From: Jeff King <peff@peff.net>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: "Junio C Hamano" <gitster@pobox.com>,
"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
"Patrick Steinhardt" <ps@pks.im>,
git@vger.kernel.org
Subject: Re: [PATCH 2/2] config: allow specifying config entries via envvar pairs
Date: Tue, 17 Nov 2020 20:59:07 -0500 [thread overview]
Message-ID: <20201118015907.GD650959@coredump.intra.peff.net> (raw)
In-Reply-To: <20201118005014.GC389879@camp.crustytoothpaste.net>
On Wed, Nov 18, 2020 at 12:50:14AM +0000, brian m. carlson wrote:
> > then I'd feel comfortable making it a public-facing feature. And for
> > most cases it would be pretty pleasant to use (and for the unpleasant
> > ones, I'm not sure that a little quoting is any worse than the paired
> > environment variables found here).
>
> What if we didn't document it but provided a command that produced a
> suitable value? Maybe something like this:
>
> GIT_CONFIG_PARAMETERS=$(git rev-parse --quote-parameters a.b.c ENV_VAR d.e.f OTHER_ENV_VAR)
>
> Or whatever we decide.
I think we mostly already have that tooling.
$ GIT_CONFIG_PARAMETERS=$(
git rev-parse --sq-quote \
foo.bar=value \
'section.key=with spaces' \
"or.even=embedded 'quotes'" |
sed 's/^ //'; # yuck
)
$ export GIT_CONFIG_PARAMETERS
$ git config --list --show-scope | grep ^command
command foo.bar=value
command section.key=with spaces
command or.even=embedded 'quotes'
The "yuck" there is because --sq-quote insists on putting a space at the
front. Our parser should probably ignore that, but right now it's quite
picky.
Though I suppose:
- do you mean ENV_VAR to literally look up an environment variable?
That solves Patrick's original problem of not wanting to put
sensitive values onto the command line. But it's much more annoying
to use if you _don't_ already have the value in an environment
variable. I'm not sure if that original problem matters here, as a
program that does a lot of this would probably implement the quoting
itself.
- obviously it is doubling down on the shell-quoting as a public
thing, and part of your point is that we would leave it opaque.
I'm OK with that aspect (even if it ends up as an alias for
--sq-quote for now). I'm not entirely sure people aren't using this
in the wild already, though. Saying "it was undocumented" may give
us a leg to stand on if we change the format, but it will still be
annoying to people we break.
- my example above still has the "a.b=c.d=e" ambiguity that I
mentioned earlier. Fixing that requires changing the format in the
environment variable.
> I don't personally love shell quoting as an interchange mechanism; I'd
> prefer something like URI-encoding, which is a bit more standardized and
> easier to reason about from a security perspective. But if we decide to
> change it, it doesn't matter, since it's still undocumented and this
> would be the only acceptable way to pass config through the environment.
Yes, I think concatenating uri_encode(key) + "=" + uri_encode(value)
would be easier to reason about, and solves the ambiguity problem. If we
are willing to break from the existing format, it's probably a
reasonable direction.
> Alternatively, we could just do this:
>
> git with-config --key a.b.c --value ENV_VAR --key d.e.f --value OTHER_ENV_VAR --command git foo
>
> That would also leave it undocumented, but make it easier to work with.
I wondered at first how this is different from:
git -c a.b.c=value foo
but I guess it is meant to do the same environment-lookup? We could
probably add:
git --env-config a.b.c=ENV_VAR foo
to have Git internally stick $ENV_VAR into $GIT_CONFIG_PARAMETERS. That
avoids all of the rev-parse rigamarole, keeps the format of the
environment variable opaque, and solves Patrick's problem of putting the
value onto the command-line.
It doesn't solve the ambiguity with "=" in the subsection, but IMHO that
is not all that important a problem.
-Peff
next prev parent reply other threads:[~2020-11-18 2:00 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-13 12:16 [PATCH 0/2] config: allow specifying config entries via envvar pairs Patrick Steinhardt
2020-11-13 12:16 ` [PATCH 1/2] config: extract function to parse config pairs Patrick Steinhardt
2020-11-13 12:16 ` [PATCH 2/2] config: allow specifying config entries via envvar pairs Patrick Steinhardt
2020-11-13 13:04 ` Ævar Arnfjörð Bjarmason
2020-11-16 19:39 ` Junio C Hamano
2020-11-17 2:34 ` Jeff King
2020-11-17 6:37 ` Patrick Steinhardt
2020-11-17 7:01 ` Jeff King
2020-11-17 14:22 ` Ævar Arnfjörð Bjarmason
2020-11-17 23:57 ` Jeff King
2020-11-18 13:44 ` Ævar Arnfjörð Bjarmason
2020-11-18 0:50 ` brian m. carlson
2020-11-18 1:59 ` Jeff King [this message]
2020-11-18 2:25 ` brian m. carlson
2020-11-18 7:04 ` Patrick Steinhardt
2020-11-19 2:11 ` brian m. carlson
2020-11-19 6:37 ` Patrick Steinhardt
2020-11-18 5:44 ` Junio C Hamano
2020-11-17 6:28 ` Patrick Steinhardt
2020-11-17 7:06 ` Junio C Hamano
2020-11-18 13:49 ` Ævar Arnfjörð Bjarmason
2020-11-18 13:56 ` Patrick Steinhardt
2020-11-18 16:01 ` Junio C Hamano
2020-11-17 14:03 ` Ævar Arnfjörð Bjarmason
2020-11-13 16:37 ` Philip Oakley
2020-11-17 6:40 ` Patrick Steinhardt
2020-11-13 13:11 ` [PATCH 0/2] " Ævar Arnfjörð Bjarmason
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201118015907.GD650959@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=ps@pks.im \
--cc=sandals@crustytoothpaste.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).