Git merge reports "Already up-to-date" though there is a difference

I have a git repository with 2 branches: master and test.

There are differences between master and test branches.

Both branches have all changes committed.

If I do:

git checkout master

git diff test

A screen full of changes appears showing the differences. I want to merge the changes in the test branch and so do:

git merge test

But get the message "Already up-to-date"

However, examining files under each different branch clearly shows differences.

What's the problem here and how do I resolve it?

The message “Already up-to-date” means that all the changes from the branch you’re trying to merge have already been merged to the branch you’re currently on. More specifically it means that the branch you’re trying to merge is a parent of your current branch. Congratulations, that’s the easiest merge you’ll ever do. :)

Use gitk to take a look at your repository. The label for the “test” branch should be somewhere below your “master” branch label.

Your branch is up-to-date with respect to its parent. According to merge there are no new changes in the parent since the last merge. That does not mean the branches are the same, because you can have plenty of changes in your working branch and it sounds like you do.

Edit 10/12/2019:

Per Charles Drake in the comment to this answer, one solution to remediate the problem is:

git checkout master
git reset --hard test

This brings it back to the 'test' level.

Then do:

git push --force origin master

in order to force changes back to the central repo.

This often happens to me when I know there are changes on the remote master, so I try to merge them using git merge master. However, this doesn't merge with the remote master, but with your local master.

So before doing the merge, checkout master, and then git pull there. Then you will be able to merge the new changes into your branch.

Say you have a branch master with the following commit history:

A -- B -- C -- D

Now, you create a branch test, work on it, and do 4 commits:

E -- F -- G -- H
/
A -- B -- C -- D

master's head points to D, and test's head points to H.

The "Already up-to-date" message shows up when the HEAD of the branch you are merging into is a parent of the chain of commits of the branch you want to merge. That's the case, here: D is a parent of E.

There is nothing to merge from test to master, since nothing has changed on master since then. What you want to do here is literally to tell Git to have master's head to point to H, so master's branch has the following commits history:

A -- B -- C -- D -- E -- F -- G -- H

This is a job for Git command reset. You also want the working directory to reflect this change, so you'll do a hard reset:

git reset --hard H

This is what works for me. Let's say you have branch1 and you want to merge it into branch2.

You open git command line go to root folder of branch2 and type:

git checkout branch1
git pull branch1
git checkout branch2
git merge branch1
git push

If you have conflicts, solve them before git push.

git merge origin/master instead git merge master worked for me. So to merge master into feature branch you may use:

git checkout feature_branch
git merge origin/master

Be sure to checkout the branch you want to merge first and then pull it (so your local version matches the remote version).

Then checkout back to your branch you want to do the merge on and your git merge should work.

> A merge is always between the current HEAD and one or more commits (usually, branch head or tag),
and the index file must match the tree of HEAD commit (i.e. the contents of the last commit) when it starts out.
In other words, git diff --cached HEAD must report no changes.

> The merged commit is already contained in HEAD. This is the simplest case, called "Already up-to-date."

That should mean the commits in test are already merged in master, but since other commits are done on master, git diff test would still give some differences.

This happens because your local copy of the branch you want to merge is out of date. I've got my branch, called MyBranch and I want to merge it into ProjectMaster.

_>git status
On branch MyBranch-Issue2
Your branch is up-to-date with 'origin/MyBranch-Issue2'.

nothing to commit, working tree clean

_>git merge ProjectMaster
Already up-to-date.

But I know that there are changes that need to be merged!

Here's the thing, when I type git merge ProjectMaster, git looks at my local copy of this branch, which might not be current. To see if this is the case, I first tell Git to check and see if my branches are out of date and fetch any changes if so using, uh, fetch. Then I hop into the branch I want to merge to see what's happening there...

_>git fetch origin

_>git checkout ProjectMaster
Switched to branch ProjectMaster
**Your branch is behind 'origin/ProjectMaster' by 85 commits, and can be fast-forwarded.**
  (use "git pull" to update your local branch)

Ah-ha! My local copy is stale by 85 commits, that explains everything! Now, I Pull down the changes I'm missing, then hop over to MyBranch and try the merge again.

_>git pull
Updating 669f825..5b49912
Fast-forward

_>git checkout MyBranch-Issue2
Switched to branch MyBranch-Issue2
Your branch is up-to-date with 'origin/MyBranch-Issue2'.

_>git merge ProjectMaster
Auto-merging Runbooks/File1.ps1
CONFLICT (content): Merge conflict in Runbooks/Runbooks/File1.ps1

Automatic merge failed; fix conflicts and then commit the result.

And now I have another issue to fix...

This happened to me because strangely GIT thought that the local branch was different from the remote branch. This was visible in the branch graph: it displayed two different branches: remotes/origin/branch_name and branch_name.

The solution was simply to remove the local repo and re-clone it from remote. This way GIT would understand that remotes/origin/branch_name>and branch_name are indeed the same, and I could issue the git merge branch_name.

rm <my_repo>
git clone <my_repo>
cd <my_repo>
git checkout <branch_name>
git pull
git checkout master
git merge <branch_name>

happend to me and was sent to this page, not sure if I had the same scenario, but mine was me trying to "re-merge" that "test" branch.

So I previously merged it but I intentionally exclude some specific changes during that merge, so it clearly has some diff between branches. I was then trying to re-merge it because I realize/forget that I should have and wanted to add a particular change/file that I have previously excluded and I was hoping if I do a merge again would show all changes that I excluded before, but I was wrong and I get the "Already up-to-date" message instead.

Upon reading @Bombe's comment/answer, he is right, and git I think behaves that way, so what I did was to make hard backup of the files on test branch, then checkout the master branch and manually paste the files in it and commit it as if it was new changes.

am not sure if this is the right way or could help others having this same issue, but it did provide solution to my particular case.

If merging branch A into branch B reports "Already up to date", reverse is not always true. It is true only if branch B is descendant of branch A, otherwise branch B simply can have changes that aren't in A.

Example:

1. You create branches A and B off master
2. You make some changes in master and merge these changes only into branch B (not updating or forgetting to update branch A).
3. You make some changes in branch A and merge A to B.

At this point merging A to B reports "Already up to date" but the branches are different because branch B has updates from master while branch A does not.

Faced this scenario using Git Bash.

Our repository has multiple branches and each branch has a different commit cycle and merge happens once in a while. Old_Branch was used as a parent for New_Branch

Old_Branch was updated with some changes which required to be merged with New_Branch

Was using below pull command without any branch to get all sources from all branches. > git pull origin

Strangely this doesn't pull all the commits from all the branches. Had thought it so as the indicated shows almost all branches and tags.

So to fix this had checked out the Old_Branch pulled the latest using > git checkout Old_Branch > > git pull origin Old_Branch

Now checked out New_Branch

>git checkout New_Branch

Pulled it to be sure

> git pull origin New_Branch > > git merge Old_Branch

And viola got conflicts to fix from Old_Branch to New_Branch :) which was expected

I had the same problem. I had changes in the remote and it was still showing "Already up to date". Recloning the repository fixed the problem for me.

The same happened to me. But the scenario was a little different, I had master branch, and I carved out release_1 (say) out of it. Made some changes in release_1 branch and merged it into origin. then I did ssh and on the remote server I again checkout out release_1 using the command git checkout -b release_1 - which actually carves out a new branch release_! from the master rather than checking out the already existing branch release_1 from origin. Solved the problem by removing "-b" switch

Silly but it might happen. Suppose your branch name is prefixed with an issue reference (for example #91-fix-html-markup), if you do this merge:

$ git merge #91-fix-html-markup

it will not work as intended because everything after the # is ignored, because # starts an inline comment.

In this case you can rename the branch omitting # or use single quotes to surround the branch name: git merge '#91-fix-html-markup'.

I committed the changes in my current branch, and then the merge from the Origin branch worked.

I've fixed such problem with rebasing current branch on itself.

I'm not sure exactly what the problem was in my case, but the root of the issue seemed to be that with branchB checked out, I could not pull the latest changes from branchA...

I had to checkout branchA, pull, then checkout branchB and merge branchA for it to work like expected.

try following commands

git checkout master
git pull
git fetch --all
git rebase --abort

git checkout test
git pull
git reset --hard  
git merge origin master

Mostly with rebase or already taking merge branch has shadow history, with clearing or reseting branch will help to get the merge things in files.

Hi, I have created a git alias that I called git remerge that helps to solve the problem.

1. It will first git merge <FEATURE-BRANCH-NAME>.
2. And then will force to re-calculate all the conflicts of the files that differ between the branches.

You are able to use it here!

If you have any suggestions or you want to contribute to the project, you are more than welcome!