{"thread":{"id":"48964","subject":"Multiple consecutive null bytes with log -z --name-only","startedAt":"2018-07-27T20:21:10Z","lastAt":"2018-07-27T22:12:35Z","messageCount":2,"participants":["Drew Noakes","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"353751","messageId":"CAJd66x7ZHn=6AHFRXo5E4MhzEiW98Mpf37JRWv_18U5eYFeVJg@mail.gmail.com","threadId":"48964","inReplyTo":null,"subject":"Multiple consecutive null bytes with log -z --name-only","fromName":"Drew Noakes","fromEmail":"drew@drewnoakes.com","sentAt":"2018-07-27T20:20:54Z","receivedAt":"2018-07-27T20:21:10Z","isPatch":false,"sender":{"key":"drew@drewnoakes.com","avatar":null},"body":"Hi all,\n\nI'm a developer on the Git Extensions project [1] and am looking at an\nissue parsing the output of `git log` in that application.\n\nSome investigation suggests that a certain combination of arguments causes\nmultiple consecutive null bytes between rows, where I would ordinarily\nexpect one.\n\nPassing -z with --name-only causes double nulls.\n\n$ git log -z --pretty=format:\"%H\" --name-only | grep -obUaP \"\\x00\\x00\" | wc\n-l\n8994\n$ git log -z --pretty=format:\"%H\" | grep -obUaP \"\\x00\\x00\" | wc -l\n0\n\nWe can work around this issue, but I would like to understand if it's a bug\nor if there's some information to be gleaned here.\n\n$ git --version\ngit version 2.18.0.windows.1\n\nMany thanks,\n\nDrew\n\n[1] https://github.com/gitextensions/gitextensions\n"},{"id":"353764","messageId":"xmqq36w4l44x.fsf@gitster-ct.c.googlers.com","threadId":"48964","inReplyTo":"CAJd66x7ZHn=6AHFRXo5E4MhzEiW98Mpf37JRWv_18U5eYFeVJg@mail.gmail.com","subject":"Re: Multiple consecutive null bytes with log -z --name-only","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-07-27T22:12:30Z","receivedAt":"2018-07-27T22:12:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Drew Noakes <drew@drewnoakes.com> writes:\n\n> Passing -z with --name-only causes double nulls.\n>\n> $ git log -z --pretty=format:\"%H\" --name-only | grep -obUaP \"\\x00\\x00\" | wc\n> -l\n> 8994\n> $ git log -z --pretty=format:\"%H\" | grep -obUaP \"\\x00\\x00\" | wc -l\n> 0\n\nWith --pretty that tells you to show %H and --name-only that tells\nyou to show names of paths that were touched by each commit, you'd\nneed to be able to distinguish commit object name (or whategver you\ngive --pretty=format to) and each pathname, and because you are\ndriving \"log\", you also should be able to see where info for one\ncommit ends and the next one starts.\n\nSo I'd imagine that for a commit that touches N paths, you would get\n(one pathname followed by NUL) N times, and then another NUL after\nthat to let you know that you read all the pathnames for that\ncommit.\n\nBy the way, tools should be reading from \"--format=...\", not from\n\"--pretty=format:...\".  The --format=... option is for human\nconsumption and gives LF (or NUL when -z is used) the \"separator\"\nsemantics, i.e. when listing things A B and C, we would throw\nseparator in between but not before the first one (obviously) and\nnot after the last one.  \"--format=...\" which is a synonym for\n\"--pretty=tformat:...\" is designed for tool consumption and gives LF\n(or NULL when -z i used) the \"terminator\" semantics, i.e. each item\nin the output is followed by terminator, so in addition to LF/NUL\nafter A and B in the example in this paragraph, you also get one\nafter C, which is the last item.\n\n\n\t\n"}]}