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

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.

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.

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.

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.

This may seem trivial but I have seen many people miss it and just do git merge while on the parent branch. This will automatically result to "Already up-to-date" message.

The merge command should be git merge branchNametoMergeFrom

For instance assumming you have 2 branches branchA & branchB and you need to merge B into A. You need to first checkout to BranchA and then use the merge command while specifing the branch to merge from in this case branchB.

Therefore the command should NOT be just git merge but should BE git merge branchB.

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.

I have a way of re-merging it, my scenario is that I need to merge a release branch to master.

Condition: the release branch code is golden. meaning master is incorrect while release branch is correct.

Symptom: When merge release to master, the incorrect part in master is not updated with the parts in release.

here is the steps, disclaimer: my knowledge of git is limited, there must be a better way of achieving it.

1. checkout release branch, do a pull. [Commit #A]
2. merge latest master to release [Commit #B] (incorrect file will write to release branch)
3. do a reverse commit of the [Commit #B] BUT keep it in stage (if the reserve commit is committed as [Commit #C] then do a soft reset to Commit #B) (this essentially reverse the incorrect files)
4. edit the files, check whether these are correct, discard the unwanted ones (if there is any)
5. stash the changes in step 4 [Stash{X}]
6. reset release back to Commit #A (same as remote)
7. merge latest master to release again [Commit #D] (diff hash should be the same but commit hash is different than b)
8. Apply stash {x}
9. Commit and merge to master.

EDIT: step 9 can happen at local just to see whether the intended parts has been applied if you happen to have to use a pr at remote.

I too had this issue. I wanted to update my feature branch with changes that were in the main branch, but since it was already merged and the conflicts addressed, the changes would not come and it said "already up to date."

Here is the way to get the changes regardless of merge history (CAREFUL: this clears the working tree, so git stash or commit your changes before):

git checkout your-feature-branch
git checkout branch-with-changes -- .

The -- . argument for git checkout will checkout all the FILES from the other branch, while still checked out into the same branch. Then you can add and commit as you like.

I also used this in conjunction with git add -p Which will make you able stage any changes in "hunks." It asks y/n if you want to stage any hunks of lines that changed, meaning you can leave unwanted changes out of your next commit.

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!