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

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 22, 2025, 15:21 UTC
Message-ID: <xmqqtt34tfna.fsf@gitster.g>
In-Reply-To: <CAOLa=ZREo19jCj3i+XkRM15AzaAV9ZLOvt42pTiUFmcZpCyS5g@mail.gmail.com>

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

Show 16 quoted lines

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