Re: [GSoC PATCH v5 1/5] repo: declare the repo command
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jul 24, 2025, 16:06 UTC
- Message-ID
- <xmqqwm7xindq.fsf@gitster.g>
- In-Reply-To
- <aIHRCz_qswp7RgSy@pks.im>
Patrick Steinhardt <ps@pks.im> writes:
Show 17 quoted lines
>> 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).
Show 9 quoted lines
> 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.