Re: [RFC/PATCH v2 0/4] A new library for plumbing output

From: Jakub Narebski <jnareb@gmail.com>
Date: Apr 14, 2010, 21:29 UTC
Message-ID: <201004142329.38914.jnareb@gmail.com>
In-Reply-To: <7vbpdlpy5t.fsf@alter.siamese.dyndns.org>

On Wed, 14 April 2010, Junio C Hamano wrote:

Show 12 quoted lines

> Jakub Narebski <jnareb@gmail.com> 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