git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: Junio C Hamano <junkio@cox.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH/RFC] diff: Make numstat machine friendly also for renames
Date: Tue, 8 May 2007 14:33:57 +0200	[thread overview]
Message-ID: <200705081433.58931.jnareb@gmail.com> (raw)
In-Reply-To: <7vhcqo5b64.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano <junkio@cox.net> wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
> 
>>>> The numstat format for rename is now
>>>>
>>>>   added deleted TAB path for "src" TAB path for "dst" LF
>>>>
>>>> or if -z option is used
>>>>
>>>>   added deleted TAB path for "src" NUL NUL path for "dst" NUL
>>> 
>>> Why two NULs?
>>
>> That was the only way I could think of to separate pre-image name
>> from posi-image name for renames. Note that file name might look like
>> (part of) diffstat line, and there is no 'status' field in the
>> numstat to mark rename (as there is in "git diff-tree --raw" output).
> 
> 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.

This would change output in every case, while my proposal doesn't change
output for the case without renames. '-M' should also work correctly,
perhaps scripts using it getting wrong filename. It is '-z -M' that changes
most.

>> Did you mean --stat here?
> 
> No, I did mean --summary.  But that was foolish of me.  I forgot
> that it had the same { namepart => namepart } issue.

Ah. I somehow didn't get then that you meant for --numstat to have only
post-image names, and get pre-image names from rename information in
--summary. But as you have noticed it wouldn't help: rename information
is in the same for-humans format.

>>>> @@ -949,11 +955,19 @@ static void show_numstat(struct diffstat_t* data,
>>>>  			printf("-\t-\t");
>>>>  		else
>>>>  			printf("%d\t%d\t", file->added, file->deleted);
>>>> -		if (options->line_termination && !file->is_renamed &&
>>>> +		if (options->line_termination &&
>>>>  		    quote_c_style(file->name, NULL, NULL, 0))
>>>>  			quote_c_style(file->name, NULL, stdout, 0);
>>>>  		else
>>>>  			fputs(file->name, stdout);
>>>> +		if (file->is_renamed) {
>>>> +			printf("%s", options->line_termination ? "\t" : "\0\0");
>
> What I was hoping you to notice was that printf("%s", "\0\0")
> thing.  %s would not even notice that the const char[] literal
> is 2 bytes long.

Ooops. Shame on me. That is the result of trying to be too smart... 
and changing separator between pathnames for rename from NUL to NUL NUL.

-- 
Jakub Narebski
Poland

  reply	other threads:[~2007-05-08 12:34 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-08  0:43 [PATCH/RFC] diff: Make numstat machine friendly also for renames Jakub Narebski
2007-05-08  1:10 ` Junio C Hamano
2007-05-08  1:45   ` Jakub Narebski
2007-05-08  1:58     ` Junio C Hamano
2007-05-08 12:33       ` Jakub Narebski [this message]
2007-05-09  4:59         ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200705081433.58931.jnareb@gmail.com \
    --to=jnareb@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=junkio@cox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).