{"thread":{"id":"47740","subject":"2 conflicts referencing the same path?","startedAt":"2018-02-01T23:00:46Z","lastAt":"2018-02-02T00:46:07Z","messageCount":2,"participants":["Bryan Turner","Elijah Newren"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"338053","messageId":"CAGyf7-He4in8JWUh9dpAwvoPkQz9hr8nCBpxOxhZEd8+jtqTpg@mail.gmail.com","threadId":"47740","inReplyTo":null,"subject":"2 conflicts referencing the same path?","fromName":"Bryan Turner","fromEmail":"bturner@atlassian.com","sentAt":"2018-02-01T23:00:40Z","receivedAt":"2018-02-01T23:00:46Z","isPatch":false,"sender":{"key":"bturner@atlassian.com","avatar":"https://gravatar.com/avatar/16bcf3167981c1ef7c804e502642366d888a35b0d0b0a4ca01fdc442aa1acb1e?d=mp&s=160"},"body":"While investigating an issue with rendering conflicts on a pull\nrequest, I noticed that the merge was producing this output (sanitized\nfor paths)\n\n$ git merge --no-ff --log -m \"Test\" 190a25b6e0f32c7b8ccddf8c31e054149dece8b7\nCONFLICT (rename/add): Rename A->B in HEAD. B added in\n190a25b6e0f32c7b8ccddf8c31e054149dece8b7\nAdding as B~190a25b6e0f32c7b8ccddf8c31e054149dece8b7 instead\n...\nAuto-merging B\nCONFLICT (content): Merge conflicts in B\n\n(There are several other conflicts listed \"between\" the two I'm\nshowing here, various rename/add, add/add and content conflicts, but\nI'm trimming those out to focus on the lines that I think are relevant\nto my question.)\n\nThis merge produces 2 (or is it 3?) conflicts for the same B path:\n- Rename A to B in HEAD, add B in 190a25b\n- Content conflicts in B\n\nThe version of B left in place _does_ contain conflict markers, after\nthe merge processes completes. The version added as B~190a25b has no\nconflict markers; it just shows a small number of inserted lines.\n\nThe merge in question produces 23 different CONFLICT lines, but aside\nfrom \"composite\" conflicts (rename/add, add/add) that can include the\nsame path multiple times in their output, only this one path is\nmentioned in multiple CONFLICT lines.\n\nI'm still trying to produce a set of steps that will allow a minimal\nreproduction, but I thought I'd post to the list just to see if anyone\nhad any thoughts on how it could happen. Is it a \"normal\" (albeit\nrare) case? Or could it represent some sort of issue in Git's 3-way\nmerge algorithm (in its behavior or perhaps in how the merge conflicts\nare logged)?\n\nAny insights appreciated!\nBryan Turner\n"},{"id":"338062","messageId":"CABPp-BGJiS96_wXTp4dpVG4CpTEt--KGELykofimP-Wh4nFhdg@mail.gmail.com","threadId":"47740","inReplyTo":"CAGyf7-He4in8JWUh9dpAwvoPkQz9hr8nCBpxOxhZEd8+jtqTpg@mail.gmail.com","subject":"Re: 2 conflicts referencing the same path?","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2018-02-02T00:45:55Z","receivedAt":"2018-02-02T00:46:07Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"Hi,\n\nOn Thu, Feb 1, 2018 at 3:00 PM, Bryan Turner <bturner@atlassian.com> wrote:\n> While investigating an issue with rendering conflicts on a pull\n> request, I noticed that the merge was producing this output (sanitized\n> for paths)\n>\n> $ git merge --no-ff --log -m \"Test\" 190a25b6e0f32c7b8ccddf8c31e054149dece8b7\n> CONFLICT (rename/add): Rename A->B in HEAD. B added in\n> 190a25b6e0f32c7b8ccddf8c31e054149dece8b7\n> Adding as B~190a25b6e0f32c7b8ccddf8c31e054149dece8b7 instead\n> ...\n> Auto-merging B\n> CONFLICT (content): Merge conflicts in B\n>\n> (There are several other conflicts listed \"between\" the two I'm\n> showing here, various rename/add, add/add and content conflicts, but\n> I'm trimming those out to focus on the lines that I think are relevant\n> to my question.)\n>\n> This merge produces 2 (or is it 3?) conflicts for the same B path:\n> - Rename A to B in HEAD, add B in 190a25b\n> - Content conflicts in B\n\nRight, so the merge-base has just one (relevant) file, A.  For sake of\nargument, let's say it's contents is \"hello\\nworld\".\n\nOne side of history, leading to HEAD, also has one (relevant) file,\nwhich was a rename of A->B which also changed its contents to say\n\"hello\\nbeautiful\\nworld\"\n\nThe other side of history, leading to commit 190a25 has two files.\nThe original A, whose contents has changed to say\n\"hello\\namazing\\nworld\", and a new file called B.\n\nWhen you merge the two, the \"hello world\" file has been modified\ndifferently on the two sides as well as having been renamed from A->B,\nAND there was a separate file also placed at B on the other side of\nhistory which gets in the way.  Git resolves the\ntwo-files-getting-in-the-way-of-each-other (the rename/add) by moving\none of the two out of the way (though it really ought to move both out\nof the way, but that's a tangent).  And it resolves the conflicting\ncontent changes in the other B by doing a content merge with conflict\nmarkers, giving a file with contents of the form:\n\n\"\"\"\nhello\n<<<<<<\nbeautiful\n======\namazing\n>>>>>>\nworld\n\"\"\"\n\nand it treats that B (from the \"rename\") as more important than other\n(the \"add\") which it shows by recording it at B.\n\n> I'm still trying to produce a set of steps that will allow a minimal\n> reproduction, but I thought I'd post to the list just to see if anyone\n> had any thoughts on how it could happen. Is it a \"normal\" (albeit\n> rare) case? Or could it represent some sort of issue in Git's 3-way\n> merge algorithm (in its behavior or perhaps in how the merge conflicts\n> are logged)?\n\nIt is \"normal\" to get this, and functioning as intended, albeit fairly\nrare.  rename/rename(1to2) and rename/rename(2to1) conflicts could\nprovide very similar situations.\n\nrename/add conflicts have three issues I know about[1], but that\ndidn't include the output messages being suboptimal.  That might just\nmean my mind has been warped by reading merge-recursive.c or that I'm\ntoo familiar with it, so I don't notice how much it could be improved.\nIf you can think of how to improve the messages, I'm happy to listen,\nespecially since I'm trying to find time to continue my rewrite of\nmerge-recursive.  It'd have to apply to other rename cases, as noted\nabove (and, in particular, each side of a rename/rename(1to2) can\nfurther be involved in other collisions, such as rename/add or\nrename/rename(2to1), so it could get hairy quick if the solution isn't\nsimple enough.)\n\n[1] https://public-inbox.org/git/20171120221944.15431-6-newren@gmail.com/;\nthat patch and the others in the series are waiting for the directory\nrename detection series to progress before I resubmit.\n\nElijah\n"}]}