Question

I have a Git repository on my local machine that I cloned from my remote server. The Git repository that I cloned from is a bare repository.

One thing that still puzzles me is that, when changes have been made on origin and I do git pull origin master to update my local repository, git status then tells me that I’m X commits ahead of origin, where X is the number of commits I just pulled.

This is despite the fact that the commit logs are already identical.

So I always do a git push origin master afterwards, but I was just wondering if anybody could explain why this is necessary and whether I might not be doing this incorrectly.

It seems to me that if I just pulled the changes from origin, the two repos should be identical. So why am I told that I’m ahead of origin then? Is this related to the fact that it’s a bare repository?

Here’s the situation in a bit more detail, for clarity’s sake:

I have a bare git repo (hub) on a remote server. That repo has two clones: “dev” on my local machine and “staging”, on the same server as origin.

When I make changes on dev, I then git push origin master them to the bare “hub” repo. Then I log on to the remote server, cd to the “staging” repo and do git pull origin master to update “staging” from “hub”.

After I’ve done this, if I compare the hub and staging commit logs using git log --pretty=oneline I can see that they’re identical.

However, if I do git status in the “staging” directory I get the following:

$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
#
nothing to commit (working directory clean)

So then I usually do git push origin master from there, and I’m told:

$ git push origin master
Everything up-to-date

Everything works properly, but I just have this nagging question in my mind whether I didn’t make a mistake when setting the repos up, or whether this is normal…

Answer 1

According to man git-pull:

Merge into the current branch the remote branch next:

$ git pull origin next

This leaves a copy of next temporarily in FETCH_HEAD, but does not update any remote-tracking branches. Using remote-tracking branches, the same can be done by invoking fetch and merge:

$ git fetch origin
$ git merge origin/next

Emphasis is mine.

Basically, Git is telling you that your updated master is ahead of origin/master, which is a remote tracking branch for master. Since this tracking branch is not being updated by git pull origin master (as indicated in the man page), you are technically ahead of it. Calling git fetch origin updates your remote tracking branches and then you can merge that tracking branch in by hand (as indicated in the second manpage example).

AFAIK, if you do not specify a branch name with git pull (e.g. git pull origin), it will read .git/config for what it should fetch and the remote tracking branches will be updated.