Reputation: 679
The changes to files in two commits have disappeared after a pull merge, eg:
I understand that something must have gone wrong with the merge operation, but what?
The commits are still in the log, but the changes they contained are no longer in master. Doing a git log
:
How can I root cause this issue?
Unfortunately, I don't have access to the actual git
commands that have generated this scenario (I am a different user). And I know that I can cherry-pick these commits to fix the issue. What I am interested in is:
a) figuring out what happened
b) preventing this from happening again.
Thanks!
Upvotes: 0
Views: 1388
Reputation: 51780
If the message in the merge commit is "Merged branch master of gitlab...", this would hint to someone having run git merge
or git pull
on his machine.
The standard message for accepted Merge requests is different.
To investigate after the facts :
you should ask "blue" how he performed the merge commit (what commands did he run ? did he fix conflicts ?)
you can run the same merge again to see what's the result of that operation :
git switch -c testmerge <commit 6>
git merge <commit 5>
you will see if conflicts are triggered, or if the merge completed succesfully, you can compare its content with the existing merge commit :
git diff testme <merge commit>
To fix the issue :
git cherry-pick
as suggested by VonC),master
-- for example : reset to commit 5
, evaluate if some changes are worth keeping in commit 6
and cherry-pick them on top of commit 5
, then cherry-pick commit 8
-- and push --force
the result to your central repo.The second point is a long sentence for :
# inspect the diff for commit 6 :
git show <commit 6> # or view it in any graphical viewer
# replay the non merge commits on top of <commit 5> :
git rebase -i <commit 5>
Upvotes: 2
Reputation: 1323125
If creating branches is not convenient, because you need to keep the merge commit and commit 8 (HEAD), but just restore changes from commit 5 and 6, you cal also consider git cherry-pick
git switch master
git cherry-pick commit4_SHA1...commit5_SHA1
That way, you would re-apply those changes on top of the existing HEAD.
Upvotes: 1