pull-only repo's 'git status' saying the branch is ahead of origin/master. Why?
So here's the situation:
$ git status
# On branch master
# Your branch is ahead of 'origin/master' by [x] commits.
#
There are several questions about this on SO already, but none seem to specifically address the type of scenario I have. This answer to one of the questions comes closest, but doesn't go into detail.
I'll just quote it verbatim:
If you get this message after doing a "git pull remote branch", try following it up with a "git fetch".
Fetch seems to update the local representation of the remote branch, which doesn't necessarily happen when you do a "git pull remote branch".
That tip does indeed work. But "doesn't necessarily happen?" Why not? I need to understand this. What is pull not doing?
I don't want to take over that question, so here's my scenario in detail:
Three computers involved. The Mac on which I develop, my home server where the git repo (i.e. origin/master) lives and a Webfaction account that pulls from that server.
I do commits and git push origin master only on the Mac. The only command that ever gets run on Webfaction as part of the normal workflow is git pull origin master (as part of a Fabric deployment script). I don't modify code there. I'm a lone developer, so neither does anyone else.
Every now and then I log in to Webfaction and check on things, including a git status. Inevitably, I always get the "Your branch is ahead..." message. Running git fetch makes the message go away.
I'm about to add git fetch to the Fabric script to be done with this issue, but I want to know why that needs to be done, especially on a pull-only clone of origin/master. I'm not deeply versed in Git though I use the basic functionality daily, so a newbie-friendly explanation would be appreciated.
Update as requested, the relevant bits from config:
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = git@[server_address]:[path/to/repo.git]
[branch "master"]
remote = origin
merge = refs/heads/master
Answer
Ok, so from the outset, you're doing everything correctly. I think the comment you added previously is a pretty good explanation:
In the simplest terms, "git pull" does a "git fetch" followed by a "git merge"
That's how I think of it. So you shouldn't have to call a git fetch after a straight up git pull - but, I can almost guarantee you, this works perfectly fine on anything EXCEPT the master branch.
In one of the linked posts, it said to remove the following line:
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/* <--- Remove this
And it should fix this issue - however, I cannot provide an explanation as to why this works. It's very hard to research, but I think that when you call fetch, your git config actually specifies what exactly to grab. When you're running pull, I'm not sure that it thinks the master is synced.
I can guarantee you that if you did this from another non-master branch, you wouldn't see this problem. Hopefully one of the git gurus can explain the fetch line in config in detail.
Furthermore, I would recommend running the following command instead which sets the HEAD for the remote repository to ensure it is in sync with your local one: git push -u origin master
Here's another interesting question:
Having a hard time understanding git-fetch
Ok, so I tested this on one of my workflows and found the following.
When you execute a git pull origin master on your remote server, there's a file in the .git/ directory that references where your HEAD is at. Two files to take note of:
ORIG_HEAD
FETCH_HEAD
You'll notice that your FETCH_HEAD is correct, but the ORIG_HEAD shows the old commit, hence the reason you're getting the Ahead by x. When you run git fetch, you'll actually correct the reference in ORIG_HEAD and everything is back to normal. I'm looking into how to change the fetch line in the config to fix this behavior.