On Wed, 14 April 2010, Junio C Hamano wrote:
> Jakub Narebski <jnareb@xxxxxxxxx> writes:
>
>>> Wouldn't the exact same argument apply equally well to the output format
>>> of "status --porcelain", by the way? It is line-based and pretty much
>>> self-describing (once you know the mnemonic but you can make an educated
>>> guess from previous SCM experience).
>>
>> No, current "git status --porcelain" output is record-based (tabular);
>> the meaning is not described by header but depends on field in record,
>> i.e. position in line.
>
> Now, what's wrong about that?
Well, this whole idea started with the fact, that "git status --short"
was hard (or impossible) to parse unambigously by scripts[1], and even
"git status --porcelain -z"[2] is not that easy to parse[3].
With JSON output format one can use existing JSON parsers, which are
available in any language.
[1] And it was woefully underdocumented
[2] I wonder why git-config and git-grep have '--null' as long version
of '-z' option... and only those.
[3] I rather liked the idea of -Z output format, the form that uses
NUL as field separator for each field (and not only filenames),
and NUL NUL as record terminator; it makes parsing much easier
because you don't need to take a look at other field to know
where the record ends.
> For that matter, would you say "diff --raw" output should be
> JSON/XMLified because it is columnar?
It would be nice to have raw diff format JSONified, or have --porcelain
(like "git blame --porcelain" output format) version of it. Especially
for "diff -c --raw" i.e. raw output format for merges, which lacks some
information, namely filename and similarity score for n-th pre-image,
if rename or copy was detected.
--
Jakub Narebski
Poland
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html