CODEWITHSUNDEEP
gitmerge-conflict-resolutiongit-merge-conflictgit-rerere
jozxyqk
jozxyqk

Reputation: 17266

How can I see what "previous resolution" git applied?

When cherry-picking a commit with similar resolutions to a previously resolved patch I sometime see git saying it tried to re-apply what I'd done earlier. I believe this is the rerere component of git.

$ git cherry-pick ...
error: could not apply a123f6c424... [commit message]
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'
Resolved 'path/to/file.c' using previous resolution.

The problem is I don't trust my previous resolution. How can I see what the "previous resolution" did? I.e. the diff of just the conflicting areas.

I know I can re-do the merge completely with the following commands. However, I don't want to completely throw away the previous work, just review and validate it.

git rerere forget path/to/file.c
git checkout -m path/to/file.c
# Resolve. e.g., git mergetool

The following questions are similar but are for merge commits, not conflicts in general or uncommitted changes.

Upvotes: 4

Views: 692

Answers (2)

jthill
jthill

Reputation: 60313

You can save the rerere'd version for comparison against the conflicted version, and do the comparison, with

mv $file{,.rerere}
git checkout -m $file
git diff --no-index $file{,.rerere}     # (or another differ,`diff -u file{,.rerere}` works too)

and either move the rerere'd version back or just rerun the rerere (with git rerere) if you like what you see, or git rerere forget $file to forget it, then add a resolution you like better (the commit will rerun rerere to record it).

You can see the diffs Git's working with, using

file=path/to/conflicted/file
git diff :1:$file :2:$file    # "our" diffs, base to local tip
git diff :1:$file :3:$file    # "their diffs, base to merged tip

which shows what the automerge was looking at. (Cherrypick is a merge, with the cherrypick's parent as the base, which you'll see when you run hose stage diffs.)

Upvotes: 1

Jamin
Jamin

Reputation: 66

I ran into this same issue recently, though I was rebasing instead of cherry-picking, but I don't think there should be a difference. Here's a flow that should work:

  • First, abort the operation where the conflict occurred:

    git cherry-pick --abort

  • Then, repeat the operation with rerere functionality disabled:

    git -c rerere.enabled=false cherry-pick ...

  • Observe the conflicts.

  • Apply the recorded resolution manually:

    git rerere

It's a bit tedious, but I think it achieves what you're wanting. I'd love if there were a way to show a diff of the merge attempt (with conflicts) against the resolution like git show --diff-merges=remerge, but I'm not sure if there's a straightforward way to get that.

Upvotes: 2

Related Questions