Re: [PATCH] i18n: make GETTEXT_POISON a runtime option
- From
Ramsay Jones <ramsay@ramsayjones.plus.com>
- Date
- Oct 25, 2018, 01:24 UTC
- Message-ID
- <a5535030-65c1-613c-e4ea-d4379b243b87@ramsayjones.plus.com>
- In-Reply-To
- <20181025010905.GA4458@sigill.intra.peff.net>
On 25/10/2018 02:09, Jeff King wrote:
Show 27 quoted lines
> On Thu, Oct 25, 2018 at 10:00:31AM +0900, Junio C Hamano wrote: > >> Jeff King <peff@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). > > 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).
I was thinking:
$ git var -e GIT_WHATEVER_ENV
[-e for environment].
... but that is really no different than git-config. ;-)
ATB, Ramsay Jones