On Fri, Mar 14, 2025 at 10:02:11AM -0700, Junio C Hamano wrote:
> The developers who know that the revision walk infrastructure is
> shared between rev-list and log may wish that "-z" to mean the same
> thing for these two commands, but the end-users do not have to, no?
I think of them as related in a user-facing way, but it is likely that
my mind is poisoned by knowing too much of Git's internals. :)
> After all, "git log" accepts "-z" but "git rev-list" does not in the
> current system and nobody complained about the discrepancy so far.
Well, rev-list _does_ take "-z", but it just happens that it cannot ever
do anything because you cannot convince it to produce a diff. But even
knowing that is true is probably again a sign of my poisoned mind.
> Having said that, at the plumbing level, my preference is to have
> two independent options "--nul-delimited-{output,input}". It does
> not prevent us from starting with a single "-z" that works as a
> short-hand that flips both on (and is inconsistent with "git log" at
> the Porcelain level), but we can make "-z" only for output for
> consistency. As long as we agree on the design to allow us to
> control both sides independently, starting with "-z" that is only
> for output may be the best way forward.
Yeah, I almost suggested earlier having longer, unambiguous names. And
then that punts the issue from "which functionality should be available"
to "which functionality should be mapped to short-and-sweet -z".
I do think it's still worth considering what "-z" should do _now_,
though, because it will be painful/impossible to switch its behavior
later. And people seemed to like the "both input and output" direction.
That would leave the longer names as escape hatches. I.e., I'd expect:
git rev-list -z --no-nul-delimited-input --stdin
to use newlines for the input and NULs for the output.
-Peff
