Re: [PATCH v3 5/5] format-rev: introduce builtin for on-demand pretty formatting

["Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com>]

On Sat, May 2, 2026, at 12:00, Phillip Wood wrote:
>>>[snip]
>>> We'll also need to be
>>> careful about flushing the output at the end of a processed message.
>>
>> I don’t get why this takes special care. I’ll think about it.
>
> Because the output from printf() is buffered, unless you explicitly
> flush it you can get into a state where git thinks it has printed the
> output and is waiting for the caller to write more input, but the caller
> is still waiting to read git's output and so they are deadlocked.
> Calling maybe_flush_or_die() is the usual way to handle this I think -
> see 344a107b55 (merge-tree --stdin: flush stdout to avoid deadlock,
> 2025-02-18)

Ah, I understand now. Very well explained. Thanks :)

>>> For "--stdin-mode=revs" the caller cannot know how many lines the output
>>> will span because formats like %(trailers) will produce a variable
>>> number of lines depending on which trailers are present. It is also
>>> possible for a rev name to span more than one line. The following
>>> example finds the most recent commit that mentions 'cherry-pick' in the
>>> subject line
>>>
>>> :/^[^
>>> ]cherry-pick
>>>
>>> so we need a way to delimit the input and output records there as well.
>>
>> Okay, so a null-terminator mode for input as well?
>
> Yes I think "-z" should mean NUL terminated input and output.

I will use `-z` (and `--null`) to mean NUL terminated input and output
based on your recommendation and because I see that it is the approach
used in other commands that I have found that have NUL termination for
both stdin and stdout.

I also want to supply `--null-input` and `--null-output` since I think
`--null-output` will be more generally useful.

***

That these long options ended up being called `--null` instead of
`--nul` by convention is maybe just a historical accident? Considering
one writes NUL byte/character.

>[snip]