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

[Jeff King <peff@peff.net>]

On Tue, Jan 28, 2020 at 11:28:36AM -0800, Junio C Hamano wrote:

> > 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).

I do agree it would be nice if we could separate syntax from semantics,
just because it lets us reuse and modify parsers more easily. We have
the same problem on output (e.g., anything parsing "diff --name-status
-z" has to know there are two name fields for an R or C entry), and it
has tripped people up in the past.

But:

  - I don't think we'd want a current version of Git to ignore an
    unknown frotz anyway. It would probably say "I don't understand
    frotz, so I don't know if it's safe to ignore it or not".

  - Given only the tool of NUL bytes, I'm not sure how to easily
    design a syntax that isn't awful. I.e., clearly something like:

      frotz SP 2 NUL <arg1> NUL <arg2> NUL

    works, but have we really made the world a better place? It would
    make more sense to me to use a standard serialization format like
    JSON, but that generally comes with its own inherited baggage (like
    non-UTF8 strings).

-Peff