Lucas Seiki Oshiro <lucasseikioshiro@xxxxxxxxx> writes:
> I was trying to follow the behavior of rev-parse, where we can
> do this:
>
> git rev-parse --show-toplevel --is-bare-repository
As often said, an earlier mistake is not an excuse to pile more of
them on top. Isn't the whole point of this new command to remove
these kitchen-sink options out of rev-parse and give them better
home? Let's learn from our earlier mistakes and do it right in the
new incarnation.
> 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
Hmm. Isn't
4. The output always comes out in JSON. There should be plenty JSON
reading libraries available to the GUI command or whatever that
forks this command and reads from it, right?
an option? If we want textual format, and assume that almost all
values are text, we could do something like
1. In text mode, the values are shown one-item-per-line, even if
the value has embedded LF in it. At least we assume that the
values do not contain a NUL byte.
2. If a value does not have LF or double-quote in it, it is output
literally.
3. Otherwise, the value is shown with quote_c_style().
The implication of which is that a loosely written program that does
not grok funny values (namely, a string that contains a double-quote
or a line-feed) can be written loosely without having to worry about
quoting and assume one-line-per-item. They may show a wrong value,
but at least because one-line-per-item assumption holds, their
input/request and value they receive from the program will not go
out of sync. And a more carefully written program can of course
check the first byte to see if it is a double-quote, in which case
they have to unquote the whole line (which may yield a multi-line
value if the quoted string had embedded "\n"s).
