Shouldn't it be "-C $there" (like make and tar)? -- Jakub Narebski Warsaw, Poland ShadeHawk on #git --

In this particular case, it is not "chdir() before starting" but "mkdir and then chdir() into it". Using -C would be counterproductive. --

Le Saturday 08 November 2008 21:44:25 Francis Galiegue, vous avez écrit : I meant "handled", sorry. -- fge --

Your proposal goes much further than my initial question, but I thought I'd I don't understand what the "signoff" builtin is : is that a link to see only commits "Signed-off-by:" a particular person? If so, might I suggest that an "alt" tells "Only show commits signed off by this person"? And also, what about the sha1 builtin? AFAIK, a SHA1 can point to a commit, a tree, and others... In fact, it points to any of these right now, but how would you tell apart these different SHA1s in a ...

OK, you lost me somewhat. What I understand is that right now, the SHA1 links are "pre-processed" by gitweb so that the 'a' parameter is correct, right? Out of curiosity, I just went to the kernel git repository (I don't know the git version that git.kernel.org uses offhand) and altered the 'a' parameter to something which is not even an 'a' command at all: 500... However, if I try a VALID 'a' command with an "irrelevant" 'h' parameter, it acts quite funny: it just looks like it wants...

We saw this quite a number of times. I think it's about time we did something about it. But I do not think it is a reasonable design to give receive-pack such an option. An easy alternative would be to issue the usual "mkdir && git init" shell script before spawning receive-pack. This will limit the feature to pushing over the ssh transport, and pushing over the git protocol against a loose git-daemon will not be able to support it. Also I suspect this will break sites managed by gi...

If you implement a new feature by enhancing receive-pack (or anything else), you obviously cannot use the new feature against an installation with an older implementation, so what you said is a known. My point was how to enhance the receiving end and what constraints we would have in That's good to know. I also realize that gitosis does not need any hook for "git init -D $there" to decide whether a new repository can be created at requested location, as it reads the command line and makes decisi...

ad0a82bae: git-svn: Always create a new RA when calling do_switch for svn:// According to the commit message, that fixed a problem that caused the "Malformed netword data" error. It's in git v1.6.0.3, so if you have an older git version, try upgrading. HTH Björn --

This patch teaches diffcore_rename() to look into $GIT_DIR/rename-cache and make use of it to recreate diff_filepair. With proper cache, there should be no available entry for estimation after exact matching. Rename caching is per commit. I don't think abitrary tree-tree caching is worth it. $GIT_DIR/rename-cache spans out like $GIT_DIR/objects. Each file corresponds to one commit. Its content consists of lines like this <Destination SHA-1> <SPC> <Source SHA-1> <SPC> &l...

Signed-off-by: Christian Couder <chriscool@tuxfamily.org> --- git-bisect.sh | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/git-bisect.sh b/git-bisect.sh index 1daa81c..87e186f 100755 --- a/git-bisect.sh +++ b/git-bisect.sh @@ -401,7 +401,7 @@ check_merge_bases() { _bad="$1" _good="$2" _skip="$3" - for _mb in $(git merge-base --all $_bad $_good) + for _mb in $(git merge-base --all --bisect-replace $_bad $_good) do if is_among "$_mb" "$_good"; the...

Signed-off-by: Christian Couder <chriscool@tuxfamily.org> --- builtin-rev-list.c | 2 +- commit.h | 2 ++ 2 files changed, 3 insertions(+), 1 deletions(-) diff --git a/builtin-rev-list.c b/builtin-rev-list.c index 75cc1fc..7cf5f9e 100644 --- a/builtin-rev-list.c +++ b/builtin-rev-list.c @@ -637,7 +637,7 @@ static int bisect_replace(const char *refname, const unsigned char *sha1, return 0; } -static void bisect_replace_all(void) +void bisect_replace_all(void) { ...

Signed-off-by: Christian Couder <chriscool@tuxfamily.org> --- Documentation/git-bisect.txt | 61 ++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 61 insertions(+), 0 deletions(-) diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt index c7981ef..5d5bdf7 100644 --- a/Documentation/git-bisect.txt +++ b/Documentation/git-bisect.txt @@ -24,6 +24,7 @@ on the subcommand: git bisect visualize git bisect replay <logfile> git bisect log + git bisect ...

Signed-off-by: Christian Couder <chriscool@tuxfamily.org> --- t/t6035-bisect-replace.sh | 130 +++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 130 insertions(+), 0 deletions(-) create mode 100755 t/t6035-bisect-replace.sh diff --git a/t/t6035-bisect-replace.sh b/t/t6035-bisect-replace.sh new file mode 100755 index 0000000..6ab3667 --- /dev/null +++ b/t/t6035-bisect-replace.sh @@ -0,0 +1,130 @@ +#!/bin/sh +# +# Copyright (c) 2008 Christian Couder +# +test_description=...

Signed-off-by: John Chapman <thestar@fussycoder.id.au> --- contrib/fast-import/git-p4 | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4 index 38d1a17..9f0a5f9 100755 --- a/contrib/fast-import/git-p4 +++ b/contrib/fast-import/git-p4 @@ -316,8 +316,11 @@ def gitBranchExists(branch): stderr=subprocess.PIPE, stdout=subprocess.PIPE); return proc.wait() == 0; +_gitConfig = {...

Wouldn't it be better to use "git config -l -z", split lines at "\0" (NUL), and split key from value at first "\N" (CR)? This format was meant for scripts. -- Jakub Narebski Poland ShadeHawk on #git --

GitTogether 2008, which took place October 27(Mon)-29(Wed), has ended more than week ago. Therefore I'd like to ask you impressions (while it is still fresh) from GitTogether, describe talks which are not described below, correct wrong information in below, etc. Please reply to this email while GitTogether is on front of your mind... Talks at GitTogether 2008 ========================= Mon, Oct 27, 2008 ----------------- * Dscho: Contributing with Git [ message continues ]

By the way, it would be nice to have transcript for this talk, just like there is for Linus talk: http://git.or.cz/gitwiki/LinusTalk200705Transcript (but this would take some doing). It would be also nice to have slides for the talk available somewhere, Something like Sam Vilain slides from "perl.git" talk?, http://utsl.gen.nz/talks/perl-history/slides/ It shouldn't be that hard, depending on the original program the slides were made... well, it was made in Impress from OpenOffice.org ...

The discussion was along the lines of "here are some more cool things we could do, if we had notes." I don't remember the specifics of the cool things, but they were related to annotating patches with review information. Shawn can probably elaborate more. That led to a "notes as a tree are nice, but too slow because looking up a tree entry is linear" (and obviously you do a ton of lookups in the notes tree during "git log"). Dscho had posted an implementation with a persistent notes cache long ag...

If it is a warning to the user who produces the patch, and not but a Renaming patch needs manual massaging if you want to use GNU patch and that is not a new issue. People know that. The problem is in your example output were that it would break _existing git tools_ with a backward incompatible change, when you did not have to. That's the difference. --

Yeah, I was kind of hoping we could assume that anybody relying on this behavior was somewhat insane, and wouldn't be too upset when it broke. But you're probably right that we should be more conservative. I'll rework it with a "yes/no/warn" option for the config, and we can set it to "warn" (and those who really do want it can shut off the warning with "no"). Or we can even start with just leaving it on "no", but I think Yes, they do break with 4/4 applied without 3/4 (that was how I found them,...

Hi, I think I have a repository with "git read-tree -u -m HEAD" as update hook for that kind of behavior. But I will not be the person responsible to keep that behavior, if I am the only one relying on it. I very much like the approach of defaulting to "warn" for quite some time (but setting the variable to "refuse" in git-init) and then adapt the default after some time. Ciao, Dscho --

Why not --rebase --keep-merges? Personnally, I think it makes things clearer since in general options are either standalone or have a value. -- fge --

FWIW Patience diff wouldn't help at all here. Patience diff is just a matter of preseeding your preferred diff algorithm with better (wrt human readability) candidate for the invariant lines. IOW it helps dividing the problem into smaller bits, but requires *unique lines* to start with. If you haven't any, then basically, Patience diff does nothing and calls your usual diff algorithm on the whole files. It does so in a pseudo linear complexity, hence should not make overall time really worse, but...

Whoops, just WINDOW. - Davide --

It works fine for me (the time went from 5m17s to 1.8s). (By the way, my test case is certainly very odd, but it is a real file from my test suite, albeit with the content x'ed away; and the change was to adjust the expected output for all the items. I wasn't looking for bugs. :-) Thanks for the explanation and the patch. -- ams --