Re: git log doesn't allow %x00 in custom format anymore?

[Erik Faye-Lund <kusmabite@gmail.com>]

On Thu, Oct 7, 2010 at 7:29 PM, Jeff King <peff@peff.net> 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.