On Wed, May 1, 2019 at 4:14 AM Jeff King <peff@xxxxxxxx> wrote: > It's definitely not implemented universally; each consumer of the config > option must decide on it (and it will probably always be that way to > some degree, since we don't know the semantics of each options; recall > that we may be holding config keys for other non-core programs, too). > And we just haven't retro-fitted a lot of those older options because > nobody has been bothered by it. > > That said, I am a proponent of having some kind of clearing mechanism > (and I was the one who added credential.helper's mechanism, which has > been mentioned in this thread). I think it makes things a lot less > difficult if we don't have to change the syntax of the config files to > do it. With that constraint, that pretty much leaves: > > 1. Some sentinel value like the empty string. That one _probably_ > works in most cases, but there may be lists which want to represent > the empty value. There could be other sentinel values (e.g., > "CLEAR") which are simply unlikely to be used as real values. > > 2. The boolean syntax (i.e., "[foo]bar" with no equals) is almost > always bogus for a list. So that can work as a sentinel that is > OK syntactically. Another question about the universal clearing mechanism, how does "git config" fit into this? It would be great if the user can actually see the same thing a git command sees to troubleshoot. Option 1 leaves the interpretation/guessing to the user, "git config" simply gives the raw input list before "clear" is processed. Option 2, "git config" probably can be taught to optionally clear when it sees the boolean syntax. -- Duy
