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

[Junio C Hamano <gitster@pobox.com>]

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