Jeff King <p...@peff.net> 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).
