On Sat, Apr 15, 2023 at 8:36 AM Philippe Blain <levraiphilippeblain@xxxxxxxxx> 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`).
