Re: [PATCH] fetch: add config to avoid fetching every branch in shallow repo

On 22/09/2026 18:11, Junio C Hamano wrote:

Phillip Wood [off-list ref] writes:

quoted

I think the sparse checkout is irrelevant? It is unclear to me if this
is talking about a case where there are many branches in the remote
repository and only one of them was cloned, then adding a second remote
created a wildcard fetch refspec; or if there are intentionally lots of
remote tracking branches in the local repository and you don't want to
wait for them all to update. If it is the former then we should think
how we can improve the behavior of "git remote add" in a sparse
repository to prevent it adding a wildcard fetch refspec and instead
setup the new remote to fetch only the branch(es) we're interested in.

Very good suggestions.  "Avoid wildcards" is easy, but designing a
suitable alternative ("only the ones we are interested in") may be
harder.

Perhaps we want to have something similar in spirit to the
"matching" mode 'git push' has, where the set of local branches we
have defines the set of branches we are interested in?  That is,
when 'remote.*.fetch' is configured to signal that special mode,
'git fetch' would:

  - Find each local branch that has its '@{upstream}' set to a branch
    at the remote we are fetching from.

  - Fetch these branches at the remote that our local branches care
    about.

I can see that being useful fetch mode for a remote that we've already 
fetched from, but for a newly added remote there will be no local 
branches with their upstream set to it because "git branch 
--set-upstream-to" fails if the upstream does not already exist. So I 
like the idea for fetching from existing remotes, but it leaves us with 
a chicken-and-egg problem when adding new remotes, so I'm not sure how 
it would work in practice.

Thanks

Phillip
  > I said "in spirit" above, and I find it tempting to use ':' and '+:'

as the special '<refspec>' to trigger this mode, to mimic what 'git
push' does when using the local branches we have as the set of
branches we care about.  But there are important differences:

  (1) The correspondence between local and remote-tracking branches
      is not one-to-one, as you can fork multiple local topics out
      of the same upstream branch.  Maybe our 7 local branches build
      on top of only 2 branches we fetch from the remote, for
      example.

  (2) Corollary.  Unlike the matching mode in 'git push' where local
      branch 'B' is used to update branch 'B' at the remote (if it
      exists), this new mode in 'git fetch' only uses local branches
      as a guide to determine which branches to fetch from the
      remote.  If our local branch 'B' builds on top of branch 'U' at
      the remote, it is branch 'U' we fetch and store as the
      'refs/remotes/R/U' remote-tracking branch, where 'R' is the
      remote, and 'B' as the name does not get anywhere in the
      picture.

In other words, this is not "matching" at all, even though it takes
inspiration from it.  I do not know what it should be called, but I
think it would be a useful addition.

Thanks.