How to identify conflicting commits by hash during git rebase?

Question

When I encounter a merge conflict using git rebase, how can I identify the source of the conflict in terms of commits, rather than just file difference

Answer 1

Since Git 2.17 (March 2018), you shouldn't need to use rebase-apply.

The new "--show-current-patch" option gives an end-user facing way to get the diff being applied when "git rebase" (and "git am") stops with a conflict.

See commit fbd7a23, commit 6633529, commit 984913a (11 Feb 2018) by Nguyễn Thái Ngọc Duy (pclouds).
^{(Merged by Junio C Hamano -- gitster -- in commit 9ca488c, 06 Mar 2018)}

am: add --show-current-patch

^{Signed-off-by: Nguyễn Thái Ngọc Duy}

Pointing the user to $GIT_DIR/rebase-apply may encourage them to mess around in there, which is not a good thing.

With this, the user does not have to keep the path around somewhere (because after a couple of commands, the path may be out of scrollback buffer) when they need to look at the patch.

See more at "Show current git interactive rebase operation"

Example:

C:\Users\VonC\repo\src>git rebase origin/master
First, rewinding head to replay your work on top of it...
Applying: change code
Using index info to reconstruct a base tree...
M       a/src/file
Falling back to patching base and 3-way merge...
Auto-merging a/src/file
CONFLICT (content): Merge conflict in a/src/file
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch' to see the failed patch                  <======
Patch failed at 0001 change code
Resolve all conflicts manually, mark them as resolved with
"git add/rm ", then run "git rebase --continue".
You can instead skip this commit: run "git rebase --skip".
To abort and get back to the state before "git rebase", run "git rebase --abort".

You would then get:

C:\Users\VonC\rep\src>git am --show-current-patch
  commit xxx (master)
  Author: VonC 
  Date:   Mon Nov 4 13:59:18 2019 +0100

      change code

  diff --git a/a/src/file b/a/src/file
  index yyy..zzz 100644
  --- a/a/src/file
  +++ b/a/src/file
  @@ -13,5 +13,5 @@ file: /a/src
   content line 1
   content line 2
   content line 3
   content line 4
  -content line 5
  -content line 6
  +content bis line 5
  +content bis line 6

---

"git am --short-current-patch" is a way to show the piece of e-mail for the stopped step, which is not suitable to directly feed "git apply" (it is designed to be a good "git am" input).

With Git 2.26 (Q1 2020), it learned a new option to show only the patch part.

See commit aa416b2, commit f3b4822, commit e8ef1e8, commit bc8620b, commit 62e7a6f (20 Feb 2020) by Paolo Bonzini (bonzini).
^{(Merged by Junio C Hamano -- gitster -- in commit 0e0d717, 09 Mar 2020)}

am: support --show-current-patch=diff to retrieve .git/rebase-apply/patch

^{Reported-by: J. Bruce Fields
Signed-off-by: Paolo Bonzini}

When "git am --show-current-patch" was added in commit 984913a210 ("am: add --show-current-patch", 2018-02-12, Git v2.17.0-rc0 -- merge listed in batch #7), "git am" started recommending it as a replacement for .git/rebase-merge/patch.

Unfortunately the suggestion is somewhat misguided; for example, the output of "git am --show-current-patch" cannot be passed to "git apply" if it is encoded as quoted-printable or base64.

Add a new mode to "git am --show-current-patch" in order to straighten the suggestion.

The new mode is diff:

--show-current-patch[=(diff|raw)]:

Show the message at which git am has stopped due to conflicts.
If raw is specified, show the raw contents of the e-mail message; if diff, show the diff portion only.
Defaults to raw.

And:

am: support --show-current-patch=raw as a synonym for --show-current-patch

^{Signed-off-by: Paolo Bonzini}

To simplify worktree operations and to avoid that users poke into .git, it would be better if "git am" also provided a mode that copies .git/rebase-merge/patch to stdout.

One possibility could be to have completely separate options, introducing for example --show-current-message (for .git/rebase-apply/NNNN) and --show-current-diff (for .git/rebase-apply/patch), while possibly deprecating --show-current-patch.

That would even remove the need for the first two patches in the series. However, the long common prefix would have prevented using an abbreviated option such as "--show".

Therefore, I chose instead to add a string argument to --show-current-patch.