Junio C Hamano [off-list ref] writes:

... to some "unspecified" or "default" value?  What does the existing
parser routine for remote.*.followremotehead do?

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?".

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), ...

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.

Other than that, this looks excellent.  Thanks.