git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Junio C Hamano <gitster@pobox.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 18:57:36 -0500	[thread overview]
Message-ID: <20201117235736.GC642410@coredump.intra.peff.net> (raw)
In-Reply-To: <873618f4he.fsf@evledraar.gmail.com>

On Tue, Nov 17, 2020 at 03:22:05PM +0100, Ævar Arnfjörð Bjarmason 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).
> 
> I wonder if something like the git config -z format wouldn't be easier,
> with the twist that we'd obviously not support \0. So we'd need an
> optional length prefix. : = unspecified.
> 
>     :user.name
>     Jeff K
>     :alias.ci
>     commit
>     :10:bin.ary
>     <10 byte string, might have a \n>
>     :other.key
>     Other Value
> 
> Maybe that's overly fragile, or maybe another format would be better.

Yeah, length-delimited strings are an alternative that some people think
is less error-prone than quoting. And we do use pkt-lines. They're also
a pain for humans to write (it's nicer if they're optional, but when you
_do_ have to start using them, now you are stuck counting things up).

> I was trying to come up with one where the common case wouldn't
> require knowing about shell quoting/unquoting, and where you could
> still do:
> 
>     GIT_CONFIG_PARAMETERS=":my.new\nvalue\n$GIT_CONFIG_PARAMETERS"
> 
> Or equivalent, and still just keep $GIT_CONFIG_PARAMETERS as-is to pass
> it along.
> 
> Your "do not require quoting" accomplishes that, and it's arguably a lot

Looks like your mail got cut off. But yeah, the goal of making the
quoting optional was to make it easier for humans to use for simple
cases. It doesn't help at all with other programs inserting values,
which can just as easily err on the side of caution.

BTW, there is another problem with GIT_CONFIG_PARAMETERS (and "git -c"
in general). The dotted config-key format:

  section.subsection.key

is unambiguous by itself, even though "subsection" can contain arbitrary
bytes, including dots. Because neither "section" nor "key" can contain
dots, we can parse from either end, and take the whole middle as a
subsection (and this is how we do it in the code).

But an assignment string like:

  section.subsection.key=value

_is_ ambiguous. We have to parse left-to-right up to the first equals
(since "value" can contain arbitrary characters, including an equals).
But "subsection" can have one, too, so we want to parse right-to-left
there. E.g., in:

  one.two=three.four=five

this could be either of:

  - section is "one", key is "two", value is "three.four=five"

  - section is "one", subsection is "two=three", key is "four", value is
    "five"

We currently always parse it as the former (which I think is least-bad
of the two, since values are more likely than subsections to contain
arbitrary text with an equals).

-Peff

  reply	other threads:[~2020-11-17 23:59 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 [this message]
2020-11-18 13:44             ` Ævar Arnfjörð Bjarmason
2020-11-18  0:50         ` brian m. carlson
2020-11-18  1:59           ` Jeff King
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=20201117235736.GC642410@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 \
    /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).