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

[Junio C Hamano <gitster@pobox.com>]

Junio C Hamano <gitster@pobox.com> 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.