Why after merge does GIT say "Already up-to-date", but differences between branches still exist?

Reverting Merges vs. Resetting Merges

My guess is that you actually are Already-up-to-date.

The problem is that git revert doesn't undo the merge, it only undoes the changes that the merge brought with it. When you create a merge commit, you're combining the commit histories of those two branches.

Merging

     develop        |A---B---C \       \  E---F---M          |      newfeature

In the case above, develop is merged into newfeature, creating the M commit. If you were to run git log newfeature you would see all the commits from both branches, however from the perspective of the newfeature branch, all those changes were performed by the M commit.

Reverting

The git revert command does not remove any commits, instead it creates a new commit that undoes the changes that the commit contained. For example if you had a commit containing this diff...

-This is the old sentence.+This is the new sentence.

Then reverted this, the revert command would create a new commit that just preformed the opposite diff, it simply flips the signs.

-This is the new sentence.+This is the old sentence.

This is really useful for undoing damage caused by commits that other developers already have. It moves history forward rather than changing history.

Reverting Merges

However, in the context of a non-fastforward merge it may have an undesired effect.

     develop        |A---B---C \       \  E---F---M---W              |         newfeature

Assuming W is a reversion commit, you can see how running git log newfeature will still include all the commits from the develop branch. As a result, additional merges from develop will no work, because it doesn't see anything missing from your branch.

Using git reset instead of revert.

In the future, you might want to consider using git reset --hard <ref> (where <ref> is the commit hash of the merge) to undo a merge if that merge has not been shared with other developers. In the example above, after having created merge commit M, running the command git reset --hard F would result in the following.

     develop        |A---B---C \       \  E---F---M      |  newfeature

As you can see this technique doesn't obliterate the commit as some people tend to think, it simply moves your branch back to the commit you selected. Now if you ran git log newfeature you would only get commit F, E, and A. Now the merge is actually gone from your branches history, so a later attempts to re-merge in develop will cause no problems.

This method is not without its complications. Realize that you are now modifying history, so if the newfeature branch was pushed to a remote branch after the M merge was made, then git is going to think you are simply out of date and tell you that you need to run git pull. If its just you working on that remote branch, then feel free to force-push - git push -f <remote> <branch>. This will have the same effect of the reset but on the remote branch.

If this branch is being used by multiple developers, who would have by now already pulled from it - then this is a bad idea. This is the very reason git revert is useful, because it undoes changes without changing the actual history.

Using reset on history is really only on option for commits that have not been shared.

The solution - reverting the reversion.

If the merge commit has already been shared, then the best approach is probably to use git revert on that merge. However as we said before, you can not then simply merge the branch back in and expect all the changes from that branch to re-appear. The answer is to revert the revert commit.

Lets say you did some work on the develop branch after having revered the merge in newfeature. Your history would look something like this.

         develop            |A---B---C---D \       \  E---F---M---W              |         newfeature

If you merge develop into newfeature now, you would only get D because its the only commit that is not already part of the history of the newfeature branch. What you also need to do is revert that W commit - git revert W should do the trick followed by git merge develop.

                 develop                    |A---B---C-----------D \       \           \  E---F---M---W---M---G                      |                 newfeature

This restores all the changes made by the original merge commit - which were actually made by C and B but were reverted in W, it then brings in D via a new merge commit G I would recommend reverting the revert before merging in the recent changes to develop, I suspect doing it in that order will have a lower chance of triggering conflicts.

TL;DR

Reverting creates a 'revert commit'. When undoing a revert, you need to run the revert command on the revert commit that was created when you reverted the first time. It should be easy enough to find, git tends to auto-comment on reverts so that they start with the word "Reverted".

git revert <commit>

Found a hacky solution. But it works.

Whatever eddiemoya has answered is totally helpful. Thanks a lot for explanation. I encountered the similar situation. Where, I was able to see a lot of content in git diff <branch> but git merge was saying already up to date.

And I was not able to find the exact revert commit due to lot of reverts in the log. (Yeah bad thing. Shouldn't have happened in the first place)

Solution

git checkout branchX -- .

This will stage all the changes from branchX to my current branch. Use on of your favorite git client, unstage and revert whatever is not intended.

Make a new commit and be happy :)

I've met the same situation too. What I have done is I just created a new branch and cherry picked all desired files from different commits and then merged this branch.

The actions looks like this:

• created a new branch
• used git cherry-pick -n xxxxxxx to get desired files from different commits
• then commit these files git commit -m 'Your commit message'
• then merge this cherry picked branch into desired branch