Re: [PATCH v3 2/4] fetch: infer branches to fetch from a refmap-only remote

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 25, 2026, 23:26 UTC
Message-ID: <xmqqo6dksyj2.fsf@gitster.g>
In-Reply-To: <4ec508a223a19c3aac8cf368e3dc0314ff6de479.1790333402.git.gitgitgadget@gmail.com>

"Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:

Show 14 quoted lines

> From: Harald Nordgren <haraldnordgren@gmail.com>
>
> Configuring remote.<name>.refmap without remote.<name>.fetch used to
> make a refspec-less "git fetch <name>" fail with "--refmap option is
> only meaningful with command-line refspec(s)", since a refmap only
> says where to put fetched refs, not what to fetch.
>
> Make that case infer what to fetch: the local branches whose
> @{upstream} is already on that remote, plus the remote's default
> branch, which is always included so it is available even before
> anything is set up to track it. This lets a remote be configured to
> fetch only the branches actually in use, without listing them by
> hand in remote.<name>.fetch, and without needing to touch the
> command line every time.

You may not necessarily be interested in what the remote's HEAD is pointing at.

 - You may only be working on top of their 'maint' and their 'next'
   without ever touching their 'master'.  It would be rude for Git
   to decide for you to fetch their 'master', which you have no use
   for, without being asked at all.

 - Or you may be very much interested in their 'master' that is
   pointed at by their HEAD.  In such a case, you would have your
   local branch that is forked from their 'master' *anyway*, and
   you'll get one, without special casing their HEAD.

Especially since we are about to add the knob to trigger this mechanism to "git remote add", presumably this is to be used for second and later remotes. The primary remote may already be supplying "refs/heads/master -> refs/remotes/origin/master" when the repository was made with "git clone --shallow --single-branch" or something like that. That makes it doubly dubious to assume that the branch the HEAD of this secondary remote points at is so special and everybody that does "git remote add" wants to interact with it.

Show 16 quoted lines

> diff --git a/Documentation/fetch-options.adoc b/Documentation/fetch-options.adoc
> index 538914bc6e..c973a07caf 100644
> --- a/Documentation/fetch-options.adoc
> +++ b/Documentation/fetch-options.adoc
> @@ -245,8 +245,12 @@ endif::git-pull[]
>  	command-line arguments. See section on "Configured Remote-tracking
>  	Branches" for details.
>  +
> -`remote.<name>.refmap` provides the default value for this option, the
> -same way `remote.<name>.fetch` provides the default refspecs to fetch.
> +When a refmap is active (from `--refmap` or `remote.<name>.refmap`) but
> +there is nothing to fetch, neither on the command line nor from
> +`remote.<name>.fetch`, Git infers what to fetch from the local branches
> +whose `@{upstream}` is on that remote, plus the remote's default branch,
> +which is always included so that it is available even before anything
> +is set up to track it.

So, I would "plus the remote's default branch, which is always included".

Show 12 quoted lines

> diff --git a/builtin/fetch.c b/builtin/fetch.c
> index 7651b41139..c8ce89cf30 100644
> --- a/builtin/fetch.c
> +++ b/builtin/fetch.c
> ...
> +		if (default_branch_dst) {
> +			struct refspec_item head_item = { .force = 1 };
> +
> +			head_item.src = xstrdup("HEAD");
> +			head_item.dst = default_branch_dst;
> +			get_fetch_map(remote_refs, &head_item, &tail, 1);
> +			free(head_item.src);

This adds a fetch map entry with rm->name = "HEAD" and rm->peer_ref->name = "refs/remotes/second/main". Because "HEAD" does not begin with "refs/heads/", the report after fetch says

	* [new ref]    HEAD  -> second/main

instead the usual

	* [new branch] main  -> second/main

doesn't it? If we do not force-include HEAD, the code would be simplar and we won't have to worry about this.

Thanks.