Re: Dead links, broken search box, confusing/inconvenient contact
On Fri, Oct 4, 2013 at 1:50 AM, Stefan Pochmann stefan.pochm...@gmail.com wrote: 4) When I found this email address and sent a mail with items 1)-3), I got a rejection reply saying The message contains HTML subpart. Very annoying. I'm trying to help here by pointing out problems, and you're making it really inconvenient. Majordomo, the software that runs this mailing list (and many others) considers HTML to be a mark of spam: Usage of HTML in email -- even as an alternate format -- is considered to be signature characteristics of SPAM. source: http://vger.kernel.org/majordomo-info.html Just want to point out it's not us. -- Cheers, Ray Chuan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
Do You Need A Loan? Email Us Now At jerryfund...@rediffmail.com With Amount Needed As Loan And Phone Number. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] add: add --bulk to index all objects into a pack file
The use case is
tar -xzf bigproject.tar.gz
cd bigproject
git init
git add .
# git grep or something
The first add will generate a bunch of loose objects. With --bulk, all
of them are forced into a single pack instead, less clutter on disk
and maybe faster object access.
On gdb-7.5.1 source directory, the loose .git directory takes 66M
according to `du` while the packed one takes 32M. Timing of
git grep --cached:
loose packed
real0m1.671s 0m1.372s
user0m1.542s 0m1.313s
sys 0m0.126s 0m0.056s
It's not an all-win situation though. --bulk is slower than --no-bulk
because:
- Triple hashing: we need to calculate both object SHA-1s _and_ pack
SHA-1. At the end we have to fix up the pack, which means rehashing
the entire pack again. --no-bulk only cares about object SHA-1s.
- We write duplicate objects to the pack then truncate it, because we
don't know if it's a duplicate until we're done writing, and cannot
keep it in core because it's potentially big. So extra I/O (but
hopefully not too much because duplicate objects should not happen
often).
- Sort and write .idx file.
- (For the future) --no-bulk could benefit from multithreading
because this is CPU bound operation. --bulk could not.
But again this comparison is not fair, --bulk is closer to:
git add .
git ls-files --stage | awk '{print $2;}'| \
git pack-objects .git/objects/pack-
except that it does not deltifies nor sort objects.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
v2 examines pros and cons of --bulk and I'm not sure if turning it on
automatically (with heuristics) is a good idea anymore.
Oh and it fixes not packing empty files.
Documentation/git-add.txt | 10 ++
builtin/add.c | 10 +-
sha1_file.c | 3 ++-
3 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 48754cb..147d191 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -160,6 +160,16 @@ today's git add pathspec..., ignoring removed files.
be ignored, no matter if they are already present in the work
tree or not.
+--bulk::
+ Normally new objects are indexed and stored in loose format,
+ one file per new object in $GIT_DIR/objects. This option
+ forces putting all objects into a single new pack. This may
+ be useful when you need to add a lot of files initially.
++
+This option is equivalent to running `git -c core.bigFileThreshold=0 add`.
+If you want to only pack files larger than a size threshold, use the
+long form.
+
\--::
This option can be used to separate command-line options from
the list of files, (useful when filenames might be mistaken
diff --git a/builtin/add.c b/builtin/add.c
index 226f758..40cbb71 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -336,7 +336,7 @@ static struct lock_file lock_file;
static const char ignore_error[] =
N_(The following paths are ignored by one of your .gitignore files:\n);
-static int verbose, show_only, ignored_too, refresh_only;
+static int verbose, show_only, ignored_too, refresh_only, bulk_index;
static int ignore_add_errors, intent_to_add, ignore_missing;
#define ADDREMOVE_DEFAULT 0 /* Change to 1 in Git 2.0 */
@@ -368,6 +368,7 @@ static struct option builtin_add_options[] = {
OPT_BOOL( 0 , refresh, refresh_only, N_(don't add, only refresh the
index)),
OPT_BOOL( 0 , ignore-errors, ignore_add_errors, N_(just skip files
which cannot be added because of errors)),
OPT_BOOL( 0 , ignore-missing, ignore_missing, N_(check if - even
missing - files are ignored in dry run)),
+ OPT_BOOL( 0 , bulk, bulk_index, N_(pack all objects instead of
creating loose ones)),
OPT_END(),
};
@@ -560,6 +561,13 @@ int cmd_add(int argc, const char **argv, const char
*prefix)
free(seen);
}
+ if (bulk_index)
+ /*
+* Pretend all blobs are large files, forcing them
+* all into a pack
+*/
+ big_file_threshold = 0;
+
plug_bulk_checkin();
if ((flags ADD_CACHE_IMPLICIT_DOT) prefix) {
diff --git a/sha1_file.c b/sha1_file.c
index f80bbe4..8b66840 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -3137,7 +3137,8 @@ int index_fd(unsigned char *sha1, int fd, struct stat *st,
if (!S_ISREG(st-st_mode))
ret = index_pipe(sha1, fd, type, path, flags);
- else if (size = big_file_threshold || type != OBJ_BLOB ||
+ else if ((big_file_threshold size = big_file_threshold) ||
+type != OBJ_BLOB ||
(path would_convert_to_git(path, NULL, 0, 0)))
ret = index_core(sha1, fd, size, type, path, flags);
else
--
1.8.2.82.gc24b958
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
Re: [PATCH v2] add: add --bulk to index all objects into a pack file
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: except that it does not deltifies nor sort objects. I think this should be mentionned in the doc. Otherwise, it seems like git add --bulk is like git add git repack. BTW, will the next git gc be efficient after a add --bulk? I mean: will it consider the pack as already pack and let it as-is, without deltification, or will it get a chance to actually repack efficiently? -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] add: add --bulk to index all objects into a pack file
On Fri, Oct 4, 2013 at 2:10 PM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: except that it does not deltifies nor sort objects. I think this should be mentionned in the doc. Otherwise, it seems like git add --bulk is like git add git repack. Yep. Will do. BTW, will the next git gc be efficient after a add --bulk? I mean: will it consider the pack as already pack and let it as-is, without deltification, or will it get a chance to actually repack efficiently? gc does repack -A so all separate packs will be merged. It may delay gc time though because it'll take more time to hit the loose object limit. I think pack-objects will try to deltify so we're good. If we produce bad deltas in --bulk then that's another story because pack-objects will try to blindly reuse them. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] silence gcc array-bounds warning
In shorten_unambiguous_ref, we build and cache a reverse-map of the
rev-parse rules like this:
static char **scanf_fmts;
static int nr_rules;
if (!nr_rules) {
for (; ref_rev_parse_rules[nr_rules]; nr_rules++)
... generate scanf_fmts ...
}
where ref_rev_parse_rules is terminated with a NULL pointer.
Compiling with gcc -O2 -Wall does not cause any problems, but
compiling with -O3 -Wall generates:
$ make CFLAGS='-O3 -Wall' refs.o
refs.c: In function ‘shorten_unambiguous_ref’:
refs.c:3379:29: warning: array subscript is above array bounds
[-Warray-bounds]
for (; ref_rev_parse_rules[nr_rules]; nr_rules++)
Curiously, we can silence this by explicitly nr_rules to 0
in the beginning of the loop, even though the compiler
should be able to tell that we follow this code path only
when nr_rules is already 0.
Signed-off-by: Jeff King p...@peff.net
---
I've convinced myself that this is a gcc bug and not some weird
undefined behavior or extra analysis that gcc can do due to inlined
functions. The fact that what should be a noop makes the warning go away
makes me very suspicious.
You can also silence it by declaring ref_rev_parse_rules as:
const char * const ref_rev_parse_rules[];
to make both the strings themselves and the pointers in the list
constant. And that may be worth doing instead, because it really is
a constant list for us. The downside is that it's a little uglier to
read, and it carries over to pointers we use to access it, like:
const char * const *p;
for (p = ref_rev_parse_rules; *p; p++)
...
refs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/refs.c b/refs.c
index ad5d66c..c1cc98a 100644
--- a/refs.c
+++ b/refs.c
@@ -3376,7 +3376,7 @@ char *shorten_unambiguous_ref(const char *refname, int
strict)
size_t total_len = 0;
/* the rule list is NULL terminated, count them first */
- for (; ref_rev_parse_rules[nr_rules]; nr_rules++)
+ for (nr_rules = 0; ref_rev_parse_rules[nr_rules]; nr_rules++)
/* no +1 because strlen(%s) strlen(%.*s) */
total_len += strlen(ref_rev_parse_rules[nr_rules]);
--
1.8.4.1.4.gf327177
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] for-each-ref: avoid loading objects to print %(objectname)
If you ask for-each-ref to print each ref and its object,
like:
git for-each-ref --format='%(objectname) %(refname)'
this should involve little more work than looking at the ref
files themselves (along with packed-refs). However,
for-each-ref will actually load each object from disk just
to print its sha1. For most repositories, this isn't a big
deal, but it can be noticeable if you have a large number of
refs to print. Here are best-of-five timings for the command
above on a repo with ~10K refs:
[before]
real0m0.112s
user0m0.092s
sys 0m0.016s
[after]
real0m0.014s
user0m0.012s
sys 0m0.000s
This patch checks for %(objectname) and %(objectname:short)
before we actually parse the object (and the rest of the
code is smart enough to avoid parsing if we have filled all
of our placeholders).
Note that we can't simply move the objectname parsing code
into the early loop. If the deref form %(*objectname) is
used, then we do need to parse the object in order to peel
the tag. So instead of moving the code, we factor it out
into a separate function that can be called for both cases.
While we're at it, we add some basic tests for the
dereferenced placeholders, which were not tested at all
before. This helps ensure we didn't regress that case.
Signed-off-by: Jeff King p...@peff.net
---
builtin/for-each-ref.c | 29 -
t/t6300-for-each-ref.sh | 4
2 files changed, 24 insertions(+), 9 deletions(-)
diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c
index 1d4083c..d096051 100644
--- a/builtin/for-each-ref.c
+++ b/builtin/for-each-ref.c
@@ -205,6 +205,22 @@ static void *get_obj(const unsigned char *sha1, struct
object **obj, unsigned lo
return buf;
}
+static int grab_objectname(const char *name, const unsigned char *sha1,
+ struct atom_value *v)
+{
+ if (!strcmp(name, objectname)) {
+ char *s = xmalloc(41);
+ strcpy(s, sha1_to_hex(sha1));
+ v-s = s;
+ return 1;
+ }
+ if (!strcmp(name, objectname:short)) {
+ v-s = xstrdup(find_unique_abbrev(sha1, DEFAULT_ABBREV));
+ return 1;
+ }
+ return 0;
+}
+
/* See grab_values */
static void grab_common_values(struct atom_value *val, int deref, struct
object *obj, void *buf, unsigned long sz)
{
@@ -225,15 +241,8 @@ static void grab_common_values(struct atom_value *val, int
deref, struct object
v-ul = sz;
v-s = s;
}
- else if (!strcmp(name, objectname)) {
- char *s = xmalloc(41);
- strcpy(s, sha1_to_hex(obj-sha1));
- v-s = s;
- }
- else if (!strcmp(name, objectname:short)) {
- v-s = xstrdup(find_unique_abbrev(obj-sha1,
- DEFAULT_ABBREV));
- }
+ else if (deref)
+ grab_objectname(name, obj-sha1, v);
}
}
@@ -676,6 +685,8 @@ static void populate_value(struct refinfo *ref)
}
continue;
}
+ else if (!deref grab_objectname(name, ref-objectname, v))
+ continue;
else
continue;
diff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh
index 752f5cb..2b4b9a9 100755
--- a/t/t6300-for-each-ref.sh
+++ b/t/t6300-for-each-ref.sh
@@ -58,6 +58,8 @@ test_atom head type ''
test_atom head numparent 0
test_atom head object ''
test_atom head type ''
+test_atom head *objectname ''
+test_atom head *objecttype ''
test_atom head author 'A U Thor aut...@example.com 1151939924 +0200'
test_atom head authorname 'A U Thor'
test_atom head authoremail 'aut...@example.com'
@@ -91,6 +93,8 @@ test_atom tag type 'commit'
test_atom tag numparent ''
test_atom tag object '67a36f10722846e891fbada1ba48ed035de75581'
test_atom tag type 'commit'
+test_atom tag *objectname '67a36f10722846e891fbada1ba48ed035de75581'
+test_atom tag *objecttype 'commit'
test_atom tag author ''
test_atom tag authorname ''
test_atom tag authoremail ''
--
1.8.4.1.4.gf327177
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git counterpart to SVN bugtraq properties?
On Wednesday, July 17, 2013 03:03:14 PM Marc Strapetz wrote: I'm looking for a specification or guidelines on how a Git client should integrate with bug tracking systems. For SVN, one can use bugtraq-properties [1] to specify e.g. the issue tracker URL ... There's seldom a question that has not been asked before. There already is a popular standard for project information like the link to a bugtracker and much more: https://en.wikipedia.org/wiki/DOAP (Description of a Project) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git counterpart to SVN bugtraq properties?
On 04.10.2013 11:15, Thomas Koch wrote: On Wednesday, July 17, 2013 03:03:14 PM Marc Strapetz wrote: I'm looking for a specification or guidelines on how a Git client should integrate with bug tracking systems. For SVN, one can use bugtraq-properties [1] to specify e.g. the issue tracker URL ... There's seldom a question that has not been asked before. There already is a popular standard for project information like the link to a bugtracker and much more: https://en.wikipedia.org/wiki/DOAP (Description of a Project) I can't see how that relates to concepts like (SVN) bugtraq properties. -Marc -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git counterpart to SVN bugtraq properties?
On Friday, October 04, 2013 01:22:08 PM Marc Strapetz wrote: On 04.10.2013 11:15, Thomas Koch wrote: On Wednesday, July 17, 2013 03:03:14 PM Marc Strapetz wrote: I'm looking for a specification or guidelines on how a Git client should integrate with bug tracking systems. For SVN, one can use bugtraq-properties [1] to specify e.g. the issue tracker URL ... There's seldom a question that has not been asked before. There already is a popular standard for project information like the link to a bugtracker and much more: https://en.wikipedia.org/wiki/DOAP (Description of a Project) I can't see how that relates to concepts like (SVN) bugtraq properties. You asked for a place to write the bugtracker URL to. DOAP defines a data structure that also contains the bugtracker URL of a project. Just place a doap file in your Git repo and parse it. Regards, Thomas Koch -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] add: add --bulk to index all objects into a pack file
On Fri, Oct 4, 2013 at 1:57 PM, Nguyễn Thái Ngọc Duy pclo...@gmail.com wrote: It's not an all-win situation though. --bulk is slower than --no-bulk because: - Triple hashing: we need to calculate both object SHA-1s _and_ pack SHA-1. At the end we have to fix up the pack, which means rehashing the entire pack again. --no-bulk only cares about object SHA-1s. Oops, it's quadruple hashing: one for object sha-1 (1), one for pack sha-1 while writing pack (2), two for pack header fixup: one after the the header fixup (3), and one repeating the same (2) just to verify that it matches (2) exactly (4). Do we have to be this paranoid? I think we could drop (2) and (4) in this case. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Extend runtime prefix computation
Hi, On Wed, Apr 17, 2013 at 08:06:47AM +0200, Michael Weiser wrote: Support determining the binaries' installation path at runtime even if called without any path components (i.e. via search path). What's the reason you want it on other platforms? It's part of an in-house development toolchain featuring git that I want to hand to users as a binary installation for a number of platforms but give them the choice where to install it. I'd still like to have this included in mainline git. What can I do to get it there? Thanks, -- Michael Weiserscience + computing ag Senior Systems Engineer Geschaeftsstelle Duesseldorf Martinstrasse 47-55, Haus A phone: +49 211 302 708 32 D-40223 Duesseldorf fax: +49 211 302 708 50 www.science-computing.de -- Vorstandsvorsitzender/Chairman of the board of management: Gerd-Lothar Leonhart Vorstand/Board of Management: Dr. Bernd Finkbeiner, Michael Heinrichs, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Philippe Miltin Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Bug: Segmentation fault (core dumped)
Hi, When I am trying to clone an empty repository and I will use together --depth 1 and -b branch_name (branch does not exist) then I get Segmentation fault (repo seems to be cloned correctly). Please see attachment for more details. Best regards Robert Mitwicki git clone --depth 1 -b test https://github.com/mitfik/coredump.git /tmp/coredump.git Cloning into '/tmp/coredump.git'... warning: You appear to have cloned an empty repository. Segmentation fault (core dumped) Unexpected end of command stream git --version git version 1.8.4 (gdb) info registers rax0x0 0 rbx0x0 0 rcx0x0 0 rdx0x72 114 rsi0x519d04 5348612 rdi0x58 88 rbp0x7d9680 0x7d9680 rsp0x7fffd8f8 0x7fffd8f8 r8 0x7fffe30b 140737488347915 r9 0x58 88 r100x7fffd6c0 140737488344768 r110x772c1d50 140737340251472 r120x0 0 r130x1 1 r140x58 88 r150x0 0 rip0x772c1d68 0x772c1d68 eflags 0x10206 [ PF IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 (gdb) bt #0 0x772c1d68 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x004204a0 in ?? () #2 0x00405b84 in ?? () #3 0x00404f6d in ?? () #4 0x771af76d in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6 #5 0x004053b9 in ?? () #6 0x7fffe078 in ?? () #7 0x001c in ?? () #8 0x0008 in ?? () #9 0x7fffe2eb in ?? () #10 0x7fffe310 in ?? () #11 0x7fffe337 in ?? () #12 0x in ?? () (gdb) x/60x $sp 0x7fffd8f8: 0x 0x 0x007d9680 0x 0x7fffd908: 0x 0x 0x0001 0x 0x7fffd918: 0x0058 0x 0x 0x 0x7fffd928: 0x004204a0 0x 0xe30b 0x7fff 0x7fffd938: 0xf7fdcd20 0x7fff 0x007d1fd0 0x 0x7fffd948: 0x 0x 0xdd60 0x7fff 0x7fffd958: 0xdad0 0x 0x 0x 0x7fffd968: 0x 0x 0x 0x 0x7fffd978: 0xf7fdb630 0x7fff 0x0001 0x7fff 0x7fffd988: 0x 0x 0x0001 0xefbd 0x7fffd998: 0xf7fdc9c8 0x7fff 0x003b4700 0x 0x7fffd9a8: 0x003b4700 0x 0x3900 0x 0x7fffd9b8: 0xddd0 0x7fff 0xde50 0x7fff 0x7fffd9c8: 0xf7ffa4c8 0x7fff 0x 0x 0x7fffd9d8: 0xf7fdcd20 0x7fff 0xdb30 0x0001
[PATCH] cherry-pick: do not segfault without arguments.
Commit 182d7dc46b (2013-09-05, cherry-pick: allow - as abbreviation of
'@{-1}') accesses the first argument without checking whether it exists.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
builtin/revert.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/revert.c b/builtin/revert.c
index 52c35e7..f81a48c 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -202,7 +202,7 @@ int cmd_cherry_pick(int argc, const char **argv, const char
*prefix)
memset(opts, 0, sizeof(opts));
opts.action = REPLAY_PICK;
git_config(git_default_config, NULL);
- if (!strcmp(argv[1], -))
+ if (argc 1 !strcmp(argv[1], -))
argv[1] = @{-1};
parse_args(argc, argv, opts);
res = sequencer_pick_revisions(opts);
--
1.8.4.1.469.gb38b9db
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] push: Enhance unspecified push default warning
When the unset push.default warning message is displayed this may be the first time many users encounter push.default. Modified the warning message to explain in a compact manner what push.default is and why it is being changed in Git 2.0. Also provided additional information to help users decide if this change will affect their workflow. Signed-off-by: Greg Jacobson coder5...@gmail.com --- builtin/push.c | 9 + 1 file changed, 9 insertions(+) diff --git a/builtin/push.c b/builtin/push.c index 7b1b66c..5393e28 100644 --- a/builtin/push.c +++ b/builtin/push.c @@ -174,6 +174,15 @@ N_(push.default is unset; its implicit value is changing in\n \n git config --global push.default simple\n \n + When push.default is set to 'matching', git will push all local branches\n + to the remote branches with the same (matching) name. This will no\n + longer be the default in Git 2.0 because a branch could be\n + unintentionally pushed to a remote.\n + \n + In Git 2.0 the new push.default of 'simple' will push only the current\n + branch to the same remote branch used by git pull. A push will\n + only succeed if the remote and local branches have the same name.\n + \n See 'git help config' and search for 'push.default' for further information.\n (the 'simple' mode was introduced in Git 1.7.11. Use the similar mode\n 'current' instead of 'simple' if you sometimes use older versions of Git)); -- 1.8.4.474.g128a96c.dirty -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] clone: do not segfault when specifying a nonexistent branch
I think we should emit a warning additionally?
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
builtin/clone.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/clone.c b/builtin/clone.c
index 0aff974..b764ad0 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -688,7 +688,7 @@ static void write_refspec_config(const char* src_ref_prefix,
if (option_mirror || !option_bare) {
if (option_single_branch !option_mirror) {
- if (option_branch) {
+ if (option_branch our_head_points_at) {
if (strstr(our_head_points_at-name,
refs/tags/))
strbuf_addf(value, +%s:%s,
our_head_points_at-name,
our_head_points_at-name);
--
1.8.4.1.469.gb38b9db
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mergetool--lib: Fix typo in the merge/difftool help
The help text for the `tool` flag should mention:
--tool=tool
instead of:
--tool-tool
Signed-off-by: Stefan Saasen ssaa...@atlassian.com
---
git-mergetool--lib.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index feee6a4..e1c7eb1 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -263,7 +263,7 @@ list_merge_tool_candidates () {
}
show_tool_help () {
- tool_opt='git ${TOOL_MODE}tool --tool-tool'
+ tool_opt='git ${TOOL_MODE}tool --tool=tool'
tab=' '
LF='
--
1.8.4.474.g128a96c.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Bug? Unexpected outputs of git pull on stdout v.s. stderr
Hello, git --version - git version 1.7.9.5 on linux A 'git pull' operation exits with 1 (which is normal) but generates the following output and error flows: stdout: Auto-merging c/makefile CONFLICT (content): Merge conflict in c/makefile Auto-merging c/x_color.c Auto-merging c/x_export.c CONFLICT (content): Merge conflict in c/x_export.c ... CONFLICT (content): Merge conflict in c/x_line.h Automatic merge failed; fix conflicts and then commit the result. stderr: From /home/malaise/ada * branchXft- FETCH_HEAD With option -q the Error flow is empty and the Output is as before. I would expect that the text: From /home/malaise/ada * branchXft- FETCH_HEAD is part of stdout and suppressed with option -q And that the message: Automatic merge failed; fix conflicts and then commit the result. is part of stderr (and kept with option -q). Or did I miss something? Thank you. -- Couldn't eradicate windows from my PC but I caged it in a vmware. Pascal MALAISE -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git rebase is confused about commits w/o textual changes (e.g. chmod's)
On Sat, Sep 28, 2013 at 02:32:44AM +0300, Paul Sokolovsky wrote: $ git --version git version 1.8.4 Specifically from Ubuntu PPA: http://ppa.launchpad.net/git-core/ppa/ubuntu Script to reproduce the issue is: https://gist.github.com/pfalcon/6736632 , based on a real-world case of merging histories of a fork created from a flat tree snapshot with the original project it was created from. Okay, as I suspected, the rebase would have resulted in an empty commit. In this particular case, the commit being rebased changed the permissions on the files, but those permissions are already correct, so the commit really is empty, even considering permissions. It looks like git is doing the right thing here. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: git rebase is confused about commits w/o textual changes (e.g. chmod's)
Hello, On Fri, 4 Oct 2013 20:28:54 + brian m. carlson sand...@crustytoothpaste.net wrote: On Sat, Sep 28, 2013 at 02:32:44AM +0300, Paul Sokolovsky wrote: $ git --version git version 1.8.4 Specifically from Ubuntu PPA: http://ppa.launchpad.net/git-core/ppa/ubuntu Script to reproduce the issue is: https://gist.github.com/pfalcon/6736632 , based on a real-world case of merging histories of a fork created from a flat tree snapshot with the original project it was created from. Okay, as I suspected, the rebase would have resulted in an empty commit. In this particular case, the commit being rebased changed the permissions on the files, but those permissions are already correct, so the commit really is empty, even considering permissions. It looks like git is doing the right thing here. Hmm, ok, thanks for investigation! But then, about this empty commit handling behavior by rebase. Low-level developer in me understands the current behavior - if we expect changes, but there're none, then it as well may be something wrong, so let's not play smartass, but tell user outright what's happening. But higher-level user in me knows that rebase is pretty trusty nowadays, and real-world cause of empty commits during rebase is that the change is already upstream. So, can we have something like --skip-empty? Then some good time later, we can talk about changing defaults ;-). -- Best regards, Paul mailto:pmis...@gmail.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clone: do not segfault when specifying a nonexistent branch
On Fri, Oct 4, 2013 at 9:20 PM, Stefan Beller
stefanbel...@googlemail.com wrote:
I think we should emit a warning additionally?
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
I think it's nice to credit Robert for reporting the fault in the
commit message (something like reported-by: or noticed-by:...)
---
builtin/clone.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/clone.c b/builtin/clone.c
index 0aff974..b764ad0 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -688,7 +688,7 @@ static void write_refspec_config(const char*
src_ref_prefix,
if (option_mirror || !option_bare) {
if (option_single_branch !option_mirror) {
- if (option_branch) {
+ if (option_branch our_head_points_at) {
if (strstr(our_head_points_at-name,
refs/tags/))
strbuf_addf(value, +%s:%s,
our_head_points_at-name,
our_head_points_at-name);
This prevents the segfault, but what about remote.*.fetch? Should we
setup standard refspec for fetch or..?
--
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mergetool--lib: Fix typo in the merge/difftool help
On Fri, Oct 4, 2013 at 7:34 AM, Stefan Saasen ssaa...@atlassian.com wrote:
The help text for the `tool` flag should mention:
--tool=tool
instead of:
--tool-tool
Signed-off-by: Stefan Saasen ssaa...@atlassian.com
---
Good eyes!
Reviewed-by: David Aguilar dav...@gmail.com
Thanks
git-mergetool--lib.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index feee6a4..e1c7eb1 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -263,7 +263,7 @@ list_merge_tool_candidates () {
}
show_tool_help () {
- tool_opt='git ${TOOL_MODE}tool --tool-tool'
+ tool_opt='git ${TOOL_MODE}tool --tool=tool'
tab=' '
LF='
--
1.8.4.474.g128a96c.dirty
--
David
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Zhejiang University of Technology, Hangzhou, CHINA - Tianjin University, Tianjin, CHINA - Nanjing Forestry University, CHINA - Asia University, TAIWAN
Call For Papers: 1st International Conference on Forest Resources and Environment (FORE '13) 1st International Conference on Wood Science and Technology (WOST '13) 1st International Conference on Interior Design and Contruction (INDC '13) 1st International Conference on Tourism and Economic Development (TEDE '13) Nanjing, China, November 17-19, 2013 Details: www.naun.org The registration fee is: 250 EUR for participants from Zhejiang University of Technology, Hangzhou, China, 250 EUR for participants from Tianjin University, Tianjin, China and 550 EUR for non-WSEAS members and 500 EUR for our members. Paper submission deadline: October 17, 2013 The proceedings will be published after the conference Scientific Sponsors: --- * Zhejiang University of Technology, Hangzhou, CHINA * Tianjin University, Tianjin, CHINA * Nanjing Forestry University, CHINA * College of Computer Science Department of Biomedical Informatics, Asia University, TAIWAN * Music Academy Studio Musica, ITALY Publications = Accepted Papers are going to be published in (a) Book, Hard-Copy Proceedings (Indexed in ISI, SCOPUS, AMS, ACS, CiteSeerX, Zentralblatt, British Library, EBSCO, SWETS, EMBASE, CAS etc) (b) CD-ROM Proceedings (Indexed in ISI, SCOPUS, AMS, ACS, CiteSeerX, Zentralblatt, British Library, EBSCO, SWETS, EMBASE, CAS etc) Review Procees for Book and CD-ROM: Papers will undergo thorough peer review by 3 international experts. Nobody can qualify to become Reviewer for our Conference Proceedings (Book and CD-ROM) without proper academic qualifications (recent publications in SCOPUS and ISI). You will receive comments from those 3 reviewers and your paper might be * a) accepted as it is (unaltered) * b) accepted after minor revision * c) accepted after major revision * d) rejected We cannot guarantee acceptance for cases b) and c), if the reviewers are not satisfied by your response and your (minor or major) modifications to your conference paper. (c) After new peer thorough review of their extended versions in a well-known Journal (Indexed in SCOPUS, AMS, ACS, CiteSeerX, Zentralblatt, British Library, EBSCO, SWETS, EMBASE, CAS etc) Review Process for Extended Version in collaborating journals: Extended Versions of high-quality journals will undergo again thorough peer review by 3 other international experts. Nobody can qualify to become Reviewer for these journals without proper academic qualifications (recent publications in SCOPUS and ISI). You will receive comments from those other reviewers and your extended paper might be * a) accepted as it is (unaltered) * b) accepted after minor revision * c) accepted after major revision * d) rejected We cannot guarantee acceptance for cases b) and c), if the reviewers are not satisfied by your response and your (minor or major) modifications to your extended paper. (d) E-Library with free access Review Process === Papers in our Conferences and Journals are subject to peer, thorough review. Nobody can qualify to become a Reviewer without proper academic qualifications (i.e. recent publications in SCOPUS and ISI). Reviewers whose review work is not thorough or who are not longer active are immediately removed from ourreviewers' list Indexes The Proceedings (CD-ROM and Books) will be send for indexing to: ISI (Thomson Reuters) ELSEVIER SCOPUS ACM - Association for Computing Machinery Zentralblatt MATH British Library EBSCO SWETS EMBASE CAS - American Chemical Society CiteSeerx Cabell Publishing Electronic Journals Library SAO/NASA Astrophysics Data System EI Compendex Engineering Village CSA Cambridge Scientific Abstracts DoPP GEOBASE Biobase American Mathematical Society (AMS) Inspec - The IET Ulrich's International Periodicals Directory This message satisfies the requirements of the European legislation on advertising (Directiva 2002/58/CE of the European Parliament). If you do not wish to receive e-mails from us, if you want to un~subscribe, send an email to north.atlantic.university.un...@naun.org with the following command as Subject: un~subscribe email1, email2, email3, where email1, email2, email3 are all the possible emails that you have For example un~subscribe johnsm...@gmail.com, jsm...@server.mbu.uk etc.. Please accept our apologies for any inconvenience caused. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
