Re: [PATCH v2 0/7] Introduce fetch.followRemoteHEAD config variable

From: Matt Hunter <m@lfurio.us>
Date: Jun 18, 2026, 04:21 UTC
Message-ID: <DJBVYP58YNTU.LQ7VXFIQE84H@lfurio.us>
In-Reply-To: <xmqqcxxp1j2t.fsf@gitster.g>

On Wed Jun 17, 2026 at 7:51 AM EDT, Junio C Hamano wrote:

Show 14 quoted lines

>>
>> Ideally,
>>
>>  (1) If the "fetch" operation ends up with not needing to consult
>>      the value of fetch.followRemoteHEAD at all (e.g., it is a
>>      one-shot fetch that updates no remote-tracking hierarchy, or it
>>      has a more specific per-remote setting that this variable is
>>      meant to serve as a mere fallback), any bogus or unknown value
>>      will not get any warning.
>>
>>  (2) If fetch.followRemoteHEAD ends up being _used_, and if it has
>>      an unknown value, we should at least warn "we do not understand
>>      what you wrote, 'awlays', and we ignore it", or die "we do not
>>      understand 'reset', perhaps it is from a future version of Git?".

This explanation makes much more sense to me than what you said in your response to the first iteration. I believe I understand your vision better here.

Show 10 quoted lines

>>
>> I do not think customization based on git_config() callback like the
>> above can easily implement such an ideal semantics.
>>
>> And I suspect that the existing per-remote configuration that this
>> variable is meant to serve as a fallback definition would not work
>> in such an ideal way (i.e., even if we are doing one-shot fetch that
>> does not touch any remote-tracking hierarchies, "git fetch" may warn
>> if the value is not understood, and when we do need the value, the
>> code would only warn and does not die), ...

Right. It seems like the design of the config callback mechanism doesn't work well for the dynamic behavior described in your ideal case.

I've tried to test out a few ideas to make it work, and each one so far ends up feeling hacky very quickly.

Show 9 quoted lines

>
> Having said all that, I do not think it is a blocker for this series
> that it does not take us into the more ideal direction and still
> makes a syntax check on a value that will not be used and complains
> to the user.  We may want an in-code NEEDSWORK comment to hint
> future developers that they may want to revamp both of the code
> paths for fetch.followRemoteHEAD and remote.*.followremotehead not
> to complain when the values are unneeded and die when the unrecognized
> value is needed to continue, though.

Personally, even in the case where we can disregard any and all followRemoteHEAD settings on a one-shot fetch, I don't think die()-ing on an unrecognized value should be the course of action.

As you pointed out in your last response to this topic, a future git release may implement additional choices for followRemoteHEAD. If a user opts in to this new functionality, but finds themself using an older version of git (for whatever reason), I would still expect the fetch operation to continue, just using different semantics for followRemoteHEAD.

In fact, the better behavior might be to fall to "never" if the user asks to do something we don't understand. In this case, we just emit the warning, continue with fetch, but followRemoteHEAD does nothing - not even create a missing ref.

>
> Other than that, this looks excellent.  Thanks.

Thanks for the great feedback and consideration!

If you like, I can apply the appropriate NEEDSWORK comment, possibly add a warning to 'fetch.followRemoteHEAD' parsing (matching the 'remote' side), and we can call this good to go for now.