Re: What's in git.git

From: Junio C Hamano <junkio@cox.net>
Date: Aug 2, 2006, 07:41 UTC
Message-ID: <7v7j1rwpmn.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.63.0608020215470.17230@wbgn013.biozentrum.uni-wuerzburg.de>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Although I am admittedly not a big fan of this dependency (it is one thing 
> to depend on perl, but another to depend on compiling C modules for perl), 
> I have to say that on all machines I tested, it works fine now. The only 
> platform I did not test is IRIX, and I'll do that on Friday.

Thanks.

Show 6 quoted lines

>>    Johannes Schindelin:
>>       Add the --color-words option to the diff options family
>
> BTW I realized it is not really colouring words, since I erroneously 
> selected word boundaries at whitespace. But if the only reaction to this 
> is your "soooooooo strange", I guess you'll drop it...

Perhaps, I dunno.

>>       read-tree --rename and merge-rename
>
> Do you have any numbers on that? I could imagine that merge-recursive 
> could be rewritten as a shell script using this and git-merge-base...

I think "read-tree --rename" is now becoming into a debuggable shape.

One bad thing about it is that merge-rename uses the usual merge-one-file, and it loses a rename merge conflict because of that. When our branch renames A to B while their branch renames A to C, "read-tree --rename" notices it and leaves A, B, and C in stage #1, #2, and #3, but merge-one-file resolves these paths following the usual 3-way merge rules, resulting A to be removed and both B and C created.