Jakub Narebski <jnareb@xxxxxxxxx> writes: > Junio C Hamano wrote: >> Jakub Narebski <jnareb@xxxxxxxxx> writes: >> >> > Previous version of this patch (from 7 May 2007) used instead of current >> > only "to_name" format similar to git-diff-tree raw format for renames: >> > >> > added deleted TAB path for "src" TAB path for "dst" LF That's perfectly fine (that is without -z). >> > ... Previous version >> > of patch used (or was to use actually, because of error in the code) >> > >> > added deleted TAB path for "src" NUL NUL path for "dst" NUL >> > >> > when -z option was used. I think your "previous" one: <added> <deleted> <src> NUL (no rename) <added> <deleted> <src> NUL NUL <dst> NUL (with rename) would be unambiguously parsable, but it would be cleaner and easier for the parser if the latter were like this instead: <added> <deleted> NUL <src> NUL <dst> NUL (with rename) The reader can expect to find a NUL terminated src, finds the length is zero and notices it cannot be src and then reads two paths from that point. Without having the status letter, we cannot do "optional two paths" without breaking existing --numstat -z readers that do not care about renames and copies, and I agree that existing --numstat -z readers that pass -M or -C are already broken, so I think a format extension along the above line (your "previous" and the above clean-up proposal have the same power of expressiveness, I just think the latter is syntactically cleaner) would be reasonable. And at that point we probably would not need --numstat-enhanced at all ;-) - 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
