tags:

views:

204

answers:

2

I'm fairly new to git. Just a few minutes ago, I performed a merge on two branches; let's call them A and B. I was 'on' branch A; my next command was 'git merge B'. It said there was one conflict, but I looked in the file and there were no conflict markers. I added the file, committed the change, and did the merge command again. "Already up-to-date" is the message I get.

Yet no merge seems to have taken place. Both branches still exist, and both are exactly as they were before the merge.

What did I do wrong? And how can I make these two branches merge successfully?

Thanks.

+1  A: 

I am not sure about your initial conflict, except if was about a file both removed in A while re-added in B. The exact error message might help here (along with your Git version)

Merging two branches does not mean one will disappear, only than their history will be linked through a new commit bringing all differences from one branch to another.

"Already up-to-date" means all changes from B are now already in A.
In other word, B is a parent of A. (gitk should be able to show you that)

Since you have added the file in A, branch A should not look exactly as it did before the merge.

VonC
+1  A: 

It said there was one conflict, but I looked in the file and there were no conflict markers.

Without more details about what Git said (the message about conflict), I can only guess what happened. And I guess that Git said that there was textual (context) conflict that it was able to automatically resolve, or the conflict was of the tree-level variety like for example CONFLICT (delete/modify) where one side deleted file and the other side modified it.

I added the file, committed the change, and did the merge command again. "Already up-to-date" is the message I get.

If one branch in ancestor of the other, you would get fast-forward or up-to-date situation. Git refuses to do pointless merges unless explicitely requested.

If you want to redo a comitted merge, you must first undo it:

git reset --hard HEAD^
git merge B

Just in case you decided that the resolution you made was good: there is reflog (git reflog) just in case you change your mind.

Jakub Narębski
Are you sure about `HEAD^`? Wouldn’t that throw away the latest commit or branch “A” if the merge commit wasn’t created?
Bombe
I was taking about comitted (created) merge - I have edited response to clarify it. If the merge was not comitted it would be `git reset --hard HEAD` and `rm .git/MERGE_HEAD`.
Jakub Narębski