More merge-recursive woes

More merge-recursive woes

[Shawn Pearce]

Today I found two new bugs in git-merge-recursive.  I'm still
researching them, but I at least have a test case for one of the
two:

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

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

Both bugs are appearing with current 'next' (8662d0ea).

After I eat something and weed through my inbox I may take a stab
at the first one, if I haven't passed out on the couch.  :-)


->->->->->->--t6024-merge-rename2.sh-->->->->->->->->-
#!/bin/sh

test_description='Merge-recursive merging renames'
. ./test-lib.sh

test_expect_success setup \
'
cat >A <<\EOF &&
a aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
b bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
c cccccccccccccccccccccccccccccccccccccccccccccccc
d dddddddddddddddddddddddddddddddddddddddddddddddd
e eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
f ffffffffffffffffffffffffffffffffffffffffffffffff
g gggggggggggggggggggggggggggggggggggggggggggggggg
h hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
i iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii
j jjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj
k kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk
l llllllllllllllllllllllllllllllllllllllllllllllll
m mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
n nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn
o oooooooooooooooooooooooooooooooooooooooooooooooo
EOF

cat >M <<\EOF &&
A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
B BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
C CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
D DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
E EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
F FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
G GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG
H HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
I IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII
J JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ
K KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
L LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL
M MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
N NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
O OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
EOF

git add A M &&
git commit -m "initial has A and M" &&
git branch white &&
git branch red &&

git checkout white &&
sed -e "/^g /s/.*/g : white changes a line/" <A >B &&
sed -e "/^G /s/.*/G : colored branch changes a line/" <M >N &&
rm -f A M &&
git update-index --add --remove A B M N &&
git commit -m "white renames A->B, M->N" &&

git checkout red &&
echo created by red >R &&
git update-index --add R &&
git commit -m "red creates R" &&

git checkout master'

test_expect_success 'merge white into red' \
'
	git checkout -b red-white red &&
	git merge white &&
	git write-tree >/dev/null || {
		echo "BAD: merge did not complete"
		return 1
	}

	test -f B || {
		echo "BAD: B does not exist in working directory"
		return 1
	}
	test -f N || {
		echo "BAD: N does not exist in working directory"
		return 1
	}
	test -f R || {
		echo "BAD: R does not exist in working directory"
		return 1
	}

	test -f A && {
		echo "BAD: A still exists in working directory"
		return 1
	}
	test -f M && {
		echo "BAD: M still exists in working directory"
		return 1
	}
'

Re: More merge-recursive woes

[Johannes Schindelin]

Hi,

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.

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

Ciao,

Re: More merge-recursive woes

[Shawn Pearce]

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> 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*
 
> > 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.

--