From: Elijah Newren <newren@gmail.com>
To: Alireza <rezaxm@gmail.com>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: Request for adding a "clean" merge strategy for a double-commit merge to deal with conflicts separately
Date: Tue, 21 Jul 2020 10:08:47 -0700 [thread overview]
Message-ID: <CABPp-BE2R3eUU7WD1Ovkn_OfVH6fc42DnXs5CuBTkMUcQsnCdQ@mail.gmail.com> (raw)
In-Reply-To: <CAD9n_qh0y84HC6sX1OxXWWv8dDMMA_tPv9zRknePVivQq_rfww@mail.gmail.com>
On Thu, Jul 16, 2020 at 10:17 AM Alireza <rezaxm@gmail.com> wrote:
>
> 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
next prev parent reply other threads:[~2020-07-21 17:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-16 17:15 Request for adding a "clean" merge strategy for a double-commit merge to deal with conflicts separately Alireza
2020-07-16 17:25 ` Michal Suchánek
2020-07-16 17:31 ` Junio C Hamano
2020-07-21 16:15 ` Alireza
2020-07-21 17:08 ` Elijah Newren [this message]
2020-07-21 17:16 ` Alireza
2020-07-21 17:34 ` Elijah Newren
2020-07-21 20:43 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CABPp-BE2R3eUU7WD1Ovkn_OfVH6fc42DnXs5CuBTkMUcQsnCdQ@mail.gmail.com \
--to=newren@gmail.com \
--cc=git@vger.kernel.org \
--cc=rezaxm@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).