On 25/03/13 01:33AM, Jeff King wrote:

quoted

Furthermore, revision and pathspec argument parsing is all handled in
`setup_revisions()` so if we want to NUL-delimit arguments parsed on
stdin with -z, we would still need to parse the option early anyway. I
think it should be fine to leave the early -z option parsing as-is.

Makes sense. And I guess we might not want to have setup_revisions() do
that handling of "-z" for input, as that would make:

  git log --stdin --raw -z

behave differently (since it does not currently change stdin handling,
only the diff output). 

Yes, we won't want to include this '-z' parsing directly in
`setup_revisions()` or else it would change the behavior of other
commands.

In version two of this series, NUL-delimited stdin handling for
`setup_revisions()` is triggered by setting a `nul_delim_stdin` field in
`setup_revision_opt`. This gives the `setup_revisions()` caller the
ability to control the parsing delimiter itself. 

Only in git-rev-list(1) does the stdin parsing behavior change if '-z'
is also present. The behavior stdin parsing for `git log -z --stdin`
remains unchanged.

Though that does mean that these two commands
will behave differently:

  git log --stdin -z
  git rev-list --stdin -z

which seems...not great. My earlier suggestion to tie "-z" to stdin
handling was for consistency with other tools like grep. But if we
already have cases where "-z" is only for output, maybe it is better to
stay consistent with other parts of git. I.e., I was worried about us
painting ourselves into a corner with your patches, but we may have
already done so years ago. ;)

I think to some extent Git is already inconsistent here. IMO it would be
preferable for both input and output to use NUL as the delimiter when
machine parsing in git-rev-list(1) as that is the behavior I would
personally expect. I also agree with Patrick's reasoning else where in
this thread[1].

I'm open to discuss further though :)

Thanks,
-Justin

[1]: [ref]