Jeff King <p...@peff.net> writes: > I think there is another reason, which is that the interface we expose > to config callbacks (and via "config --get-all") is to sequentially pass > in all values. How does that interact with this "reset"? For example, > what is the output of: > > git config foo.bar one > git -c '!foo.bar' config --get-all foo.bar
The callback API needs to be extended to include this "reset" bit, not just "var" and "value", obviously. And then of course the users of the API need to be updated to act on that "reset" thing. That is what I meant by "multi-value things need custom code". The single-valued ones can do "last one wins", and "reset" can be turned into "the initial state" assignment for the variable; multi-value cumulative ones already have custom code to accumulate things into list, and they need to learn to empty the list upon seeing the "reset" bit. But that is not as fundamental as "new syntax breaks old clients". If we want our new code to do useful things, obviously we would need to work on making it do so ;-) > I think you could get away without changing the users of the multi-value > variables, using the "negative" approach I mentioned above. Basically: > ... > But like I said, that does feel somewhat half-implemented to me, since > it treats the command-line specially. I agree with you that that is a kludge and not the right way forward. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
