Git status shows local branch ahead by X commits - should only be 1

Question

I've been searching and trying the various solutions here on stack and other forums but can't seem to get this issue resolved.

Git: Branch is ahead by X commits. Doesn't help doing git pull

Why does git say I am 40 commits ahead when I seem up to date and a push-pull (no files) fixes it?

why does it say "Your branch is ahead of origin/master by 857 commits" when I need to *pull* origin master

The overall issue is that I pulled a site checkout then had to make some local changes to the configs (database, api locations, etc.) and to prevent having to stash and re-applying each time I went ahead and committed the local changes to these files. I did all this under 1 local commit as "Local config commits". And at this time git status shows its ahead by 1.

root@web1 web]# git status
 On branch master
 Your branch is ahead of 'origin/master' by 1 commits.

However, over the past month we've been developing and fixing things. We all work off of our separate branches and merging back into a develop branch and then from there to master and so on. As things are ready, I pop into production and pull the changes down using 'git pull'. This seems to have been working well, however I noticed today that the status has now changed.

root@web1 web]# git status
On branch master
Your branch is ahead of 'origin/master' by 31 commits.

When I look at the git log against origin/master it seems like I'm seeing the merges coming in as local commits?

Small log snippet:

[root@web1 web]# git log origin/master..HEAD 
commit 336743eb411804487ad2f8a2e31701b094fb03f0
Merge: 58c8230 3478924
Author: root <root@web1.(none)>
Date:   Fri Feb 1 15:32:35 2013 -0500

    Merge branch 'master' of http://gitrepo.com/Site

commit 58c82303c523a3c9217dd677ba23582e168007cc
Merge: 6c9de32 0e1c327
Author: root <root@web1.(none)>
Date:   Fri Feb 1 15:04:58 2013 -0500

    Merge branch 'master' of http://gitrepo.com/Site

commit 6c9de32c2fed77e442e73389aa8041f067a23cc4
Merge: ff586b4 52a7ea9
Author: root <root@web1.(none)>
Date:   Fri Feb 1 14:38:08 2013 -0500

    Merge branch 'master' of http://gitrepo.com/Site

I would suspect my repo to have been properly 'fast-forwarded' and still be sitting 1 commit ahead after each pull. When doing the diff against origin/master you can see that I don't have many changes (seemingly) just the configs. This was from the original config changes and local commit.

[root@web1 web]# git diff origin/master..HEAD --name-only
application/config/api.php
application/config/config.php
application/config/database.php

I've tried the various links above and have tried the fetches, more pulls, etc. to no avail. Is there a way I can have my local repo properly fast-forward such that I only see the 1 local commit that I've made as being how var 'ahead' I am? I can't exactly push these changes out to master as this would cause those changes to then be pulled down to other installs. And then I guess after resolving this issue what is the best way of deploying, changing some configs and being able to continually update. From my understanding stash would work, but this in essence moves your changes out of place, then you can pull, and then re-apply but I can't afford the downtime of this small step especially if it involves having to sort out any merge conflicts.

Or, is there a way I can somehow pluck these files out of commit so that I can push to get everything sorted?

Answer 1

You can't do a fast-forward if you have a local commit that isn't in origin/master, it has to be a merge instead. A fast-forward is done when you are behind the remote, with no local changes. Since you have a local change, you can't fast-forward.

Maybe what you want is to rebase, which will temporarily undo your local commit, fast-forward to the tip of the remote branch, then reapply your local commit as the last commit.

git rebase origin/master

Or, if it's set as the default upstream, and you're not using an old version of Git, just

git rebase

Some people always use rebasing to pull from a remote, which is needed if the remote is configured to reject merge commits, but you should understand what rebasing does before using it willy-nilly, see http://git-scm.com/book/en/Git-Branching-Rebasing and http://darwinweb.net/articles/the-case-for-git-rebase