Git aims to stop fetching every branch in shallow clones

Shallow Git clones that only care about a few branches still pay a steep price on ordinary fetch and pull. By default a remote is wired to grab every branch the server advertises, so on a repository with a large branch set the negotiation can take minutes or appear to hang even when the user is working on a single line of development.

Harald Nordgren has proposed a series that untangles two concerns long packed into one remote setting: which refs to fetch, and where those refs are stored locally. A new per-remote fetchRefmap value supplies the storage mapping that the existing --refmap option already offered on the command line. When that mapping is set and nothing else names what to grab, a refspec-less fetch infers the set from local branches whose upstream already lives on that remote. Configured fetch refspecs, when present, still decide what is fetched; the refmap only remaps them.

git remote add gains a --limited-fetch option that installs this mapping instead of the usual wildcard fetch refspec. In an already shallow repository that mode becomes the default when adding a remote (unless the caller opts out or already names tracks or a mirror), so a second remote no longer quietly undoes the point of cloning shallow in the first place.

Git maintainer Junio C Hamano and contributor Phillip Wood pressed for a clean split between "what to fetch" and "where to store it." Wood argued that letting one variable imply both would repeat the inflexibility of today's fetch config. Hamano recalled that the original command-line --refmap design was meant to keep those choices independent, and that future heuristics for choosing refs should not be locked to the mere presence of a refmap. Nordgren's later revisions rename the setting, cover the combined fetch-plus-refmap case, and document the inference path accordingly. The work is still under review on the Git development list.