cat-file: Introduce new option to delimit output with NUL characters

In db9d67f2 (builtin/cat-file.c: support NUL-delimited input with -z, 2022-07-22), we have introduced a new mode to read the input via NUL-delimited records instead of newline-delimited records. This allows the user to query for revisions that have newlines in their path component. While unusual, such queries are perfectly valid and thus it is clear that we should be able to support them properly.

Unfortunately, the commit only changed the input to be NUL-delimited, but didn't change the output at the same time. While this is fine for queries that are processed successfully, it is less so for queries that aren't. In the case of missing commits for example the result can become entirely unparsable:

$ printf "7ce4f05bae8120d9fa258e854a8669f6ea9cb7b1 blob 10\n1234567890\n\n\commit000" |
    git cat-file --batch -z
7ce4f05bae8120d9fa258e854a8669f6ea9cb7b1 blob 10
1234567890

commit missing

This is of course a crafted query that is intentionally gaming the deficiency, but more benign queries that contain newlines would have similar problems.

Ideally, we should've changed the output to be NUL-delimited when -z is specified when we introduced that change to avoid this problem. As the input is NUL-delimited, it is clear that the output in this case cannot ever contain NUL characters by itself. Furthermore, Git does not NUL characters in revisions anyway, further stressing the point that using NUL-delimited output is safe. But even though -z has only been introduced a few releases ago in Git v2.38.0, changing it retroactively to also NUL-delimit output would be a backwards-incompatible change. And while one could make the argument that the output is inherently broken already, we need to assume that there are existing users out there that use it just fine given that revisions containing newlines are quite exotic.

Instead, we introduce a new option -Z that switches to NUL-delimited input and output. The old -z option is marked as deprecated with a hint that its output may become unparsable.

Co-authored-by: Toon Claes toon@iotcl.com Signed-off-by: Patrick Steinhardt ps@pks.im

Closes #141 (closed).