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.
> 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
--
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