Re: [PATCH 0/4] rev-list: introduce NUL-delimited output mode

From: Justin Tobler <jltobler@gmail.com>
Date: Mar 13, 2025, 16:41 UTC
Message-ID: <qapd7sijizopaefpxh3slgn7g2ecwdtyhzqzufcypciyv6n3qm@turmldwzipwe>
In-Reply-To: <20250313053329.GC94015@coredump.intra.peff.net>

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

Show 12 quoted lines

> > 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.

Show 12 quoted lines

> 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@pks.im>