Re: More merge-recursive woes

From: Shawn Pearce <spearce@spearce.org>
Date: Dec 13, 2006, 20:34 UTC
Message-ID: <20061213203410.GB32568@spearce.org>
In-Reply-To: <Pine.LNX.4.63.0612131526180.3635@wbgn013.biozentrum.uni-wuerzburg.de>

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

Show 11 quoted lines

> On Wed, 13 Dec 2006, Shawn Pearce wrote:
> 
> > Bug #1: If one branch renames a file which existed in the merge base, 
> > when we merge that change into a different branch the old version of the 
> > file is not deleted from the working directory.  The attached test 
> > script shows this ("BAD: A still exists in working directory").
> 
> You miss a ":" at the end of the test script, BTW.
>
> This bug is fixed by your patch, which makes remove_file() update the 
> working directory in the last stage.

Yes; and if you noticed this message got hung up in the email
system while I found the bug, fixed the bug, and replied to your
correction of the fix.  And I also fixed the test script along
the way.  Silly email systems holding messages.  *sigh*

Show 10 quoted lines

> > Bug #2: In that horrible repository that I have where I ran into the
> > empty tree missing bug I now have a pair of commits which when merged
> > together cause git-merge-recursive to go into an infinite loop,
> > or least burn CPU for hours on end without doing squat.  I have
> > not been able to get enough data to even write a good analysis
> > of it yet.  I'll try to do that this week, as I cannot share the
> > repository itself.  It just happens to be two new commits along
> > the same two branches however.  :-(
> 
> Could you please send me the rev-list output for this test case?

I'm actually going to go back in later tonight to try and figure this one out. Whatever data I get I'll be sure to include the rev-list --parents output from this case as well; unless I can craft a really small test case which causes the same infinite loop.