Karthik Nayak <karthik.188@xxxxxxxxx> writes: > Lucas Seiki Oshiro <lucasseikioshiro@xxxxxxxxx> 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.
