Ross Boylan <> writes:

>> Either
>>      git fetch origin master:refs/remotes/origin/master
> Great; that works.
> Is that procedure supposed to be the usual way I track upstream in this
> (1.7) version of git?  It seems arcane.

No, and no.  The command is designed so that most of the time you
can just say "git fetch<ENTER>" without anything extra, which will
let the configured remote.*.fetch to kick in as the default refspec
to slurp updates to all the branches.  This is because the branches
of a single project are supposed to be related, and a single "git
fetch" goes over a single network connection, establishment of which
is expected to be a large overhead.  Letting a single invocation of
"fetch" to slurp updates to _all_ the branches is supposed not to be
too much overhead over grabbing updates to everything (let alone
invoking a "git fetch" per each individual branch), and is the
normal mode of operation.

A single-shot "git fetch origin master" to explicitly decline
following of everything other than 'master' *is* the special case.

And it was a very conscious design decision not to molest the remote
tracking branch when this kind of explicit command line request is
made, so that you do not lose track of what commit you _saw_ before
you ran the command.  That way "git log origin/master..FETCH_HEAD"
can be used to inspect what got changed since you fetched last time.

Over the years, with reflogs enabled for everybody, preserving the
remote tracking branches when the user does not explicitly ask to
store the result has become much less important.  For this reason,
modern Git applies, when it sees "git fetch origin master", the
configured remote.*.fetch as refmap to map the name "master",
i.e. the only branch you are fetching, to the remote tracking branch
you use to store the result, i.e. "refs/remotes/origin/master".
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to