> OK, that's understandable, other than that handling of trailing > commas looks somewhat inconsistent. Ooops, it was typo. I'm using the json_writer functions >> 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? I was trying to follow the behavior of rev-parse, where we can do this: git rev-parse --show-toplevel --is-bare-repository and it prints both the top level repositority and whether it is a bare repository. > It would be uncommon but possible for LF to be in one of these > pathnames I tested here and this also happened with rev-parse: $ git init 'my repo' $ cd my\nrepo/ $ git rev-parse --show-toplevel /tmp/my repo And this also happens passing other flags to rev-parse... > This one is OK. So, after reading your review, I though about other solution: 1. The user can provide only one field or no field 2. If the user provide only one field, repo-info will return only its contents 3. If the user don't provide any field, the default set of fields will be returned
