How can I re-evaluate an old merge in git

user_896627 0
Viewed 85

Seems some crash-and-later-recover of the Eclipse git plugin resulted in a merge commit that did not pick up most of the changes that should have been merged.

If I inspect the commit in Gitlab, I see far less files changed than I would expect. I assume unchanged files of the base branch were wrongly added to the commit instead of the newer ones from the merge branch.

Unfortunately, this is all several commits (and other merges) ago and pushed to a central Gitlab repo.

How can I re-evaluate the merge and check against what has actually happened? I suppose I could 

git checkout <pre-merge-commit-hash>
git checkout -b experimental_new_merge
git merge <original-merge-branch>

to re-do the merge and then

git checkout master
git merge experimental_new_merge

to get the fixed files back into master. But I suppose that the later would result in many merge conflicts to be sorted out manually as some files touched by the merge will have newer changes too. A big goal is to check for completeness instead of just saving me the time of doing the changes again.

Is there a way to avoid this? Some way to merge again with the old branch (now only would say: Already up-to-date). Or some way to re-play the newer commits/merges onto that experimental branch and then renaming that one to master?

A
|
A2
| \
A3  B
| \  \ 
A4  C  B2
|    \   \
F    C2   B3
| \    \    \
A6  D   C3  B4
  • A - current master HEAD
  • F - possibly failed merge
  • D - branch that was possibly not merged correctly (changes missing in A)
merge git
1 Answers

You can check out commit A6 by its hash ID, resulting in a "detached HEAD":

git checkout <hash of commit A6>

(You can give this detached HEAD a new branch name, if you like, using git checkout -b.) Now you can run git merge <hash-of-commit-D> to make a new merge, just like F:

...--A6--M   <-- HEAD
      \ /
       X
      / \
...--D---F--A4--...

You can now compare the contents of new merge commit M against the contents of old merge commit F, to see if the merge was done correctly.

If it was not, you have many options for repairing the problem; the best one to use depends a lot on your situation. One simple one is to apply the corrections—the result of F-vs-M—to the tree for commit A and commit the result:

git checkout <your-branch>  # back to commit A
git diff <hash-of-F> <hash-of-M> | git apply

If the patch produced by git diff does not apply, consider using -3 / --3way to enable three-way merging, or --reject to apply the parts that fit, and then manually resolve the rejected parts.

user_12564520
Related