Re: git log doesn't allow %x00 in custom format anymore?
From: Erik Faye-Lund <hidden>
Date: 2016-06-15 22:49:43
On Thu, Oct 7, 2010 at 7:29 PM, Jeff King [off-list ref] wrote:
quoted hunk ↗ jump to hunk
On Thu, Oct 07, 2010 at 07:18:18PM +0400, Kirill Likhodedov wrote:quoted
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 0000064Ugh. 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.