Re: [PATCH v6] fetch.c: defer fetch.followRemoteHEAD validation

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 7, 2026, 16:50 UTC
Message-ID: <xmqqece1a206.fsf@gitster.g>
In-Reply-To: <20261006032258.6561-1-colinlewishinton@gmail.com>

Colin Hinton <colinlewishinton@gmail.com> writes:

Show 22 quoted lines

> The value of the fetch.followRemoteHEAD configuration variable is
> validated while the configuration file is being parsed, which
> produces a warning even when this particular "git fetch" invocation
> will never consult it.
>
> Store the raw config string instead, and resolve/validate it lazily
> at the one place in do_fetch() that actually uses it, so a mistyped
> value only warns, and a missing value only dies, when this fetch
> would have consulted it.
>
> remote.c's handle_config() has the same problem for
> remote.<name>.followRemoteHEAD, but is left unaddressed here since
> it touches shared remote-parsing infrastructure used well beyond
> fetch. Leave a NEEDSWORK comment at remote.c:handle_config()
> that has a defect similar to what is fixed by this patch,
> so the remaining scope is easy to find for a follow-up patch.
>
> Signed-off-by: Colin Hinton <colinlewishinton@gmail.com>
> ---
>  builtin/fetch.c | 73 +++++++++++++++++++++++++------------------------
>  remote.c        |  7 +++++
>  2 files changed, 44 insertions(+), 36 deletions(-)

OK. We agreed to punt on remote.*.followRemoteHEAD in this topic, even though it may leave them inconsistent with what the improved code does to fetch.followRemoteHEAD, this should be good enough.

One usability regression is that the users will no longer see the config machinery to report which line of what configuration file has the problematic setting, but nobody seemed to bring it up during these iterations. We have done similar conversions like this on other configuration values in the past, and haven't heard people complain about lack of source:line information, either. So it probably does not matter.

Let's mark the topic for 'next'.

Thanks.