From: Junio C Hamano <gitster@pobox.com>
Date: Tue, 11 Dec 2007 02:50:36 GMT
Subject: Re: [PATCH (amend)] diff: Make numstat machine friendly also for renames (and copies)
Message-ID: <7vprxehrlv.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <200712110226.35343.jnareb@gmail.com>

Jakub Narebski <jnareb@gmail.com> writes:

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

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