Git repo on a machine with zero commits is ahead of remote by 103 commits.. !

Hi,

I am using a simple git based deployment for my rails app and here is my setup and current status:

1) Git repo initialized on my local development machine with a sample file.
2) Pushed to remote repo on Github.com
3) Subsequent pushes and pulls made from local development machine
4) Repository cloned on the deployed machine
5) Subsequent pulls made from the deployed machine (but no commits or
pushes are made on this machine)

Now when I run "git status" on the deployed machine it says :

# On branch master # Your branch is ahead of 'origin/master' by 103 commits.

git pull origin master -- says it is Already up to date

git log -- appropriately shows till the latest commit

however

git log orign/master -- shows commits only till Jan 8th.

also

git rev-parse origin/master -- give different SHA1 values on my development machine and the deployed machine.

Questions:
===========
1) Why does "git status"  say that the local repo on the deployed
machine (where no commits are made) is ahead of the remote by 103
commits? (This number, 103, increases with every "git pull origin
master" and very likely the change is equal to the number of commits
pulled)

2) Why is "git log orign/master" stuck at a Jan 8th commit?

* How can I set these right?

Even with these anomalies, "git pull origin master" on the deployed machine seems to be working just fine, in terms of the right revisions of files being pulled in and all that.

Any help in understanding what caused these anomalies and suggestions to fix then would be very helpful. Kindly let me know if any more information is needed.

Am 1/25/2011 6:48, schrieb Srirang Doddihal:

This 'git pull' is very explicit. I.e., you specify the remote and the branch; in this case, no remote-tracking branches, like origin/master, are updated.

Since you cloned the repository (I assume without any special options), you already have a configuration such that you can use this shorter command:

   git pull

to merge origin's master into your local master. As a side-effect, it also updates origin/master.

-- Hannes

On Tue, Jan 25, 2011 at 12:48 AM, Srirang Doddihal <om.brahmana@gmail.com> wrote:

git status is comparing refs/heads/master, aka master, to its remote-tracking branch, refs/remotes/origin/master, aka origin/master.

master is ahead of origin/master because you've been updating the former but not the later, with your pull invocation.

Because you've been saying "git pull origin master", git has been doing the following:

- contacting origin and fetching all commits in its master not in your
local repo
- locally updating FETCH_HEAD with the results of that fetch
- performing a merge operation of FETCH_HEAD into your local master
- because you haven't made any local commits, that is a fast-forward operation
- updating your work tree

However, git is not updating your remote-tracking branch (origin/master).

Just do a "git pull" or "git pull origin". By not explicitly giving pull a branch, it consults two configuration variables in your .git/config for the currently checked out branch to figure out what you want it to do, namely:

  branch.master.remote
  branch.master.merge

Also in this case, it updates the origin/master remote-tracking branch.

(I think there has been previous discussion about this behavior - it seems broken to me that "git pull <remote> <branch>" doesn't update the corresponding remote-tracking branch <remote>/<branch> in the case where "git pull [<remote>]" would normally do so according to that repo's .git/config.)

j.

Thank you Jay and Johannes. A 'git pull' solved the problem and I now understand git a little better. :)