Hilco Wijbenga <hilco.wijbe...@gmail.com> writes:
>> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
