On Wed, Nov 14, 2018 at 04:52:59PM +0900, Junio C Hamano wrote: > Denton Liu <liu.denton@xxxxxxxxx> writes: > > > With this fix, the message becomes the following: > > > > Merge branch 'master' into new > > > > # ------------------------ >8 ------------------------ > > # Do not modify or remove the line above. > > # Everything below it will be ignored. > > # > > # Conflicts: > > # a > > I have a mixed feeling about this change and I certainly would not > call it a "fix". > > The reason why we give the list of conflicted paths that is > commented out is to remind the user of them in order to help them > describe what area of the codebase had overlapping changes, why, and > how the overlap was resolved, which is relevant information when > somebody else later needs to dig into the history to understand how > the code came into today's shape and why. For that reason, if a > careless user left conflicts list behind without describing these > details about the merge, it might be better to have the unexplained > list in the merge than nothing. > The reason why I implemented it this way is because the default cleanup setting (strip) produces this message: Merge branch 'master' into new # Conflicts: # a # # It looks like you may be committing a merge. # If this is not correct, please remove the file # .git/MERGE_HEAD # and try again. # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # # On branch new # All conflicts fixed but you are still merging. # # Changes to be committed: # modified: a # Which makes it seem like the `Conflicts:` section should be removed by default. > In theory, the above argument applies the same way for the paths to > be committed, but the list is fairly trivial to recreate with "git > diff $it^!", unlike "which paths had conflict", which can only be > found out by recreating the auto-merge. So in practice, the paths > that had conflicts is more worth showing than the paths that were > modified. > > So, I dunno. If we value the "more expensive list to reproduce", > the fix might be not to place it (and possibly the comments and > everything under the scissors line) behind a "# " comment char on > the line, without moving its position. If I understood correctly, then I have no strong opinions between uncommenting the Conflicts section by default and this change; I just think it'd be nice to have behaviour that's consistent. > > . > >
