On Thu, Oct 25, 2018 at 10:00:31AM +0900, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > but then you lose the default handling. I think if we added a new > > option, it would either be: > > > > # interpret a value directly; use default on empty, I guess? > > git config --default=false --type=bool --interpret-value "$GIT_WHATEVER_ENV" > > > > or > > > > # less flexible, but the --default semantics are more obvious > > git config --default=false --type=bool --get-env GIT_WHATEVER_ENV > > Yeah, my thinko. The latter would be closer to what this patch > wants to have, but obviously the former would be more flexible and > useful in wider context. Both have the "Huh?" factor---what they > are doing has little to do with "config", but I did not think of a > better kitchen-sink (and our default kitchen-sink "rev-parse" is > even further than "config", I would think, for this one). Heh, I thought through the exact sequence in your paragraph when writing my other message. That's probably a good sign that we should probably not pursue this further unless we see the use case come up again a few more times (and if we do, then consider "config" the least-bad place to do it). -Peff