Re: confused about remote branch management

> Ross Boylan <ross@biostat.ucsf.edu> 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".