On Sat, Oct 27 2018, Jeff King wrote:
> On Fri, Oct 26, 2018 at 09:20:56PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
>> >> I was thinking:
>> >>
>> >> $ git var -e GIT_WHATEVER_ENV
>> >>
>> >> [-e for environment].
>> >>
>> >> ... but that is really no different than git-config. ;-)
>> >
>> >
On Fri, Oct 26, 2018 at 09:20:56PM +0200, Ævar Arnfjörð Bjarmason wrote:
> >> I was thinking:
> >>
> >> $ git var -e GIT_WHATEVER_ENV
> >>
> >> [-e for environment].
> >>
> >> ... but that is really no different than git-config. ;-)
> >
> > Actually, "git var" already does pull bits from the
On Thu, Oct 25 2018, Jeff King wrote:
> On Thu, Oct 25, 2018 at 02:24:41AM +0100, Ramsay Jones wrote:
>
>> >> 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
On Thu, Oct 25, 2018 at 02:24:41AM +0100, Ramsay Jones wrote:
> >> 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
On 25/10/2018 02:09, Jeff King wrote:
> On Thu, Oct 25, 2018 at 10:00:31AM +0900, Junio C Hamano wrote:
>
>> Jeff King 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,
On Thu, Oct 25, 2018 at 10:00:31AM +0900, Junio C Hamano wrote:
> Jeff King 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
Jeff King 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,
On Wed, Oct 24, 2018 at 02:45:49PM +0900, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
> > Notes on the implementation:
> >
> > * The only reason we need a new "git-sh-i18n--helper" and the
> >corresponding "test-tool gettext-poison" is to expose
> >git_env_bool() to
Ævar Arnfjörð Bjarmason writes:
> Notes on the implementation:
>
> * The only reason we need a new "git-sh-i18n--helper" and the
>corresponding "test-tool gettext-poison" is to expose
>git_env_bool() to shellscripts, since git-sh-i18n and friends need
>to inspect the
Change the GETTEXT_POISON compile-time + runtime GIT_GETTEXT_POISON
test parameter to only be a GIT_TEST_GETTEXT_POISON= runtime
parameter, to be consistent with other parameters documented in
"Running tests with special setups" in t/README.
When I added GETTEXT_POISON in bb946bba76 ("i18n: add
10 matches
Mail list logo
