{"thread":{"id":"17290","subject":"Merging adjacent deleted lines?","startedAt":"2009-01-21T19:20:50Z","lastAt":"2009-01-23T15:59:46Z","messageCount":9,"participants":["Jonathan del Strother","Robin Rosenberg","Junio C Hamano","Jay Soffian"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"101429","messageId":"57518fd10901211120n62f8d0e9ya8595fc9baa6476c@mail.gmail.com","threadId":"17290","inReplyTo":null,"subject":"Merging adjacent deleted lines?","fromName":"Jonathan del Strother","fromEmail":"maillist@steelskies.com","sentAt":"2009-01-21T19:20:50Z","receivedAt":"2009-01-21T19:20:50Z","isPatch":false,"sender":{"key":"jon.delstrother@bestbefore.tv","avatar":"https://gravatar.com/avatar/754e21ab701c00e2d21fc261187254c34b2a1c0b959d9ee5be1a295990be3081?d=mp&s=160"},"body":"Say I have a file that started out with the following content :\n\nline1\nline2\nline3\nline4\n\n\nI create a branch, which deletes line2. Someone else's branch deletes line 3.\n\nWhen I merge those two branches, the conflict looks like :\n\nline1\n<<<<<<< HEAD:lines\nline3\n=======\nline2\n>>>>>>> SomeoneElse:lines\nline4\n\n\n\nWhich in my cursory overview, looked an awful lot like the obvious\nmerge resolution ought to be\n\nline1\nline3\nline4\n\nAfter all - I know I want to delete line 2, and wasn't aware of the\nother person deleting line 3.\n\nIt was only later that we discovered that the merge was broken and\nboth lines should have been deleted. Thinking about it, I guess that\nthe conflict if the other branch _hadn't_ deleted line 3 would have\nlooked something like\n\nline1\n<<<<<<< HEAD:lines\n=======\nline2\n>>>>>>> SomeoneElse:lines\nline3\nline4\n\n - which wouldn't have resulted in a conflict anyway.\n\n\nSo, it looks like I need to be way more careful when merging\nconflicts. Which leads me to - what tools do you use when studying\nconflicts like that? git blame seems the obvious one, for getting the\ncontext of each deletion, but it seems like I need to run it once as\ngit blame HEAD lines, and once as git blame MERGE_HEAD lines. Is\nthere something a little more integrated for comparing the origin of\neach change from both merge branches simultaneously?\n\nWould welcome any thoughts on how you guys approach conflict-resolution\n-Jon\n"},{"id":"101432","messageId":"200901212049.55556.robin.rosenberg.lists@dewire.com","threadId":"17290","inReplyTo":"57518fd10901211120n62f8d0e9ya8595fc9baa6476c@mail.gmail.com","subject":"Re: Merging adjacent deleted lines?","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2009-01-21T19:49:55Z","receivedAt":"2009-01-21T19:49:55Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"onsdag 21 januari 2009 20:20:50 skrev Jonathan del Strother:\n[...]\n> So, it looks like I need to be way more careful when merging\n> conflicts. Which leads me to - what tools do you use when studying\n> conflicts like that? git blame seems the obvious one, for getting the\n> context of each deletion, but it seems like I need to run it once as\n> git blame HEAD lines, and once as git blame MERGE_HEAD lines. Is\n> there something a little more integrated for comparing the origin of\n> each change from both merge branches simultaneously?\n> \n> Would welcome any thoughts on how you guys approach conflict-resolution\n\nI think you've illustrated a case for graphical merge resolution tools, i.e.\nrun git mergetool to help resolve the conlicts. It will run a graphical tool\nfor you.\n\nThe list seems to be: kdiff3 kdiff3 tkdiff xxdiff meld gvimdiff opendiff emerge vimdiff\n\nNone of the tools can run blame in the merge tool also. That would be nice.\n\n-- robin\n"},{"id":"101448","messageId":"7vy6x4cqq1.fsf@gitster.siamese.dyndns.org","threadId":"17290","inReplyTo":"57518fd10901211120n62f8d0e9ya8595fc9baa6476c@mail.gmail.com","subject":"Re: Merging adjacent deleted lines?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-01-21T21:08:06Z","receivedAt":"2009-01-21T21:08:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan del Strother writes:\n\n> Say I have a file that started out with the following content :\n>\n> line1\n> line2\n> line3\n> line4\n>\n>\n> I create a branch, which deletes line2. Someone else's branch deletes line 3.\n>\n> When I merge those two branches, the conflict looks like :\n>\n> line1\n> <<<<<<< HEAD:lines\n> line3\n> =======\n> line2\n>>>>>>>> SomeoneElse:lines\n> line4\n>\n>\n>\n> Which in my cursory overview, looked an awful lot like the obvious\n> merge resolution ought to be\n>\n> line1\n> line3\n> line4\n\nWhy? The obvious resolution would be:\n\n line1\n line4\n\nas it is obvious that you do not want line2 and the other does not want\nline3.\n\nBut that is only true if it is obvious to you. When you cannot remember\nwhat each side did since they forked, there are two ways you can use to\nunderstand the history better without resorting to graphical merge tools.\n\n $ git log -p --merge \n\nwhich shows you the commits involved in the conflict, what they did, and\nwhy they did what they did (of course, this assumes that your project\nparticipant did their commits properly).\n\n $ git checkout --conflict=diff3 \n\nThis will add an extra block to the conflicted output to show the common\nancestor's version, after showing yours. The conflicts left in \nwould look like this:\n\n line1\n <<<<<<< ours\n line3\n |||||||\n line2\n line3\n =======\n line2\n >>>>>>> theirs\n line4\n\nwhich may make it clearer that you deleted line2 and they deleted line3.\n"},{"id":"101520","messageId":"57518fd10901220257p62b6d1efof97ba3fcf90dbfda@mail.gmail.com","threadId":"17290","inReplyTo":"7vy6x4cqq1.fsf@gitster.siamese.dyndns.org","subject":"Re: Merging adjacent deleted lines?","fromName":"Jonathan del Strother","fromEmail":"maillist@steelskies.com","sentAt":"2009-01-22T10:57:41Z","receivedAt":"2009-01-22T10:57:41Z","isPatch":false,"sender":{"key":"jon.delstrother@bestbefore.tv","avatar":"https://gravatar.com/avatar/754e21ab701c00e2d21fc261187254c34b2a1c0b959d9ee5be1a295990be3081?d=mp&s=160"},"body":"On Wed, Jan 21, 2009 at 7:49 PM, Robin Rosenberg\n wrote:\n> onsdag 21 januari 2009 20:20:50 skrev Jonathan del Strother:\n> [...]\n> I think you've illustrated a case for graphical merge resolution tools, i.e.\n> run git mergetool to help resolve the conlicts. It will run a graphical tool\n> for you.\n>\n\nMmm. I use opendiff, which is generally ok, but in this case produced\na merge looking like this :\nhttp://pastie.org/paste/asset/367587/Picture_6.png\nWhich, in my mind, isn't any clearer about the fact that both lines\nought to be deleted than the text conflict markers are. Do any of the\nother graphical tools present conflicts like that differently?\n\n\nOn Wed, Jan 21, 2009 at 9:08 PM, Junio C Hamano wrote:\n> But that is only true if it is obvious to you. When you cannot remember\n> what each side did since they forked, there are two ways you can use to\n> understand the history better without resorting to graphical merge tools.\n>\n> $ git log -p --merge \n>\n\nAhh, that's very helpful - thanks.\n"},{"id":"101559","messageId":"200901222113.31082.robin.rosenberg.lists@dewire.com","threadId":"17290","inReplyTo":"57518fd10901220257p62b6d1efof97ba3fcf90dbfda@mail.gmail.com","subject":"Re: Merging adjacent deleted lines?","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2009-01-22T20:13:30Z","receivedAt":"2009-01-22T20:13:30Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"torsdag 22 januari 2009 11:57:41 skrev Jonathan del Strother:\n> On Wed, Jan 21, 2009 at 7:49 PM, Robin Rosenberg\n> wrote:\n> > onsdag 21 januari 2009 20:20:50 skrev Jonathan del Strother:\n> > [...]\n> > I think you've illustrated a case for graphical merge resolution tools, i.e.\n> > run git mergetool to help resolve the conlicts. It will run a graphical tool\n> > for you.\n> >\n> \n> Mmm. I use opendiff, which is generally ok, but in this case produced\n> a merge looking like this :\n> http://pastie.org/paste/asset/367587/Picture_6.png\n> Which, in my mind, isn't any clearer about the fact that both lines\n> ought to be deleted than the text conflict markers are. Do any of the\n> other graphical tools present conflicts like that differently?\n\nTry a three-way merge tool instead like, e.g. xxdiff.\n\n-- robin\n"},{"id":"101623","messageId":"76718490901222318l7c3559ecje4a627fe2ff2ad12@mail.gmail.com","threadId":"17290","inReplyTo":"200901222113.31082.robin.rosenberg.lists@dewire.com","subject":"Re: Merging adjacent deleted lines?","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2009-01-23T07:18:15Z","receivedAt":"2009-01-23T07:18:15Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Thu, Jan 22, 2009 at 3:13 PM, Robin Rosenberg\n wrote:\n> torsdag 22 januari 2009 11:57:41 skrev Jonathan del Strother:\n>> Mmm. I use opendiff, which is generally ok, but in this case produced\n>> a merge looking like this :\n>>\n>> http://pastie.org/paste/asset/367587/Picture_6.png\n>>\n>> Which, in my mind, isn't any clearer about the fact that both lines\n>> ought to be deleted than the text conflict markers are. Do any of the\n>> other graphical tools present conflicts like that differently?\n>\n> Try a three-way merge tool instead like, e.g. xxdiff.\n\nopendiff (aka FileMerge) *is* a three-way merge tool. If the\nscreenshot above is not clear, I'm not sure what would be. The left\npane shows your copy of the file with only line1, line3, and line4.\nThe right pane shows the other copy, with only line1, line2, and\nline4.\n\nThe lower pane shows the merge resolution, which currently has the\nsingle conflict highlighted, and is being resolved toward the right.\nYou can use the Action drop down menu to resolve the conflict one of\nfive ways: left, right, both (left first), both (right first),\nneither. You've currently got \"right\" selected. The appropriate\nresolution is \"neither\", which keeps neither line3 from the left, nor\nline2 from the right.\n\nShrug.\n\nj.\n"},{"id":"101647","messageId":"200901231132.36543.robin.rosenberg.lists@dewire.com","threadId":"17290","inReplyTo":"76718490901222318l7c3559ecje4a627fe2ff2ad12@mail.gmail.com","subject":"Re: Merging adjacent deleted lines?","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2009-01-23T10:32:36Z","receivedAt":"2009-01-23T10:32:36Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"fredag 23 januari 2009 08:18:15 skrev Jay Soffian:\n> On Thu, Jan 22, 2009 at 3:13 PM, Robin Rosenberg\n> wrote:\n[...]\n> > Try a three-way merge tool instead like, e.g. xxdiff.\n> \n> opendiff (aka FileMerge) *is* a three-way merge tool. If the\n> screenshot above is not clear, I'm not sure what would be. The left\n> pane shows your copy of the file with only line1, line3, and line4.\n> The right pane shows the other copy, with only line1, line2, and\n> line4.\n\nWhere's the ancestor? I'm used to having four panes for doing three-way \nmerges, but your screenshot showed only three.\n\n> \n> Shrug.\n\nYou have the option to ignore me....\n\n-- robin\n"},{"id":"101660","messageId":"76718490901230751uef27274sf7b44e6718f861ae@mail.gmail.com","threadId":"17290","inReplyTo":"200901231132.36543.robin.rosenberg.lists@dewire.com","subject":"Re: Merging adjacent deleted lines?","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2009-01-23T15:51:16Z","receivedAt":"2009-01-23T15:51:16Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Fri, Jan 23, 2009 at 5:32 AM, Robin Rosenberg\n wrote:\n> Where's the ancestor? I'm used to having four panes for doing three-way\n> merges, but your screenshot showed only three.\n\nI installed xxdiff to compare w/opendiff, meld, and vimdiff and I see\nwhat you mean with xxdiff.\n\nopendiff/meld/vimdiff don't show the ancestor directly, but they are\nstill using it in order to show how one version differs from the\nancestor in the left pane, and how the other version differs in the\nright pane.\n\n>> Shrug.\n>\n> You have the option to ignore me....\n\nDoh, I meant only \"I don't understand.\" My apologies.\n\nj.\n"},{"id":"101661","messageId":"76718490901230759k25c4d0c9t57c648f3e373c5bb@mail.gmail.com","threadId":"17290","inReplyTo":"76718490901230751uef27274sf7b44e6718f861ae@mail.gmail.com","subject":"Re: Merging adjacent deleted lines?","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2009-01-23T15:59:46Z","receivedAt":"2009-01-23T15:59:46Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Fri, Jan 23, 2009 at 10:51 AM, Jay Soffian wrote:\n> opendiff/meld/vimdiff don't show the ancestor directly, but they are\n> still using it in order to show how one version differs from the\n> ancestor in the left pane, and how the other version differs in the\n> right pane.\n\nHmm, okay. I see that meld/vimdiff are apparently not doing a 3-way\nmerge. So I guess after all this, I don't have an explanation about\nopendiff. It claims to do a 3-way diff and mergetool is passing it the\nancestor as an argument. Sorry for the confusion.\n\nj.\n"}]}