Re: [PATCH (amend)] diff: Make numstat machine friendly also for renames (and copies)

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 11, 2007, 02:50 UTC
Message-ID: <7vprxehrlv.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <200712110226.35343.jnareb@gmail.com>

Jakub Narebski <jnareb@gmail.com> writes:

Show 7 quoted lines

> Junio C Hamano wrote:
>> Jakub Narebski <jnareb@gmail.com> 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).

Show 6 quoted lines

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