Re: What's in git.git

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Aug 2, 2006, 00:34 UTC
Message-ID: <Pine.LNX.4.63.0608020215470.17230@wbgn013.biozentrum.uni-wuerzburg.de>
In-Reply-To: <7v1ws0xb9y.fsf@assigned-by-dhcp.cox.net>

Hi,

On Tue, 1 Aug 2006, Junio C Hamano wrote:

Show 6 quoted lines

>   - Git.pm by Pasky with help from Pavel Roskin and others.
> 
>     I'd like to merge this immediately after 1.4.2, unless there
>     still are concerns about its portability (in which case
>     please help fixing them up before this hits the "master"
>     branch).

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.

Show 5 quoted lines

>   - "merge-recur" by Johannes and Alex with help from others.
> 
>     I still see a few TODO here and there in the code, but it
>     appears that this operates correctly (I've been using this
>     for real work for some time).  Do we have benchmarks?

As for the TODOs: they are strictly non-functional. But I think we can squash the remaining three until Monday.

As for benchmarks, Alex has a very nasty test-case, where the Python script takes ages: 10 minutes as compared to just over 2 minutes with our recursive merge.

Unfortunately, resolve beats that easily with less than 3 seconds ;-)

>    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...

>       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...

Ciao, Dscho