Re: [PATCH 4/5] Documentation: document AUTO_MERGE

[Elijah Newren <newren@gmail.com>]

On Sat, Apr 15, 2023 at 8:36 AM Philippe Blain
<levraiphilippeblain@gmail.com> wrote:
>
> Hi Elijah,
>
<snip>
> > (By contrast, the closely related --remerge-diff option to `git log`
> > or `git show` does help see the resolution of *both* the textual and
> > non-textual conflicts, but of course one can't use that option on the
> > current merge until after first commiting the existing changes.)
>
> That's true. And, remerge-diff only helps when actually looking at two-way
> merge commit, not with conflicts hit during a rebase, cherry-pick or revert.

Good point.  I have a small patchset to create an option allowing
folks to see how conflicts were resolved in reverts, and in
cherry-picks made with the -x option.  I made it over two years ago,
but never ended up deciding whether to submit it or not.  At some
point I put it up on gitgitgadget, at
https://github.com/gitgitgadget/git/pull/1151.

Points against it are that it doesn't work for rebases (because we
don't know which commits they were taken from) or for many
cherry-picks.  Given the lower utility, and the fact that it involves
commit message scraping (looking for "reverts commit <X>" and
"(cherry-picked from <X>)"), I never ended up pushing for it.

> A semi-related trick I use to check conflict resolution during a rebase (after
> resolving the conflicts but before 'git rebase --continue') is to manually
> construct a commit from the index and use 'git range-diff' to compare it
> to REBASE_HEAD.

Heh, I have a semi-related trick as well.  During rebases, when I want
to compare overall diffs for the current commit against what it was
picked from, I tend to use:
   mydiff <(git log -1 -p REBASE_HEAD) <(git diff HEAD)
where `mydiff` is a specialized wrapper around `git diff --no-index`
that actually reads the contents of /dev/fd/<value> instead of
treating it as a symlink.  (Though if I don't have that script handy,
I just plug in `diff -u` for `mydiff`).