On 09/12/2022 23:58, Junio C Hamano wrote:
Phillip Wood <phillip.wood123@xxxxxxxxx> writes:
Hi Toon
On 09/12/2022 15:00, Toon Claes wrote:
Since it's supported to have NUL-delimited input, introduced in
db9d67f2e9 (builtin/cat-file.c: support NUL-delimited input with `-z`,
2022-07-22), it's possible to pass paths that contain newlines. This
works great when the object is found, but when it's not, the input path
is returned in the error message. Because this can contain newlines, the
error message might get spread over multiple lines, making it harder to
machine-parse this error message.
With this change, the input is quote-formatted in the error message,
if
needed. This ensures the error message is always on a single line and
makes parsing the error more straightforward.
Thanks for working on this. I'd previously suggested NUL terminating
the output of "git cat-file -z" to avoid this problem [1] but quoting
the object name is a better solution.
Hmph. My knee-jerk reaction was that it is utterly disgusting if we
quote when we do NUL-terminated. Is your "quoting is OK over NUL
terminating" because "-z" applies only to the input?
Yes, if the object exists then delimiting the output with newlines is
fine, it is only if the object is missing and its name contains a
newline that there is a problem. It also makes adopting "-z" in existing
scripts easier as there is no change required when parsing the output.
As "-z" was added in 2.38 there is also a pragmatic reason to prefer
quoting over NUL terminated output as it allows us to fix this issue
without changing the output delimiter of an existing option.
If so, then I
would agree that is OK, but shouldn't the quoting apply regardless
of how the input is formulated? Why do we call the cquote helper
only under "-z"?
Without "-z" you cannot pass object names that contain newlines so not
quoting the output does not cause a problem. We could start quoting the
object name without "-z" but we'd be changing the output without a huge
benefit.
Best Wishes
Phillip
