On Thu, Oct 7, 2010 at 7:29 PM, Jeff King <peff@xxxxxxxx> wrote:
> On Thu, Oct 07, 2010 at 07:18:18PM +0400, Kirill Likhodedov wrote:
>
>> Thanks for pointing that out.
>> I confirm that on Mac OS X that happens for rev-list as well.
>>
>> # git log --pretty=format:foo%x00bar HEAD -1 | od -c
>> 0000000 f o o \0 b a r
>> 0000007
>>
>> # git rev-list --pretty=format:foo%x00bar HEAD -1 | od -c
>> 0000000 c o m m i t 2 3 6 0 1 a 2 c 3
>> 0000020 e 4 6 4 a 4 4 7 9 f 1 7 7 4 e 3
>> 0000040 6 e a 5 b 9 5 8 b 4 6 0 5 2 1 \n
>> 0000060 f o o \n
>> 0000064
>
> Ugh. Even worse, it does print with --graph, which uses a slightly
> different code path.
>
> $ git rev-list --graph -1 --format=foo%x00bar HEAD | cat -A
> * commit 81d866a6a213d5524ce389369377ba3529461e1b$
> |\ foo^@bar$
>
> I am inclined to call the rev-list behavior a bug, and the fix is
> probably:
>
> diff --git a/builtin/rev-list.c b/builtin/rev-list.c
> index efe9360..3b2dca0 100644
> --- a/builtin/rev-list.c
> +++ b/builtin/rev-list.c
> @@ -147,8 +147,10 @@ static void show_commit(struct commit *commit, void *data)
> }
> } else {
> if (revs->commit_format != CMIT_FMT_USERFORMAT ||
> - buf.len)
> - printf("%s%c", buf.buf, info->hdr_termination);
> + buf.len) {
> + fwrite(buf.buf, 1, buf.len, stdout);
> + putchar(info->hdr_termination);
> + }
> }
> strbuf_release(&buf);
> } else {
This gives me a bit of a deja-vu: 1fb5fdd
Also, fwriting like that to stdout might be a bit troublesome on
Windows because the string won't end up going through our
ANSI-emulation.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html