Re: Your branch and 'origin/master' have diverged

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 14, 2012, 22:35 UTC
Message-ID: <7v628l85l4.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CAE1pOi3a9ZMFfJ2qjkaZ_O-DuQa3xkKtsMU5GYYUuiwcRoFjbg@mail.gmail.com>

Hilco Wijbenga <hilco.wijbenga@gmail.com> writes:

Show 16 quoted lines

>> I meant something else than Junio hinted at.  Saying
>>
>>   git fetch origin master
>>   # or by extension
>>   git pull origin master
>>
>> does not update the origin/* namespace, not even origin/master.  All
>> fetching happens only into FETCH_HEAD.  This leads to confusion such as
>> yours because origin/master and thus the upstream tracking displays will
>> not know about the change.
>
> I'll say. Now I'm really confused.
>
> If what you say is true then what is updating origin/master? I've been
> using "git pull" daily for over a year and origin/master is definitely
> getting updated (at least according to gitk).

Now it is really the time for you to go back to "git fetch --help" and read up on refspecs.

With

    $ git fetch origin

you are not telling "fetch" what to fetch, so it goes to your .git/config and finds remote.origin section to find what refspec to use. They would say something like

	[remote "origin"]
        	url = ...
                fetch = refs/heads/*:refs/remotes/origin/*

meaning (see the manual) "fetch all the branches there, store them with the corresponding name under refs/remotes/origin".

With

    $ git fetch origin master

you are overiding the refspec in .git/config and explicitly saying "I want to fetch the master branch, but do not want to update anything with it". It is a short-hand for

    $ git fetch origin refs/heads/master

which in turn is a short-hand for

    $ git fetch origin refs/heads/master:

If you wanted to update the tracking ref, you would use a refspec with non-empty strings on the both sides of colon, i.e.

    $ git fetch origin master:refs/remotes/origin/master