{"thread":{"id":"43645","subject":"Re: More merge-recursive woes","startedAt":"2006-12-13T07:36:39Z","lastAt":"2006-12-13T20:34:10Z","messageCount":3,"participants":["Johannes Schindelin","Shawn Pearce"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"297475","messageId":"20061213073639.GA9289@spearce.org","threadId":"43645","inReplyTo":null,"subject":"More merge-recursive woes","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-13T07:36:39Z","receivedAt":"2006-12-13T07:36:39Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Today I found two new bugs in git-merge-recursive.  I'm still\nresearching them, but I at least have a test case for one of the\ntwo:\n\nBug #1: If one branch renames a file which existed in the merge base,\nwhen we merge that change into a different branch the old version\nof the file is not deleted from the working directory.  The attached\ntest script shows this (\"BAD: A still exists in working directory\").\n\nBug #2: In that horrible repository that I have where I ran into the\nempty tree missing bug I now have a pair of commits which when merged\ntogether cause git-merge-recursive to go into an infinite loop,\nor least burn CPU for hours on end without doing squat.  I have\nnot been able to get enough data to even write a good analysis\nof it yet.  I'll try to do that this week, as I cannot share the\nrepository itself.  It just happens to be two new commits along\nthe same two branches however.  :-(\n\nBoth bugs are appearing with current 'next' (8662d0ea).\n\nAfter I eat something and weed through my inbox I may take a stab\nat the first one, if I haven't passed out on the couch.  :-)\n\n\n->->->->->->--t6024-merge-rename2.sh-->->->->->->->->-\n#!/bin/sh\n\ntest_description='Merge-recursive merging renames'\n. ./test-lib.sh\n\ntest_expect_success setup \\\n'\ncat >A <<\\EOF &&\na aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\nb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb\nc cccccccccccccccccccccccccccccccccccccccccccccccc\nd dddddddddddddddddddddddddddddddddddddddddddddddd\ne eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee\nf ffffffffffffffffffffffffffffffffffffffffffffffff\ng gggggggggggggggggggggggggggggggggggggggggggggggg\nh hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh\ni iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii\nj jjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj\nk kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk\nl llllllllllllllllllllllllllllllllllllllllllllllll\nm mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm\nn nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn\no oooooooooooooooooooooooooooooooooooooooooooooooo\nEOF\n\ncat >M <<\\EOF &&\nA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nB BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB\nC CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC\nD DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD\nE EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE\nF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF\nG GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG\nH HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH\nI IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII\nJ JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ\nK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK\nL LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL\nM MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM\nN NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN\nO OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO\nEOF\n\ngit add A M &&\ngit commit -m \"initial has A and M\" &&\ngit branch white &&\ngit branch red &&\n\ngit checkout white &&\nsed -e \"/^g /s/.*/g : white changes a line/\" <A >B &&\nsed -e \"/^G /s/.*/G : colored branch changes a line/\" <M >N &&\nrm -f A M &&\ngit update-index --add --remove A B M N &&\ngit commit -m \"white renames A->B, M->N\" &&\n\ngit checkout red &&\necho created by red >R &&\ngit update-index --add R &&\ngit commit -m \"red creates R\" &&\n\ngit checkout master'\n\ntest_expect_success 'merge white into red' \\\n'\n\tgit checkout -b red-white red &&\n\tgit merge white &&\n\tgit write-tree >/dev/null || {\n\t\techo \"BAD: merge did not complete\"\n\t\treturn 1\n\t}\n\n\ttest -f B || {\n\t\techo \"BAD: B does not exist in working directory\"\n\t\treturn 1\n\t}\n\ttest -f N || {\n\t\techo \"BAD: N does not exist in working directory\"\n\t\treturn 1\n\t}\n\ttest -f R || {\n\t\techo \"BAD: R does not exist in working directory\"\n\t\treturn 1\n\t}\n\n\ttest -f A && {\n\t\techo \"BAD: A still exists in working directory\"\n\t\treturn 1\n\t}\n\ttest -f M && {\n\t\techo \"BAD: M still exists in working directory\"\n\t\treturn 1\n\t}\n'\n\n"},{"id":"296245","messageId":"Pine.LNX.4.63.0612131526180.3635@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43645","inReplyTo":"20061213073639.GA9289@spearce.org","subject":"Re: More merge-recursive woes","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-13T14:28:21Z","receivedAt":"2006-12-13T14:28:21Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 13 Dec 2006, Shawn Pearce wrote:\n\n> Bug #1: If one branch renames a file which existed in the merge base, \n> when we merge that change into a different branch the old version of the \n> file is not deleted from the working directory.  The attached test \n> script shows this (\"BAD: A still exists in working directory\").\n\nYou miss a \":\" at the end of the test script, BTW.\n\nThis bug is fixed by your patch, which makes remove_file() update the \nworking directory in the last stage.\n\n> Bug #2: In that horrible repository that I have where I ran into the\n> empty tree missing bug I now have a pair of commits which when merged\n> together cause git-merge-recursive to go into an infinite loop,\n> or least burn CPU for hours on end without doing squat.  I have\n> not been able to get enough data to even write a good analysis\n> of it yet.  I'll try to do that this week, as I cannot share the\n> repository itself.  It just happens to be two new commits along\n> the same two branches however.  :-(\n\nCould you please send me the rev-list output for this test case?\n\nCiao,\n"},{"id":"296328","messageId":"20061213203410.GB32568@spearce.org","threadId":"43645","inReplyTo":"Pine.LNX.4.63.0612131526180.3635@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: More merge-recursive woes","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-13T20:34:10Z","receivedAt":"2006-12-13T20:34:10Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> On Wed, 13 Dec 2006, Shawn Pearce wrote:\n> \n> > Bug #1: If one branch renames a file which existed in the merge base, \n> > when we merge that change into a different branch the old version of the \n> > file is not deleted from the working directory.  The attached test \n> > script shows this (\"BAD: A still exists in working directory\").\n> \n> You miss a \":\" at the end of the test script, BTW.\n>\n> This bug is fixed by your patch, which makes remove_file() update the \n> working directory in the last stage.\n\nYes; and if you noticed this message got hung up in the email\nsystem while I found the bug, fixed the bug, and replied to your\ncorrection of the fix.  And I also fixed the test script along\nthe way.  Silly email systems holding messages.  *sigh*\n \n> > Bug #2: In that horrible repository that I have where I ran into the\n> > empty tree missing bug I now have a pair of commits which when merged\n> > together cause git-merge-recursive to go into an infinite loop,\n> > or least burn CPU for hours on end without doing squat.  I have\n> > not been able to get enough data to even write a good analysis\n> > of it yet.  I'll try to do that this week, as I cannot share the\n> > repository itself.  It just happens to be two new commits along\n> > the same two branches however.  :-(\n> \n> Could you please send me the rev-list output for this test case?\n\nI'm actually going to go back in later tonight to try and figure\nthis one out.  Whatever data I get I'll be sure to include the\nrev-list --parents output from this case as well; unless I can\ncraft a really small test case which causes the same infinite loop.\n\n-- \n"}]}