Re: confused about remote branch management

Ross Boylan <ross@biostat.ucsf.edu> writes:

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".