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

On Wed, Sep 23, 2026 at 11:49 AM Junio C Hamano [off-list ref] wrote:

Phillip Wood [off-list ref] writes:

quoted

quoted

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