From: D. Ben Knoble <ben.knoble@gmail.com>
Date: Wed, 23 Sep 2026 16:55:07 GMT
Subject: Re: [PATCH] fetch: add config to avoid fetching every branch in shallow repo
Message-ID: <CALnO6CA2DXvyOO+fu04sozg2=E0JoymAqyhs_heHzExgRSEzVw@mail.gmail.com>
In-Reply-To: <xmqq5wzwc76w.fsf@gitster.g>

On Wed, Sep 23, 2026 at 11:49 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> Phillip Wood <phillip.wood123@gmail.com> writes:
>
> >> 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.
>
> Just like with "git push there :", you prime the pump by explicitly
> doing something (for "push", you do "git push there mine" to express
> your preference to work with branch 'mine' and share it with the
> remote).
>
> So if we are to allow customizing the refspec used for fetch with
> "git remote add", you might do:
>
>     $ git remote add --fetch=: second https://ho.st/git/second
>
> which creates:
>
>         [remote "second"]
>                 url = https://ho.st/git/second
>                 fetch = :
>
> (Note: I am not sure if ":" is a good special token to express this
> mode of fetching, as I said earlier).
>
> Your initial "git fetch second" without any other arguments will be
> a no-op.  You may decide to work on top of their 'main' branch by
> running:
>
>     $ git fetch second main:refs/remotes/second/main

I've wanted something similar for notes, so allow me to interject from
the sidelines: it would be even nicer to still have the ability to map
fetches (so that "git fetch second main" did the right thing, creating
a useful remote tracking branch with the usual hierarchy;
configurable, of course) on top of this. So, the first "git fetch
second" does nothing, but "git fetch second main" + creating the
branch does as you describe.

>     $ git checkout -b topic -t second/main
>
> At that point, the local branch 'topic' is built on top of their
> 'main' branch by having its @{upstream} set to that remote-tracking
> branch.  After that, running "git fetch" will update 'second/main' and
> no other remote-tracking branch.


-- 
D. Ben Knoble