Re: [PATCH 6/7] fetch: add configuration option fetch.followRemoteHEAD

From: Matt Hunter <m@lfurio.us>
Date: Jun 13, 2026, 02:58 UTC
Message-ID: <DJ7L27FXS2PG.7PMBDY817U4V@lfurio.us>
In-Reply-To: <xmqqik7nj11i.fsf@gitster.g>

On Fri Jun 12, 2026 at 10:17 AM EDT, Junio C Hamano wrote:

>
> By the way, do not call a "configuration variable" a "configuration option".
> Let's keep the vocabulary forcused without using random synonyms.

Noted. I can appreciate that the term "option" may be better reserved for describing command-line options, to avoid confusion.

Is it safe to assume "setting" may be an appropriate alternative to "configuration variable" in some contexts?

Show 10 quoted lines

>
> I think these uses of strcasecmp() are unnecessary and actively
> harms end-user experience.  This is especially true because the
> value given to remote.<name>.followRemoteHEAD is case sensitive.
>
> [...]
>
> Admittedly values to some existing configuration variables may be
> parsed case insensitively but we should aim to fix the mistake in
> the longer term, and we should certainly not add more of them.

Thanks for clarifying the correct form here. The use of strcasecmp() was largely to match surrounding context as I assumed it would meet most people's expectations.

I think a detail like this can be especially confusing since it seems like the parsing for config variable **names** generally is case-insensitive.

Show 15 quoted lines

>
> Is it sensible to die() here?  If you are fetching from somewhere
> without keeping a set of remote-tracking branches for it (i.e., a
> single shot "git fetch https://github.com/gitster/git master"), you
> do not care what garbage value is in fetch.followRemoteHEAD.
> Perhaps the version of Git that is slightly newer than the version
> that ships with this patch defined new valid values that this patch
> does not know about, and such a user who is doing a single-shot
> fetch may have that setting to help them working with their usual
> non-single shot repositories, but they use a newer version of Git
> for such regular work, and they are using slightly old version of
> Git to perform this single-shot fetch.  The point is that the
> configured value will *NOT* be used for such a user, and dying only
> because this piece of code does not understand the configuration that
> will not be used is of dubious value.

Very good point about forward compatibility. Agreed that die() is the wrong call here.

The most sensible thing is probably to leave fetch.followRemoteHEAD UNCONFIGURED if the value is unrecognized, so we fall back to the "create" behavior unless the remote in question defines its own followRemoteHEAD policy.

Will incorporate each of these in the next round, thanks!