{"thread":{"id":"53867","subject":"Request for adding a \"clean\" merge strategy for a double-commit merge to deal with conflicts separately","startedAt":"2020-07-16T17:15:54Z","lastAt":"2020-07-21T20:43:55Z","messageCount":8,"participants":["Alireza","Michal Suchánek","Junio C Hamano","Elijah Newren"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"401645","messageId":"CAD9n_qh0y84HC6sX1OxXWWv8dDMMA_tPv9zRknePVivQq_rfww@mail.gmail.com","threadId":"53867","inReplyTo":null,"subject":"Request for adding a \"clean\" merge strategy for a double-commit merge to deal with conflicts separately","fromName":"Alireza","fromEmail":"rezaxm@gmail.com","sentAt":"2020-07-16T17:15:24Z","receivedAt":"2020-07-16T17:15:54Z","isPatch":false,"sender":{"key":"rezaxm@gmail.com","avatar":null},"body":"Hi,\n\nEven though the merge commit's message includes conflicted files by\ndefault, the *resolution* itself is lost, that is, it's hard or\nimpossible to review how the author *resolved* said conflicts.\n\nThe proposal is that an option like `-X clean` would commit a clean\nmerge and leave out any conflicting hunks in the tree for a follow-up\ncommit to resolve conflicts.\n\nThat would be extremely helpful for a code reviewer to see how a\npossibly external contributor has dealt with upstream changes e.g. in\na long-standing branch.\n\nAny comment would be appreciated.\n\nThanks,\nAlireza\n"},{"id":"401646","messageId":"20200716172549.GJ32107@kitsune.suse.cz","threadId":"53867","inReplyTo":"CAD9n_qh0y84HC6sX1OxXWWv8dDMMA_tPv9zRknePVivQq_rfww@mail.gmail.com","subject":"Re: Request for adding a \"clean\" merge strategy for a double-commit merge to deal with conflicts separately","fromName":"Michal Suchánek","fromEmail":"msuchanek@suse.de","sentAt":"2020-07-16T17:25:49Z","receivedAt":"2020-07-16T17:25:52Z","isPatch":false,"sender":{"key":"msuchanek@suse.de","avatar":"https://avatars.githubusercontent.com/u/787652?v=4"},"body":"On Thu, Jul 16, 2020 at 09:45:24PM +0430, Alireza wrote:\n> Hi,\n> \n> Even though the merge commit's message includes conflicted files by\n> default, the *resolution* itself is lost, that is, it's hard or\n> impossible to review how the author *resolved* said conflicts.\nNo, the merge commit includes the resolution. You can compare with all\nparents, and even perform the same merge locally using your strategy and\ntooling of choice and compare the result with what the merge author\ncommitted as resolution.\n\n> \n> The proposal is that an option like `-X clean` would commit a clean\n> merge and leave out any conflicting hunks in the tree for a follow-up\n> commit to resolve conflicts.\nI don't see any value above performing the same merge locally and\ncomparing with the committed resolution. Can you please elaborate on the\nexpected format of the merge that does add some value?\n\nThanks\n\nMichal\n"},{"id":"401647","messageId":"xmqqo8ofgycz.fsf@gitster.c.googlers.com","threadId":"53867","inReplyTo":"CAD9n_qh0y84HC6sX1OxXWWv8dDMMA_tPv9zRknePVivQq_rfww@mail.gmail.com","subject":"Re: Request for adding a \"clean\" merge strategy for a double-commit merge to deal with conflicts separately","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-07-16T17:31:56Z","receivedAt":"2020-07-16T17:32:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alireza writes:\n\n> The proposal is that an option like `-X clean` would commit a clean\n> merge and leave out any conflicting hunks in the tree for a follow-up\n> commit to resolve conflicts.\n\nYou need to clarify what \"leave out\" means to you. If you and a\nside branch started from the same place and you did one thing while\nthe side branch did something else, you would get a conflict.\n\nWhat would the \"clean\" (by your definition) result have in that\nblock of contents that actually has a conflict? Do you mean to say\n\"Pick our version and ignore theirs in the blocks where the changes\nconflict\"? If so perhaps -Xours merge strategy option that the\nrecursive backend offers is what you are looking for?\n"},{"id":"401809","messageId":"CAD9n_qi=9Dm83g+dJ42m+CJKtjzm7M9_x2cCi5_iHmYr6vDQEA@mail.gmail.com","threadId":"53867","inReplyTo":"xmqqo8ofgycz.fsf@gitster.c.googlers.com","subject":"Re: Request for adding a \"clean\" merge strategy for a double-commit merge to deal with conflicts separately","fromName":"Alireza","fromEmail":"rezaxm@gmail.com","sentAt":"2020-07-21T16:15:47Z","receivedAt":"2020-07-21T16:16:19Z","isPatch":false,"sender":{"key":"rezaxm@gmail.com","avatar":null},"body":"Say I'm merging from upstream with 100 changed files, but I only get\ntwo conflicts.\nIf I manually resolve those, the changes I made in the process is\nactually lost in a large merge diff.\nWhat I'm trying to do is to separate those manual changes from\nanything else that could merge without conflict.\n\n\n> What would the \"clean\" (by your definition) result have in that\n> block of contents that actually has a conflict? Do you mean to say\n> \"Pick our version and ignore theirs in the blocks where the changes\n> conflict\"? If so perhaps -Xours merge strategy option that the\n> recursive backend offers is what you are looking for?\n\nThat's actually what I first tried. But when I use -Xours, I can't run\n`git merge ` again\nto reproduce those conflicting hunks - because the resulting commit is\ndeemed to be in sync with both parents.\nAs a result, all the upstream changes are now overridden in this side branch.\n"},{"id":"401812","messageId":"CABPp-BE2R3eUU7WD1Ovkn_OfVH6fc42DnXs5CuBTkMUcQsnCdQ@mail.gmail.com","threadId":"53867","inReplyTo":"CAD9n_qh0y84HC6sX1OxXWWv8dDMMA_tPv9zRknePVivQq_rfww@mail.gmail.com","subject":"Re: Request for adding a \"clean\" merge strategy for a double-commit merge to deal with conflicts separately","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2020-07-21T17:08:47Z","receivedAt":"2020-07-21T17:09:02Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Thu, Jul 16, 2020 at 10:17 AM Alireza wrote:\n>\n> Hi,\n>\n> Even though the merge commit's message includes conflicted files by\n> default, the *resolution* itself is lost, that is, it's hard or\n> impossible to review how the author *resolved* said conflicts.\n>\n> The proposal is that an option like `-X clean` would commit a clean\n> merge and leave out any conflicting hunks in the tree for a follow-up\n> commit to resolve conflicts.\n>\n> That would be extremely helpful for a code reviewer to see how a\n> possibly external contributor has dealt with upstream changes e.g. in\n> a long-standing branch.\n>\n> Any comment would be appreciated.\n\nI disagree that they are \"lost\". Rather, git doesn't make them very\neasy to access: git log -p won't show you any output for a merge by\ndefault, and the only options that exist (-c, -cc) don't do what you\nneed to see how conflicts were resolved. Thus, the only way to get\nthem would be to check out the first parent of the merge, do a merge\nwith the second parent, then do a \"git diff -R $merge_commit\". That's\ndoable, it's just annoying.\n\nIf there were an option to allow git log for a merge to show the\ndifference between what an automatic merge would do (complete with\nconflicts) and the end-state that was committed, then the resolution\nwould become very accessible and the rest of your request would be\nmoot. See https://bugs.chromium.org/p/git/issues/detail?id=12. I'm\ngetting closer to having such a thing.\n\nElijah\n"},{"id":"401813","messageId":"CAD9n_qim=g62TnckSG3-=1yPDCwQc3u0kYouVSU3f_a3C+NtMQ@mail.gmail.com","threadId":"53867","inReplyTo":"CABPp-BE2R3eUU7WD1Ovkn_OfVH6fc42DnXs5CuBTkMUcQsnCdQ@mail.gmail.com","subject":"Re: Request for adding a \"clean\" merge strategy for a double-commit merge to deal with conflicts separately","fromName":"Alireza","fromEmail":"rezaxm@gmail.com","sentAt":"2020-07-21T17:16:59Z","receivedAt":"2020-07-21T17:17:30Z","isPatch":false,"sender":{"key":"rezaxm@gmail.com","avatar":null},"body":"> If there were an option to allow git log for a merge to show the\n> difference between what an automatic merge would do (complete with\n> conflicts) and the end-state that was committed, then the resolution\n> would become very accessible and the rest of your request would be\n> moot.\n\nHappy to see there's already some interest to make this easier.\nHowever, my main use case is not just to see those changes, ideally it\nshould be a separate commit to be easily reviewed in a PR, for\nexample, otherwise the reviewer must pull all changes locally, which\ndoesn't sound like an improvement, IMO.\n"},{"id":"401814","messageId":"CABPp-BHxzZiMhGRbtR4BMeOHZkUBygt6JFeetNgP5=MD_PSCHA@mail.gmail.com","threadId":"53867","inReplyTo":"CAD9n_qim=g62TnckSG3-=1yPDCwQc3u0kYouVSU3f_a3C+NtMQ@mail.gmail.com","subject":"Re: Request for adding a \"clean\" merge strategy for a double-commit merge to deal with conflicts separately","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2020-07-21T17:34:53Z","receivedAt":"2020-07-21T17:35:11Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Tue, Jul 21, 2020 at 10:17 AM Alireza wrote:\n>\n> > If there were an option to allow git log for a merge to show the\n> > difference between what an automatic merge would do (complete with\n> > conflicts) and the end-state that was committed, then the resolution\n> > would become very accessible and the rest of your request would be\n> > moot.\n>\n> Happy to see there's already some interest to make this easier.\n> However, my main use case is not just to see those changes, ideally it\n> should be a separate commit to be easily reviewed in a PR, for\n> example, otherwise the reviewer must pull all changes locally, which\n> doesn't sound like an improvement, IMO.\n\nWell, perhaps here is where we diverge. Providing the ability in core\ngit from the command line to make it easy to review manual user\nchanges within a merge commit would make it so that various PR-related\ntools could add that capability as well. In fact, gerrit already has\nsuch a capability and has for years, so it's not even necessary for\ngit to have any changes to get this kind of ability.\n\nIn contrast, recording the automatic changes and the manual changes as\nseparate commits is a short term workaround for a lack of a feature,\nbut one that has some long term ramifications. In my opinion this\nworkaround wrecks history and makes it ugly for the rest of forever.\nYes, I have a strong opinion here, but it's actually a bit worse than\nthat: if people like broken history, they can already record the merge\nas two commits -- so why do we need to add a separate option to\nfacilitate breaking things? I don't like the idea of breaking things\njust because external tools don't yet have an ability we would like.\nI think the external tools should be fixed, and perhaps we could\nprovide a base capability those tools can use to more easily implement\nsuch a feature.\n\nJust my (strongly worded) $0.02, of course.\n\nElijah\n"},{"id":"401824","messageId":"xmqqlfjc7g58.fsf@gitster.c.googlers.com","threadId":"53867","inReplyTo":"CABPp-BE2R3eUU7WD1Ovkn_OfVH6fc42DnXs5CuBTkMUcQsnCdQ@mail.gmail.com","subject":"Re: Request for adding a \"clean\" merge strategy for a double-commit merge to deal with conflicts separately","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-07-21T20:43:47Z","receivedAt":"2020-07-21T20:43:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Elijah Newren writes:\n\n> I disagree that they are \"lost\". Rather, git doesn't make them very\n> easy to access: git log -p won't show you any output for a merge by\n> default, and the only options that exist (-c, -cc) don't do what you\n> need to see how conflicts were resolved.\n\nWith \"sometimes\" sprinkled into appropriate places, you are 110%\nright.\n\n"}]}