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
next prev parent 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).