From: Junio C Hamano Date: Mon, 10 Mar 2025 20:37:48 GMT Subject: Re: [PATCH 0/4] rev-list: introduce NUL-delimited output mode Message-ID: In-Reply-To: <20250310192829.661692-1-jltobler@gmail.com> Justin Tobler writes: > ? [SP =]... LF > > where values containing LF or SP are printed in a token specific fashion > so that the resulting encoded value does not contain either of these two > problematic bytes. For example, missing object paths are quoted in the C > style so they contain LF or SP. "so" -> "when"??? > 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 Why do we need double-NUL in the above two cases? > ? [NUL =]... NUL NUL This one I understand; we could do without double-NUL and take the lack of "=" in the token after NUL termination as the sign that the previous record ended, though, to avoid double-NUL while keeping the format extensible. As this topic is designing essentially a new and machine parseable format, we could even unify all three formats into one. For example, the format could be like this: NUL [= NUL]... where (1) A record ends when a new record begins. (2) The beginning of a new record is signaled by that is all hexadecimal and does not have any '=' in it. (3) The traditional "rev-list --objects" output that gives path in addition to the object name uses "path" as the name, i.e. such a record looks like " NUL path= NUL". (4) The traditional "rev-list --missing" output loses the leading "?"; it is replaced by "missing" as the name, i.e. such a record may look like " NUL missing=yes NUL..." together with other "= NUL" pairs appended as needed at the end. Hmm?