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

From: Patrick Steinhardt <ps@pks.im>
Date: Jul 24, 2025, 06:22 UTC
Message-ID: <aIHRCz_qswp7RgSy@pks.im>
In-Reply-To: <xmqqtt34tfna.fsf@gitster.g>

On Tue, Jul 22, 2025 at 08:21:45AM -0700, Junio C Hamano wrote:

Show 29 quoted lines

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

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.

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.

Patrick