{"thread":{"id":"50059","subject":"Merge behavior with merge.conflictStyle diff3","startedAt":"2018-12-18T17:34:36Z","lastAt":"2018-12-18T18:02:02Z","messageCount":2,"participants":["Adilson de Almeida Junior","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"365544","messageId":"CAKmxmfosaExDYNyoaNg2teHMzsu3JJ3bqiLhrAaUt0Jt473Phw@mail.gmail.com","threadId":"50059","inReplyTo":null,"subject":"Merge behavior with merge.conflictStyle diff3","fromName":"Adilson de Almeida Junior","fromEmail":"adilson.smem@gmail.com","sentAt":"2018-12-18T17:34:20Z","receivedAt":"2018-12-18T17:34:36Z","isPatch":false,"sender":{"key":"adilson.smem@gmail.com","avatar":null},"body":"Hi,\n\nI´m not sure if this is a bug or not.\n\nThese are the steps to reproduce it (git 2.17 at least):\n- In a repo, with default settings (merge strategy, conflict style,\nmerge drivers, etc);\n- Create a file 'test.xml', and add the following content to it:\n\n[div]\n  A\n[/div]\n\n- Perform a git add and git commit, then, create a branch named branch1;\n- Next, on branch1, edit the xml file and add a new div:\n\n[div]\n  A\n[/div]\n[div]\n  B\n[/div]\n\n- Then, comit the changes, and after that return to branch master;\n- So, perform a similar but slightly different change:\n\n[div]\n  A\n[/div]\n[div]\n  C\n[/div]\n\n- Then commit it;\n- Now, do a merge (git merge branch1);\n\nWhen my conflictStyle is default (merge), the merged file becames:\n[div]\n[[[[[[[ HEAD\n  C\n=======\n  B\n]]]]]]] branch1\n[/div]\n\nBut when the merge.conflictStyle is set to diff3, I get:\n[[[[[[[ HEAD\n[div]\n  C\n[/div]\n||||||| merged common ancestors\n=======\n[div]\n  B\n[/div]\n]]]]]]] branch1\n\nI guess, most times the second behavior is the expected: two conflict\nhunks, not only the divvergent pieces (this case, the second line) of\nthem. By the doc:\n\nmerge.conflictStyle\n\n    Specify the style in which conflicted hunks are written out to\nworking tree files upon merge. The default is \"merge\", which shows a\n[[[[[[[ conflict marker, changes made by one side, a ======= marker,\nchanges made by the other side, and then a ]]]]]]] marker. An\nalternate style, \"diff3\", adds a ||||||| marker and the original text\nbefore the ======= marker.\n\nI replaced the 'lower than' and 'greater than' symbols by 'open n\nclose square brackets' to avoid antivirus.\n\nIs this a bug, or something I missunderstood from git docs?\n\nThanks,\nAdilson de Almeida Jr\n"},{"id":"365547","messageId":"20181218180158.GC31070@sigill.intra.peff.net","threadId":"50059","inReplyTo":"CAKmxmfosaExDYNyoaNg2teHMzsu3JJ3bqiLhrAaUt0Jt473Phw@mail.gmail.com","subject":"Re: Merge behavior with merge.conflictStyle diff3","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-12-18T18:01:59Z","receivedAt":"2018-12-18T18:02:02Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Dec 18, 2018 at 03:34:20PM -0200, Adilson de Almeida Junior wrote:\n\n> I guess, most times the second behavior is the expected: two conflict\n> hunks, not only the divvergent pieces (this case, the second line) of\n> them. By the doc:\n> \n> merge.conflictStyle\n> \n>     Specify the style in which conflicted hunks are written out to\n> working tree files upon merge. The default is \"merge\", which shows a\n> [[[[[[[ conflict marker, changes made by one side, a ======= marker,\n> changes made by the other side, and then a ]]]]]]] marker. An\n> alternate style, \"diff3\", adds a ||||||| marker and the original text\n> before the ======= marker.\n> \n> I replaced the 'lower than' and 'greater than' symbols by 'open n\n> close square brackets' to avoid antivirus.\n> \n> Is this a bug, or something I missunderstood from git docs?\n\nThis is the expected behavior. There's some philosophical discussion\nabout the correct thing to do here in this thread (that message and its\nreplies, but the whole thread is an interesting read):\n\n  https://public-inbox.org/git/7vvc94p8hb.fsf@alter.siamese.dyndns.org/\n\nNote that there is a patch in that thread to implement \"zdiff3\", which\ndoes what you want. I've been rebasing it and running with it for\nseveral years now. You can get my rebased version by fetching:\n\n  https://github.com/peff/git ukk/zdiff3\n\nBut note that I think it may have a subtle bug, as I have once or twice\nover the years seen it cause a segfault.\n\n-Peff\n"}]}