Re: [PATCH v1] remote.c: defer remote.<name>.followRemoteHEAD validation

["Matt Hunter" <m@lfurio.us>]

On Sun Oct 18, 2026 at 7:55 PM EDT, Colin Hinton wrote:
> Continuing from 86129fd (fetch.c: defer fetch.followRemoteHEAD
> validation), apply the same treatment to
> remote.<name>.followRemoteHEAD, which is still validated in
> handle_config(). That emits a warning for any command that loads the
> remote configuration, such as "git push" or "git remote -v", even
> though only "git fetch" ever consults the value.
>
> Store the raw string in struct remote instead, and resolve it lazily
> in do_fetch() through the get_follow_remote_head() helper introduced
> by 86129fd. This replaces the parsed follow_remote_head and
> no_warn_branch members, and the NEEDSWORK comment left behind by
> 86129fd is removed. "git remote set-head" now compares against the
> raw string to decide whether to rewrite "always" to "warn".
>
> Because both settings now go through the same parser,
> fetch.followRemoteHEAD accepts "warn-if-not-<branch>", which
> previously was only recognized for remote.<name>.followRemoteHEAD.
> Document it under fetch.followRemoteHEAD, drop the remote-specific
> paragraph, and add tests for the new fetch-level form.

I think a better justification is needed for this.  The intent behind
'warn-if-not-<branch>' makes much less sense in the context of the fetch
variable imo, and if it turns out to be problematic, reverting support
later will be tricky.

See previous discussion:
<20260611060123.GA2187173@coredump.intra.peff.net>
<DJ6IBPYNOTTY.3QKEZQ28P713V@ferdinandy.com>

>
> Messages for an unrecognized or missing value no longer name the
> fetch. prefix, as the helper now serves both the fetch-level and
> the remote-level setting.

I agree with Junio that this should be addressed.

>
> @@ -139,6 +139,9 @@ remove the value for the `fetch.bundleCreationToken` value before fetching.
>  `warn`;;
>  	Display a warning if the remote advertises a different `HEAD` than what is
>  	set locally.  Behaves like "create" if the local symbolic-ref doesn't exist.
> +`warn-if-not-<branch>`;;
> +	Like "warn", but do not display the warning if the remote's `HEAD`
> +	is `remotes/<name>/<branch>`.
>  `always`;;
>  	Silently update `remotes/<name>/HEAD` whenever the remote advertises a new
>  	value.

I like the style change from $branch to <branch>

> @@ -1978,14 +1982,10 @@ static int do_fetch(struct transport *transport,
>  		if (transport->remote->fetch.nr) {
>  			refspec_ref_prefixes(&transport->remote->fetch,
>  					     &transport_ls_refs_options.ref_prefixes);
> -			/*
> -			 * See remote.c's handling of remote.<name>.followRemoteHEAD
> -			 * for the analogous, still-unresolved case.
> -			 */
> -			if (transport->remote->follow_remote_head)
> -				follow_remote_head = transport->remote->follow_remote_head;
> +			if (transport->remote->follow_remote_head_seen)
> +				follow_remote_head = get_follow_remote_head(transport->remote->follow_remote_head_raw, &no_warn_branch);
>  			else if (config->follow_remote_head_seen)
> -				follow_remote_head = get_follow_remote_head(config->follow_remote_head_raw);
> +				follow_remote_head = get_follow_remote_head(config->follow_remote_head_raw, &no_warn_branch);

A couple more overly-long lines

>  			else
>  				follow_remote_head = BUILTIN_FOLLOW_REMOTE_HEAD_DFLT;
>  		}

By the way, I had previously made a comment about moving the definition
of 'enum follow_remote_head_settings' over to the fetch file since that
is now the only place it is relevant.  Do you think it's worth changing?