On 25/03/13 01:33AM, Jeff King wrote: > > 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]: <Z9KNQ8XliWrrYgAT@xxxxxx>
