From: Junio C Hamano <gitster@pobox.com>
Date: Tue, 22 Jul 2025 15:21:45 GMT
Subject: Re: [GSoC PATCH v5 1/5] repo: declare the repo command
Message-ID: <xmqqtt34tfna.fsf@gitster.g>
In-Reply-To: <CAOLa=ZREo19jCj3i+XkRM15AzaAV9ZLOvt42pTiUFmcZpCyS5g@mail.gmail.com>

Karthik Nayak <karthik.188@gmail.com> writes:

> Lucas Seiki Oshiro <lucasseikioshiro@gmail.com> writes:
>
>> Currently, `git rev-parse` covers a wide range of functionality not
>> directly related to parsing revisions, as its name suggests. Over time,
>> many features like parsing datestrings, options, paths, and others
>> were added to it because there wasn't a more appropriate command
>> to place them.
>>
>> Create a new Git command called `repo`. `git repo` will be the main
>> command for obtaining the information about a repository (such as
>> metadata and metrics), returning them in a machine readable format
>> following the syntax "field<LF>value<NUL>".
>>
>
> Doesn't the latter sentence only apply to 'git repo info'? Other
> sub-commands may not follow the field<LF>value<NUL> syntax, no?

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.

Thanks.