Re: Request for adding a "clean" merge strategy for a double-commit merge to deal with conflicts separately

From: Elijah Newren <newren@gmail.com>
Date: Jul 21, 2020, 17:08 UTC
Message-ID: <CABPp-BE2R3eUU7WD1Ovkn_OfVH6fc42DnXs5CuBTkMUcQsnCdQ@mail.gmail.com>
In-Reply-To: <CAD9n_qh0y84HC6sX1OxXWWv8dDMMA_tPv9zRknePVivQq_rfww@mail.gmail.com>

On Thu, Jul 16, 2020 at 10:17 AM Alireza <rezaxm@gmail.com> wrote:

Show 16 quoted lines

>
> Hi,
>
> Even though the merge commit's message includes conflicted files by
> default, the *resolution* itself is lost, that is, it's hard or
> impossible to review how the author *resolved* said conflicts.
>
> The proposal is that an option like `-X clean` would commit a clean
> merge and leave out any conflicting hunks in the tree for a follow-up
> commit to resolve conflicts.
>
> That would be extremely helpful for a code reviewer to see how a
> possibly external contributor has dealt with upstream changes e.g. in
> a long-standing branch.
>
> Any comment would be appreciated.

I disagree that they are "lost". Rather, git doesn't make them very easy to access: git log -p won't show you any output for a merge by default, and the only options that exist (-c, -cc) don't do what you need to see how conflicts were resolved. Thus, the only way to get them would be to check out the first parent of the merge, do a merge with the second parent, then do a "git diff -R $merge_commit". That's doable, it's just annoying.

If there were an option to allow git log for a merge to show the difference between what an automatic merge would do (complete with conflicts) and the end-state that was committed, then the resolution would become very accessible and the rest of your request would be moot. See https://bugs.chromium.org/p/git/issues/detail?id=12. I'm getting closer to having such a thing.

Elijah