Matthew Rothenberg <mrothenberg@xxxxxxxxx> 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 ;-) -- 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