Re: [PATCH/RFC] diff: Make numstat machine friendly also for renames

From: Junio C Hamano <junkio@cox.net>
Date: May 9, 2007, 04:59 UTC
Message-ID: <7vd51azj6c.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <200705081433.58931.jnareb@gmail.com>

Jakub Narebski <jnareb@gmail.com> writes:

Show 19 quoted lines

>> The --stat format is for human consumption, and --numstat (be it
>> with -z or without) is for machines, so I am not opposed to a
>> format change that gives information that is already computed
>> but currently is hard to parse.  If the format change breaks
>> existing scripts, we might want to do --numstat-extended,
>> though...
>> 
>> For example, I do not see a reason not to add "R98" in there.
>> I.e.
>> 
>> 	added deleted status TAB "src" (TAB "dst"){0,1} LF
>> 	added deleted status NUL "src" (NUL "dst"){0,1} NUL
>> 
>> where the dst path is present only when status says it is a
>> rename/copy, just like the --raw format.
>
> That is a good idea, but wouldn't it break existing scripts? Well,
> break more than a bit hacky idea of using NUL NUL as separator between
> pre-image name and post-image name.

I think both would break equally. That's why I hinted --numstat-extended, but I think the information is getting to be about --machine-readable, and not necessarily about "stat" anymore.