From: "SZEDER Gábor" <szeder.dev@gmail•com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail•com>
Cc: Junio C Hamano <gitster@pobox•com>, git@vger•kernel.org
Subject: Re: ab/* topics (was: Re: What's cooking in git.git (Nov 2018, #01; Thu, 1))
Date: Thu, 1 Nov 2018 15:30:06 +0100 [thread overview]
Message-ID: <20181101143006.GV30222@szeder.dev> (raw)
In-Reply-To: <87va5gkj0e.fsf@evledraar.gmail.com>
On Thu, Nov 01, 2018 at 02:46:41PM +0100, Ævar Arnfjörð Bjarmason wrote:
> > However, if you push that patch with 'sh-i18n--helper' as-is, then I
> > do object now: parsing a boolean in shell is not at all that difficult
> > to justify this new command.
>
> So instead of calling a helper (which is undocumented, and only used by
> git itself internally) you'd instead like to have some shellscript
> thingy like:
>
> if test $value = 'true' -o $value = '1' [....]
> then
> exit 0
> elif test $value = 'false' -o $value = '0' [...]
Yes, but more like:
case "$GIT_TEST_GETTEXT_POISON" in
yes|true|on|1)
GIT_INTERNAL_GETTEXT_SH_SCHEME=poison
;;
esac
There is no need to check for 'false', 0, etc.
Yes, I know that this is not as fully-fledged as git_env_bool(), e.g.
it won't recognize 'TrUe' and '42' as true, but since this is "merely"
a testing aid, I think it's sufficient.
> Sure, if that's the consensus I can change that, but it seems like the
> opposite of the direction we're moving with the general *.sh -> *.c
> migration. I.e. implementing helpers whenever possible instead of adding
> new shellscript-only logic.
I doubt that we really want to implement helpers "whenever possible",
i.e. even instead of such a rather trivial piece of shell code.
In the discusson of v1 of that patch there were suggestions on how to
turn an environment variable into a boolean in a more proper way, e.g.
by extending 'git var', but I agree with Peff that "we should do
nothing for now and see how often this comes up" [1]. In the meantime
this builtin seems to be the worse direction of all.
[1] https://public-inbox.org/git/20181025212358.GA23257@sigill.intra.peff.net/
next prev parent reply other threads:[~2018-11-01 14:30 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-01 9:59 What's cooking in git.git (Nov 2018, #01; Thu, 1) Junio C Hamano
2018-11-01 11:02 ` ab/* topics (was: Re: What's cooking in git.git (Nov 2018, #01; Thu, 1)) Ævar Arnfjörð Bjarmason
2018-11-01 13:10 ` SZEDER Gábor
2018-11-01 13:46 ` Ævar Arnfjörð Bjarmason
2018-11-01 14:30 ` SZEDER Gábor [this message]
2018-11-01 13:28 ` ab/* topics Junio C Hamano
2018-11-01 15:32 ` Duy Nguyen
2018-11-01 19:38 ` Ævar Arnfjörð Bjarmason
2018-11-01 16:07 ` master updated? (was Re: What's cooking in git.git (Nov 2018, #01; Thu, 1)) Derrick Stolee
2018-11-02 0:04 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181101143006.GV30222@szeder.dev \
--to=szeder.dev@gmail$(echo .)com \
--cc=avarab@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox