From: Junio C Hamano Date: Wed, 12 Mar 2025 15:56:01 GMT Subject: Re: [PATCH 0/4] rev-list: introduce NUL-delimited output mode Message-ID: In-Reply-To: Patrick Steinhardt writes: > On Tue, Mar 11, 2025 at 07:57:20PM -0400, Jeff King wrote: >> On Mon, Mar 10, 2025 at 02:28:25PM -0500, Justin Tobler wrote: >> >> > To make machine parsing easier, this series introduces a NUL-delimited >> > output mode for git-rev-list(1) via a `-z` option following a suggestion >> > from Junio in a previous thread[1]. In this mode, instead of LF, each >> > object is delimited with two NUL bytes and any object metadata is >> > separated with a single NUL byte. Examples: >> > >> > NUL NUL >> > [NUL ] NUL NUL >> > ? [NUL =]... NUL NUL >> > >> > In this mode, path and value info are printed as-is without any special >> > encoding or truncation. >> >> I think this is a good direction, but I have two compatibility >> questions: >> >> 1. What should "git rev-list -z --stdin" do? In most other programs >> with a "-z" option it affects both input and output. I don't >> particularly care about this case myself, but it will be hard to >> change later. So we probably want to decide now. > > I would lean into the direction of making "-z" change the format both > for stdin and stdout. That's what we do in most cases, and in those > cases where we didn't we came to regret it (git-cat-file(1)). I've seen "-Z", in addition to "-z", used to differentiate between input and output in some commands. If we are not going to do that, I agree that making "-z" to affect both input and output is less surprising than having to remember which side is still text.