Subject: Re: [GSoC PATCH v5 1/5] repo: declare the repo command

From: Junio C Hamano <[email-masked]>
Date: Thu, 24 Jul 2025 09:06:57 -0700

Patrick Steinhardt <[email-masked]> writes:

>> True.
>> 
>> I also wonder who it helps to use <LF> as a field separator.  Once
>> we require consumers to properly handle <NUL>, it does not make it
>> easier to write such a consumer script if the format uses <LF>
>> there, does it?  Besides, wouldn't it possible that field may have
>> to contain any end-user specified key, including <LF>?  If so, we'd
>> need to have some quoting/unquoting mechanism in the syntax anyway,
>> so the behefit of using <NUL> to simplify the parser would already
>> be lost.
>
> Scripts should always use NUL, true. But sometimes a user may want to
> inspect these key-value pairs, as well, just to double check a certain
> property of the repository, or to figure out how a certain property
> looks like while writing a script that parses the same key-value but
> NUL-separated pairs. Using NUL bytes would be a bit of a pain in that
> situation.

True.  I do not think the discussion so far had much focus on
helping human users doing ad-hoc inspection, and NUL can be annoying
for such use cases (even though tr is your friend).

> I'm not really too sure whether we need to bother with quoting. The
> LF-separated output shouldn't ever be used in a script, so I don't mind
> too much whether it always works. But I guess it wouldn't be hard either
> to just have something like:
>
>     if (uses_newline)
>         quote_c_style(...);
>
> So with that in mind it's probably better to just do the right thing.

The right thing being...?  Use <LF> as a record separator to avoid
forcing <NUL> on possible human readers, and adopt quoting in a rare
case where <LF>s or <NUL>s need to be in the payload?  Or something
else?

Thanks.