Daniel Shahaf wrote:
> Branko Čibej wrote on Thu, Nov 07, 2019 at 17:28:35 +0100:
>> Not with a new option. Instead --show-item should accept a
>> comma-separated list of keywords.
>
> You mean, like this?
It's tempting to say +1, commit it, and say we've made an improvement.
I have been missing the ability to specify multiple arguments to
--show-item, and it scratches that itch.
But I do have some reservations and further thoughts.
I feel sad about how inconsistent our output formats are. Subcommands
such as "status" and "list" are formatted mainly using fixed-width
columns, "info" and "log" mainly using separate lines, then there are
the XML variants, and now a tab-delimited output. And, in all of these
except XML, no consistent escaping of values for machine readability.
We have said the outputs (except XML) simply are not intended to be
parsed. That is fine as far as it goes, but leaves something lacking.
Tab-separated output seems a rather arbitrary addition to the flock,
though it's an OK choice in isolation for this particular use.
Better consistency with other subcommands would be achieved by using
space-separated output with field widths chosen per field, like we chose
them for "status" and "list". Or item-per-line format like the original
"info" output. Why should selecting items not be orthogonal to the
output format?
The XML output should also support --show-item. It's arbitrarily
inconsistent that it presently doesn't. Element names used in XML
should match those in show-item; compatibility is harder to achieve for
that, because we already made them different.
These days, JSON would be a reasonable choice of output format as an
alternative to XML. Consider if we offered it, how would we select it?
Perhaps a --json flag? Then why not a --tsv flag for TSV format, and
expect that too to be made available to other subcommands?
We might want to allow using multiple options, like
"--show-item=revision --show-item=kind" in addition to comma-separated
values.
- Julian
Received on 2019-11-07 18:53:45 CET