threads / discuss / 48964

Multiple consecutive null bytes with log -z --name-only

Subject: Multiple consecutive null bytes with log -z --name-only

## tl;dr

2 messages between Jul 27, 2018 and Jul 27, 2018.

replies: 1people: 2as markdown or json

Drew Noakes· Jul 27, 2018, 20:20 UTC · lore
Hi all,

I'm a developer on the Git Extensions project [1] and am looking at an issue parsing the output of `git log` in that application.

Some investigation suggests that a certain combination of arguments causes multiple consecutive null bytes between rows, where I would ordinarily expect one.

Passing -z with --name-only causes double nulls.

$ git log -z --pretty=format:"%H" --name-only | grep -obUaP "\x00\x00" | wc -l 8994 $ git log -z --pretty=format:"%H" | grep -obUaP "\x00\x00" | wc -l 0

We can work around this issue, but I would like to understand if it's a bug or if there's some information to be gleaned here.

$ git --version git version 2.18.0.windows.1

Many thanks,
Drew
[1] https://github.com/gitextensions/gitextensions
Junio C Hamano· Jul 27, 2018, 22:12 UTC · re: Drew Noakes · lore

Re: Multiple consecutive null bytes with log -z --name-only

Drew Noakes <drew@drewnoakes.com> writes:
Show 7 quoted lines
> Passing -z with --name-only causes double nulls.
>
> $ git log -z --pretty=format:"%H" --name-only | grep -obUaP "\x00\x00" | wc
> -l
> 8994
> $ git log -z --pretty=format:"%H" | grep -obUaP "\x00\x00" | wc -l
> 0

With --pretty that tells you to show %H and --name-only that tells you to show names of paths that were touched by each commit, you'd need to be able to distinguish commit object name (or whategver you give --pretty=format to) and each pathname, and because you are driving "log", you also should be able to see where info for one commit ends and the next one starts.

So I'd imagine that for a commit that touches N paths, you would get (one pathname followed by NUL) N times, and then another NUL after that to let you know that you read all the pathnames for that commit.

By the way, tools should be reading from "--format=...", not from "--pretty=format:...". The --format=... option is for human consumption and gives LF (or NUL when -z is used) the "separator" semantics, i.e. when listing things A B and C, we would throw separator in between but not before the first one (obviously) and not after the last one. "--format=..." which is a synonym for "--pretty=tformat:..." is designed for tool consumption and gives LF (or NULL when -z i used) the "terminator" semantics, i.e. each item in the output is followed by terminator, so in addition to LF/NUL after A and B in the example in this paragraph, you also get one after C, which is the last item.

	

← back to recent threads