Re: [PATCH v2 1/1] config: learn the --stdin option for instructions

From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Eric Sunshine <sunshine@sunshineco.com>,
	Zeger-Jan van de Weg <git@zjvandeweg.nl>,
	Git List <git@vger.kernel.org>
Subject: Re: [PATCH v2 1/1] config: learn the --stdin option for instructions
Date: Tue, 28 Jan 2020 11:28:36 -0800	[thread overview]
Message-ID: <xmqq36bz8job.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <20200128092414.GB574544@coredump.intra.peff.net> (Jeff King's message of "Tue, 28 Jan 2020 04:24:14 -0500")

Jeff King <peff@peff.net> writes:

> On Mon, Jan 27, 2020 at 11:59:03AM -0500, Eric Sunshine wrote:
>
>> Second, this doesn't give any indication about how the lines should be
>> terminated. It should instead be written as:
>> 
>>     set SP <key> NUL <value> NUL
>>     unset SP <key> NUL
>> 
>> Third, importantly, unlike git-update-ref from which this DSL takes
>> inspiration and in which "refs" might have oddball names for which
>> NUL-termination makes sense, it's hard to imagine a case in which a
>> configuration key would be so strange as to warrant NUL-termination.
>> This observation suggests a simpler DSL in which only <value> is
>> NUL-terminated:
>> 
>>     set SP <key> SP <value> NUL
>>     unset SP <key> LF
>> 
>> (The proposed code changes in config.c would need adjustment, as well,
>> to implement this revised DSL.)
>
> The section and key parts of a config key are pretty restricted, but the
> subsection portion can contain anything except newline and NUL. So in
> particular, it would be valid to have a space, which would make the
> input ambiguous.
>
> I agree it would probably be rare, but isn't the whole point of "-z" to
> be able to represent anything without worrying about quoting?

Yup.  I was tempted to say, in addition to "without worrying about
quoting", "without worrying about the syntax".

But unfortunately that would not work.  If we were to add a new
"frotz" subcommand in a future version of Git that takes N args,

	frotz SP <arg1> NUL <arg2> NUL ... <argN> NUL

may how you'd express it, and it would be wonderful if the current
version of Git that does not know "frotz" subcommand can at least
parse and ignore it.  That cannot however be done, though, because
there is no syntactic difference between the argument terminator
(after each arg) and subcommand terminator (after each subcommand).