Re: Disabling credential helper?

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

Jeff King <peff@peff.net> writes:

>   1. I chose the value-less boolean as a token to reset the list (since
>      it is otherwise an unmeaningful error). The example above shows its
>      use with "-c", but you could also do:
>
>        [credential]
>        helper
>        helper = foo
>
>      in a config file itself.  This is probably rather unintuitive.

For this one, and I suspect all the "multi-valued" ones, I think it
actually is the most sensible syntax (another possiblity is to give
an empty string, assuming that all multi-valued variables we care
about take non-empty string or numeric values), as I do not see a
useful/valid use case for wanting to define boolean multi-valued
variable.

>      If we can accept stomping on an unlikely-used token, something
>      like:
>
>        git -c credential.helper=RESET fetch ...
>
>      is more sensible (and we can argue about the exact token used).

This unfortunately is unlikely to fly well if we are shooting for a
generic mechanism that is applicable for multi-valued ones in
general (your comment 2. below is very much relevant and true).

>      If we can accept new syntax and new config code, something like:
>
>        git -c '!credential.helper' fetch ...
>
>      is probably workable.

I think I suggested exactly this syntax (and "[credential] !helper"
in the config file) when this was brought up the last time, but it
was shot down because that would make the resulting configuration
file unparsable (not just ignored) by existing versions of Git.

But perhaps it is a good thing to break existing parser when "clear
the variable settings seen so far" is used.  It would not do us very
good to allow existing implementations to ignore it and continue as
if all other entries (and special token like RESET) matter will
silently give users incorrect result.