From: Harald Nordgren <haraldnordgren@gmail.com>
Date: Tue, 22 Sep 2026 21:40:09 GMT
Subject: Re: [PATCH] fetch: add config to avoid fetching every branch in shallow repo
Message-ID: <CAHwyqnVwQRv3TKDtkZ2iAO3hNtOeC464qdv6GCxFYE_v-rLq6Q@mail.gmail.com>
In-Reply-To: <xmqqh5jhfbyw.fsf@gitster.g>

On Tue, Sep 22, 2026 at 7:11 PM Junio C Hamano <gitster@pobox.com> 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 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