Re: What's in git.git, and announcing GIT 1.4.2-rc4

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Aug 10, 2006, 14:00 UTC
Message-ID: <Pine.LNX.4.63.0608101558290.10541@wbgn013.biozentrum.uni-wuerzburg.de>
In-Reply-To: <81b0412b0608100634j4f82d486nd8ba6dd3ac85b0e7@mail.gmail.com>

Hi,

On Thu, 10 Aug 2006, Alex Riesen wrote:

Show 13 quoted lines

> On 8/10/06, Junio C Hamano <junkio@cox.net> wrote:
> >   - A new merge strategy, merge-recur, which is a rewrite of
> >     merge-recursive in C, by Johannes and Alex.
> 
> It still has problems devouring that monster merge I have (~20k entries,
> with around 40 changed in the other branch, around 100 revs ago. Big
> binary files involved. Renames and copies).
> Perfomance is nowhere near usable: ~20min on Windows/3GHz/2Gb,
> ~4Min on Linux/1.4GHz/384Mb ;) I agree that Linux is much more bearable
> but 4Min is still too much (especially comparing to that "stupid" resolve).
> 
> I noticed that it spends a lot of time finding renames (diffcore_std,
> in particular).

My next plans -- after making sure that merge-recursive is accurate (enough) -- was to use oprofile to find the expensive spots.

> Why doesn't it take that much time for "diff-tree -M -r base head1" +
> "diff-tree -M -r base head2", I wonder...? (~30 sek, for that windows box).

Could it be that it has many common ancestors? You have to do the rename handling twice for each merge...

> Sorry, I can't provide the tree. I suppose Mozilla tree can be compared
> to that thing, when it becomes available. Linux kernel is no good for
> reproducing this problem: it's too clean and compact.

The beauty of Open Source: since everyone can see your mess, you tend to be tidier...

Ciao, Dscho