From: Junio C Hamano <hidden> Date: 2018-10-25 01:00:38
Jeff King [off-list ref] 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).
From: Jeff King <hidden> Date: 2018-10-25 01:09:08
On Thu, Oct 25, 2018 at 10:00:31AM +0900, Junio C Hamano wrote:
Jeff King [off-list ref] writes:
quoted
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
From: Ramsay Jones <hidden> Date: 2018-10-25 01:24:47
On 25/10/2018 02:09, Jeff King wrote:
On Thu, Oct 25, 2018 at 10:00:31AM +0900, Junio C Hamano wrote:
quoted
Jeff King [off-list ref] writes:
quoted
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
From: Jeff King <hidden> Date: 2018-10-25 21:24:01
On Thu, Oct 25, 2018 at 02:24:41AM +0100, Ramsay Jones wrote:
quoted
quoted
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. ;-)
Actually, "git var" already does pull bits from the environment. It
doesn't know about all of the type-specific parsing that git-config
does, but it might be a reasonable path forward to teach it that. (But I
still think we should do nothing for now and see how often this comes
up).
-Peff
On Thu, Oct 25, 2018 at 02:24:41AM +0100, Ramsay Jones wrote:
quoted
quoted
quoted
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. ;-)
Actually, "git var" already does pull bits from the environment. It
doesn't know about all of the type-specific parsing that git-config
does, but it might be a reasonable path forward to teach it that. (But I
still think we should do nothing for now and see how often this comes
up).
For myself / Junio picking this up: Does that mean you've read v2 and
think it's OK to pick up in its current form? I think it is, just
looking for some Acks on that since it's not in the latest "What's
Cooking".
From: Jeff King <hidden> Date: 2018-10-27 06:59:55
On Fri, Oct 26, 2018 at 09:20:56PM +0200, Ævar Arnfjörð Bjarmason wrote:
quoted
quoted
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 environment. It
doesn't know about all of the type-specific parsing that git-config
does, but it might be a reasonable path forward to teach it that. (But I
still think we should do nothing for now and see how often this comes
up).
For myself / Junio picking this up: Does that mean you've read v2 and
think it's OK to pick up in its current form? I think it is, just
looking for some Acks on that since it's not in the latest "What's
Cooking".
I'm not sure if you're asking whether I looked at the rest of the patch.
If so, then no, not really (so no objection, but I also did not review
it).
-Peff
On Fri, Oct 26, 2018 at 09:20:56PM +0200, Ævar Arnfjörð Bjarmason wrote:
quoted
quoted
quoted
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 environment. It
doesn't know about all of the type-specific parsing that git-config
does, but it might be a reasonable path forward to teach it that. (But I
still think we should do nothing for now and see how often this comes
up).
For myself / Junio picking this up: Does that mean you've read v2 and
think it's OK to pick up in its current form? I think it is, just
looking for some Acks on that since it's not in the latest "What's
Cooking".
I'm not sure if you're asking whether I looked at the rest of the patch.
If so, then no, not really (so no objection, but I also did not review
it).
Yeah I'm fishing for a more general review than just the problem of how
we turn an env variable into a boolean, so if you or anyone else is up
for it it would be most welcome :)