{"thread":{"id":"10923","subject":"git merge no longer handles add/add","startedAt":"2007-11-19T03:18:33Z","lastAt":"2007-11-20T01:15:38Z","messageCount":8,"participants":["Martin Langhoff","Junio C Hamano","J. Bruce Fields","Jakub Narebski","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"60264","messageId":"46a038f90711181918s2743137amc6a827db6d1a6a0@mail.gmail.com","threadId":"10923","inReplyTo":null,"subject":"git merge no longer handles add/add","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-11-19T03:18:33Z","receivedAt":"2007-11-19T03:18:33Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"git used to be really good at merging 2 branches that had gotten the\nsame code added independently. Right now, both master\n(1.5.3.5.737.gdee1b)\nand next (9445b41) are telling me that the exact same file (same\nsha1), with the same mode added on 2 branches is a merge conflict. On\n_one_ of the branches there is an extra commit.\n\nHmmm.\n\nI am pretty sure that early git (pre 1.0) could handle this correctly.\nI remember sending git-archimport to Junio and immediately doing 3 or\n4 commits on top, and having the next pull work correctly without\nconflict because the merge machinery spotted the \"last common sha1\"\nfor that file and saw that only one side had changed since then.\n\nHappens with recursive and resolve. Happy to provide a minimal repro\ncase, but I think this is fairly obvious...\n\ncheers,\n\n\n\nmartin\n"},{"id":"60265","messageId":"46a038f90711181929x4bf0794eue73a5dbac8e2688a@mail.gmail.com","threadId":"10923","inReplyTo":"46a038f90711181918s2743137amc6a827db6d1a6a0@mail.gmail.com","subject":"Re: git merge no longer handles add/add","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-11-19T03:29:27Z","receivedAt":"2007-11-19T03:29:27Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On Nov 19, 2007 4:18 PM, Martin Langhoff wrote:\n> Happens with recursive and resolve. Happy to provide a minimal repro\n> case, but I think this is fairly obvious...\n\nSteps to repro...\n\n mkdir repro\n cd repro/\n cp /etc/resolv.conf ./resolv.conf\n git init\n git add resolv.conf\n git commit -m 'a' resolv.conf\n cp resolv.conf resolv-1.conf\n git add resolv-1.conf\n git commit -m 'a1' resolv-1.conf\n echo blabla >> resolv-1.conf\n git commit -m 'a2' resolv-1.conf\n git-branch other HEAD^^\n git checkout other\n cp resolv.conf resolv-1.conf\n git add resolv-1.conf\n git commit -m 'b'\n git checkout master\n git merge other\n ...\n Auto-merged resolv-1.conf\n CONFLICT (add/add): Merge conflict in resolv-1.conf\n Automatic merge failed; fix conflicts and then commit the result.\n\n\n\n\nm\n"},{"id":"60269","messageId":"7vtznipweu.fsf@gitster.siamese.dyndns.org","threadId":"10923","inReplyTo":"46a038f90711181929x4bf0794eue73a5dbac8e2688a@mail.gmail.com","subject":"Re: git merge no longer handles add/add","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-19T06:43:53Z","receivedAt":"2007-11-19T06:43:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Martin Langhoff\" writes:\n\n> On Nov 19, 2007 4:18 PM, Martin Langhoff wrote:\n>> Happens with recursive and resolve. Happy to provide a minimal repro\n>> case, but I think this is fairly obvious...\n>\n> Steps to repro...\n>\n> mkdir repro\n> cd repro/\n> cp /etc/resolv.conf ./resolv.conf\n> git init\n> git add resolv.conf\n> git commit -m 'a' resolv.conf\n> cp resolv.conf resolv-1.conf\n> git add resolv-1.conf\n> git commit -m 'a1' resolv-1.conf\n> echo blabla >> resolv-1.conf\n **************\n> git commit -m 'a2' resolv-1.conf\n> git-branch other HEAD^^\n> git checkout other\n> cp resolv.conf resolv-1.conf\n> git add resolv-1.conf\n> git commit -m 'b'\n> git checkout master\n> git merge other\n> ...\n> Auto-merged resolv-1.conf\n> CONFLICT (add/add): Merge conflict in resolv-1.conf\n> Automatic merge failed; fix conflicts and then commit the result.\n\nAs far as the point of the merge is concerned, that's an add/add\nof _different_ contents, and we have always left the conflict to\nresolve for you since day one. The only case we handle without\ncomplaining is the accidental *clean* merge. Both branches adds\nthe path *identically* compared to the common ancestor.\n\nThe very initial implementation of merge may have used the total\nemptyness as the common ancestor for the merge, and later we\nmade it a bit more pleasant to resolve by computing the common\npart of the file from the two branches to be used as a fake\nancestor contents. But the fact we left the result as conflict\nfor you to validate hasn't changed and will not change.\n"},{"id":"60347","messageId":"46a038f90711191033s4bc5ab50kd3e4f30d6b301e43@mail.gmail.com","threadId":"10923","inReplyTo":"7vtznipweu.fsf@gitster.siamese.dyndns.org","subject":"Re: git merge no longer handles add/add","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-11-19T18:33:27Z","receivedAt":"2007-11-19T18:33:27Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On Nov 19, 2007 7:43 PM, Junio C Hamano wrote:\n> As far as the point of the merge is concerned, that's an add/add\n> of _different_ contents, and we have always left the conflict to\n> resolve for you since day one. The only case we handle without\n> complaining is the accidental *clean* merge. Both branches adds\n> the path *identically* compared to the common ancestor.\n\nEven if the 2 paths did have matching content at one point? In fact,\nthe 2 files here get added with identicaly content and one of them is\nlater modified...\n\n> The very initial implementation of merge may have used the total\n> emptyness as the common ancestor for the merge, and later we\n> made it a bit more pleasant to resolve by computing the common\n> part of the file from the two branches to be used as a fake\n> ancestor contents. But the fact we left the result as conflict\n> for you to validate hasn't changed and will not change.\n\nIn this case, if you use the common part (100%) as the ancestor, then\nyou get a _clean_ merge. The file is added on both sides identically,\nand then it changes on one side.\n\nI'll see if I can repro with an older git install...\n\n\nm\n"},{"id":"60349","messageId":"20071119184657.GE14295@fieldses.org","threadId":"10923","inReplyTo":"46a038f90711191033s4bc5ab50kd3e4f30d6b301e43@mail.gmail.com","subject":"Re: git merge no longer handles add/add","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-11-19T18:46:57Z","receivedAt":"2007-11-19T18:46:57Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Tue, Nov 20, 2007 at 07:33:27AM +1300, Martin Langhoff wrote:\n> On Nov 19, 2007 7:43 PM, Junio C Hamano wrote:\n> > As far as the point of the merge is concerned, that's an add/add\n> > of _different_ contents, and we have always left the conflict to\n> > resolve for you since day one. The only case we handle without\n> > complaining is the accidental *clean* merge. Both branches adds\n> > the path *identically* compared to the common ancestor.\n> \n> Even if the 2 paths did have matching content at one point? In fact,\n> the 2 files here get added with identicaly content and one of them is\n> later modified...\n> \n> > The very initial implementation of merge may have used the total\n> > emptyness as the common ancestor for the merge, and later we\n> > made it a bit more pleasant to resolve by computing the common\n> > part of the file from the two branches to be used as a fake\n> > ancestor contents. But the fact we left the result as conflict\n> > for you to validate hasn't changed and will not change.\n> \n> In this case, if you use the common part (100%) as the ancestor, then\n> you get a _clean_ merge. The file is added on both sides identically,\n> and then it changes on one side.\n\nThat sounds like an inevitable consequence of git's design--it only uses\na global (not a per-file) common ancestor.\n\n--b.\n"},{"id":"60353","messageId":"7vabpanilk.fsf@gitster.siamese.dyndns.org","threadId":"10923","inReplyTo":"46a038f90711191033s4bc5ab50kd3e4f30d6b301e43@mail.gmail.com","subject":"Re: git merge no longer handles add/add","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-19T19:25:11Z","receivedAt":"2007-11-19T19:25:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Martin Langhoff\" writes:\n\n> On Nov 19, 2007 7:43 PM, Junio C Hamano wrote:\n>> As far as the point of the merge is concerned, that's an add/add\n>> of _different_ contents, and we have always left the conflict to\n>> resolve for you since day one. The only case we handle without\n>> complaining is the accidental *clean* merge. Both branches adds\n>> the path *identically* compared to the common ancestor.\n>\n> Even if the 2 paths did have matching content at one point? In fact,\n> the 2 files here get added with identicaly content and one of them is\n> later modified...\n\nA merge does not look at the history.\n\nIt _does_ look at the history to figure out what the common\nancestors are, but after finding them out, the \"file history\" is\nnot examined by following each step in the ancestry chain (that\nwould have been the \"blame merge\").\n\n>> The very initial implementation of merge may have used the total\n>> emptyness as the common ancestor for the merge, and later we\n>> made it a bit more pleasant to resolve by computing the common\n>> part of the file from the two branches to be used as a fake\n>> ancestor contents. But the fact we left the result as conflict\n>> for you to validate hasn't changed and will not change.\n>\n> In this case, if you use the common part (100%) as the ancestor, then\n> you get a _clean_ merge. The file is added on both sides identically,\n> and then it changes on one side.\n\nExactly. We may keep conflict markers in the file left in the\nwork tree to highlight which lines are unique to the side that\nadded more (iow, one group of lines delimited by <<< === >>> is\nempty while the other is not) but this is currently treated as\n\"fishy, needs human validation\" to catch mismerges.\n"},{"id":"60355","messageId":"fhspor$9ci$1@ger.gmane.org","threadId":"10923","inReplyTo":"7vabpanilk.fsf@gitster.siamese.dyndns.org","subject":"Re: git merge no longer handles add/add","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-11-19T19:56:07Z","receivedAt":"2007-11-19T19:56:07Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> Exactly.  We may keep conflict markers in the file left in the\n> work tree to highlight which lines are unique to the side that\n> added more (iow, one group of lines delimited by <<< === >>> is\n> empty while the other is not) but this is currently treated as\n> \"fishy, needs human validation\" to catch mismerges.\n\nBTW can xdifflib merge use original diff3 conflict markers, i.e.\n<<< [main] |||| [ancestor] === [branch] >>>?\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"60384","messageId":"Pine.LNX.4.64.0711200114290.27959@racer.site","threadId":"10923","inReplyTo":"fhspor$9ci$1@ger.gmane.org","subject":"Re: git merge no longer handles add/add","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-20T01:15:38Z","receivedAt":"2007-11-20T01:15:38Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 19 Nov 2007, Jakub Narebski wrote:\n\n> Junio C Hamano wrote:\n> \n> > Exactly. ?We may keep conflict markers in the file left in the work \n> > tree to highlight which lines are unique to the side that added more \n> > (iow, one group of lines delimited by <<< === >>> is empty while the \n> > other is not) but this is currently treated as \"fishy, needs human \n> > validation\" to catch mismerges.\n> \n> BTW can xdifflib merge use original diff3 conflict markers, i.e. <<< \n> [main] |||| [ancestor] === [branch] >>>?\n\nThere was a patch floating around which added git-diff3, just after I went \npublic with my xmerge patch. This seemed to have the code you look for.\n\nCiao,\nDscho\n\nP.S.: I will refuse to reply to you in future whenever you do not Cc: me.\n"}]}