From: Phillip Wood <phillip.wood123@gmail.com>
Date: Wed, 23 Sep 2026 15:19:06 GMT
Subject: Re: [PATCH] fetch: add config to avoid fetching every branch in shallow repo
Message-ID: <05d0e6e0-e156-4a2a-95a0-4986ab18ef49@gmail.com>
In-Reply-To: <xmqqh5jhfbyw.fsf@gitster.g>

On 22/09/2026 18:11, Junio C Hamano wrote:
> Phillip Wood <phillip.wood123@gmail.com> writes:
> 
>> 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.