Re: Efficient parsing of `status -z` output

[Junio C Hamano <gitster@pobox.com>]

Matthew Rothenberg <mrothenberg@gmail.com> writes:

>  2. Read from buffer until the first NUL, parse the entry status
> codes, and if the entry status code represents a status that *should*
> have multiple filenames, read from buffer until a second NUL is found,
> and then reparse that entry with both filenames. The issues I see with
> this approach:
>    a.) One has to know exactly which status code combinations will end
> up with two filenames, and this list has to be exhaustive. As far as I
> can tell, there is no canonical documentation for this?
>    b.) It seems a bit brittle, because if the logic from the above is
> wrong and we miss an extended entry or ask for one when it doesn't
> exist we will leave the buffer an essentially corrupt state for future
> reads.

I think this is how -z was designed to be used, and if that isn't
clear, then the documentation must be updated to clarify.  Rename
and Copy are the only ones that needs two pathnames, and I suspect
that whoever did the original description of the short format in the
documentation knew Git too well that he forgot to mention it ;-)