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

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

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