Lucas Seiki Oshiro <lucasseikioshiro@xxxxxxxxx> writes:
> $ git repo-info
> {
> "objects": {
> "format": "sha1"
> },
> "references": {
> "format": "files"
> },
> "path": {
> "git-dir": "/git/dir"
> "git-commom-dir": "/git/common-dir",
> "toplevel": "/git/toplevel",
> "superproject-working-tree": "/super/working/tree",
> }
> "layout": {
> "bare": false,
> "shallow": false
> }
> }
> ~~~
OK, that's understandable, other than that handling of trailing
commas looks somewhat inconsistent.
> Or in a plaintext format, like this:
>
> ~~~
> $ git repo-info --format=plaintext
> sha1
> files
> /git/dir
> /git/common-dir
> /git/toplevel
> /super/working/tree
> false
> false
> ~~~
This one is a bit questionable.
Is it safe to assume that we will never have to deal with payload
controllable by the end-user that can have arbitrary byte values?
It would be uncommon but possible for LF to be in one of these
pathnames, breaking one-line-per-item assumption you seem to be
making. If one-line-per-item can be assumed, you can certainly
claim that this format is easy for consumers to handle, but the fact
is that this format is cumbersome to use safely if we have to deal
with end-user controllable arbitrary byte sequences, and if the set
of info pieces the repo-info needs to deal with changes over time.
> It will also allow the user to get only the desired fields, like this:
>
> ~~~
> $ git repo-info --format=plaintext objects.format references.format
> sha1
> files
> ~~~
If the user asked for only one item, this is probably OK, but for
more than one items, the same comment applies as above (except that
the number of and order of info pieces are known in this case).
> or:
>
> ~~~
> $ git repo-info objects.format references.format
> {
> "objects": {
> "format": "sha1"
> },
> "references": {
> "format": "files"
> }
> }
> ~~~
This one is OK.
> - on deciding if the JSON and linewise plaintext formats are the really the best,
> or if I should consider others (e.g. gitconfig syntax, NUL-terminated, etc)
"git config list" and "git config get" may be weaker in handling
arbitrary bytes than we would wish them to be. As much as I loath
JSON, the format is widely recognised and supported, so as the
initial cut, it may be sufficient to nail down the schema first and
then worry about emitting the same information in other formats
later.
