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

On Tue, Sep 22, 2026 at 7:11 PM Junio C Hamano [off-list ref] 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 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.

Very interesting idea! I would like to suggest that the default branch
of the upstream is always included as well, even if it's not the
upstream of any branch yet.

I run this on every repo I work with

    git branch --set-upstream-to=upstream # upstream's default branch

and noticed on the shallow repo that it didn't work unless I first ran this

    git remote set-head upstream --auto

which was very annoying.



Harald