0

The changes to files in two commits have disappeared after a pull merge, eg: enter image description here

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: enter image description here

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!

joeDiHare
  • 619
  • 8
  • 19
  • 1
    You could create a branch foo from Commit 6 and a branch bar from Commit 5 in the local repository. Checkout foo and merge bar to redo the merge and see what happens. – ElpieKay Jul 27 '22 at 02:29
  • side note : the `--graph` option of `git log` is precious to understand how commits are related. Try running `git log --graph` or `git log --oneline --graph` in your terminal, you should have a much better time seeing your history. – LeGEC Jul 27 '22 at 07:20
  • the colors of the commits do match individual authors, correct ? (e.g : "orange" commits are the ones created by Claire, "blue" by Tim, ...) – LeGEC Jul 27 '22 at 07:22

2 Answers2

2

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 :

  • you may either keep the existing history and re-add commits 4 and 5 on top (for example using git cherry-pick as suggested by VonC),
  • or you can rewrite the history of 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>
LeGEC
  • 46,477
  • 5
  • 57
  • 104
  • Upvoted, but why promote the use of the [old, obsolete and confusing `git checkout` command](https://stackoverflow.com/a/57066202/6309)? It is `git switch -c testmerge ` for the past 3 years now. – VonC Jul 27 '22 at 07:40
  • 1
    Only the command itself has those attributes. You are forever young in spirit :) – VonC Jul 27 '22 at 07:43
  • @VonC But what are we supposed to do with that scary "THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE." mention on the [man page](https://git-scm.com/docs/git-switch#_description)? – Romain Valeri Jul 27 '22 at 07:47
  • 1
    @RomainValeri I have addressed that in [Sept. 2020](https://stackoverflow.com/a/63736082/6309): those two new commands are not going anywhere and are here to stay. – VonC Jul 27 '22 at 07:51
  • Here is what I concluded: the user had an incomplete `pull`, where it fetched but did not merge commits #4 and #5. Then they pushed a new commit (#6 above) which ended up on top of commit #3, therefore losing a lot of the changes in #4 and #5. This became evident doing `git log --graph` (thanks for the suggestion @LeGEC), which interestingly does NOT produce the same graph as per gitlab's `graph` page (which I showed above, and usually found on a page like "`gitlab.com/[PROJECT]/-/network/master`"). Thanks – joeDiHare Jul 27 '22 at 21:23
  • One last thing, could you fix `git switch -b testmerge ` to `git switch -c testmerge `? Thanks. – joeDiHare Jul 27 '22 at 21:23
  • @joeDiHare: fixed. about the "not the same graph": depending on how the graphing implementation chooses to draw the branches or the order in which commits appear, you may have different diagrams for what is actually the same graph. – LeGEC Jul 27 '22 at 21:28
1

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.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250