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

From: Jeff King <peff@peff.net>
Date: Apr 17, 2010, 09:53 UTC
Message-ID: <20100417095259.GA23110@coredump.intra.peff.net>
In-Reply-To: <201004151107.33892.jnareb@gmail.com>

On Thu, Apr 15, 2010 at 11:07:32AM +0200, Jakub Narebski wrote:

> Well, IMVHO output of "git status --short" / "git status --porcelain"
> (without '-z') is very hard to parse.  Even assuming that in the case
> of ambiguity filenames are quoted (which also means that in the case of
> ambiguity whether they are quoted they must be quoted), the fact that

For the record, they are properly quoted in the non-z form.

> [some reasons it's hard to parse]

Yeah, I don't disagree with your reasons (which are largely the same as Eric's). I just don't think it's "oh no this is useless and we have to start again" hard.

Show 7 quoted lines

> What was the reason behind choosing " -> " as separator between pair[1]
> of filenames in rename, instead of using default "git diff --stat" format
> i.e. 'arch/{i386 => x86}/Makefile' for "git status --short" which is
> meant for end user, and for "git status --porcelain" the same format 
> that raw diff format, i.e. with TAB as separator between filenames,
> and filename quited if it contains TAB (then TAB is relaced by '\t',
> and does not appear in filename, therefore you can split on TAB)?

I don't know Junio's reason for using " -> " in --short; probably because it was the format used in non-short status. For --porcelain, it was simply because I used exactly --short. I assumed that --short was suitable for parsing (which it _is_, it just has some rough edges), and wanted to provide an option right away that would keep the output stable, so we didn't run into the usual problem of people wanting to enhance the human-readable interface, but being blocked by script compatibility.

> IMVHO "git status --porcelain -z" format is not easy to parse either.
> (The same can be said for "git diff --raw -z" output format.)  You
> can't just split on record separator; you have to take into account
> status to check if there are two filenames or one.

Yep, I agree. I think the JSON approach is the best solution, as it is separating syntax from semantics.

> [1] A question: we have working area version, index version, and HEAD
>     version of file.  Isn't it possible for *each* of them to have 
>     different filename?  What about the case of rename/rename merge
>     conflict?

Good question. The answer is no, the three different versions can't have three filenames on the same line, because we don't do rename detection between the working tree and the index. Which makes sense. Consider something like this:

  mkdir repo && cd repo && git init
  echo content >one
  git add one && git commit -m one
  mv one two && git add -A
  mv two three
  git status

We will see the movement of "one -> two" between the index and HEAD. In theory we could see the movement of "three -> two" between the index and working tree. But "three" isn't tracked, so instead we see "two" deleted and "three" untracked. We can mark "three" with intent-to-add to note that we are interested in it, but then it is not a new file any more (since it has an index entry), and is therefore not eligible for rename detection.

As for a rename/rename conflict, it gets represented in the index as both deleting the source and then each side adding its new version with a conflict. So:

  mkdir repo && cd repo && git init
  echo content >one
  git add one && git commit -m base
  git mv one two && git commit -m two
  git checkout -b other HEAD^
  git mv one three && git commit -m three
  git merge master
  git status

generates:

  # On branch other
  # Unmerged paths:
  #       both deleted:       one
  #       added by us:        three
  #       added by them:      two

and an equivalent short-status form.

> Although if possible I'd like to have it wrapped in utility macros,
> like parseopt, so one does not need to write output_str / output_int
> etc.... but currently it is very, very vague sketch of an idea, rather
> than realized concept.

I'm not sure I understand what utility macros you would want.

-Peff