Reputation: 9126
I'm having a heck of a time orchestrating my first major branch and merge. What happened is I have a main branch called 'main', and a new branch that created called 'branch2' off of 'main'. I made a whole lot of changes in 'branch2' in several files over several weeks and created some new files as well. I had also made a few minor changes in 'main' during this time. When time came to merge, I checked out 'main' and called git merge branch2
. Not surprisingly, it told me that I had conflicts to resolve in one of my files. So I used git mergetool
to open meld, my diff viewer of choice, to resolve the differences. After reconciling those differences, I called git merge branch2
again, and the merge happened successfully.
The problem is that it didn't actually merge successfully. Some elements merged properly, but some changes in 'branch2' never moved over and I have no idea why. I tried calling git merge branch2
, but now it just says "everything up to date". This clearly isn't right, because if you git checkout branch2
, then you can see changes that aren't in 'main'.
Any idea what might have happened? Why is git declaring "everything up to date" when it didn't merge correctly? Is there any way to force git to try the merge again?
Upvotes: 7
Views: 9111
Reputation: 70863
You did an evil merge. Run gitk --all
to see what’s going on. You went wrong when you called git merge
a second time. When you resolved your conflicts, you need to run git commit
, not merge.
But git now thinks that your branch2
is merged into main
. So you need to remove that merge commit. Use gitk to get the sha fo the last commit before the merge and run git reset --hard **SHA**
on the main branch to reset it back to that stage. Then do your merge again.
Upvotes: 6