From: kristofferhaugsbakk@fastmail.com
Date: Fri, 01 May 2026 18:27:16 GMT
Subject: Re: [PATCH v3 5/5] format-rev: introduce builtin for on-demand pretty formatting
Message-ID: <20260501182718.27853-2-kristofferhaugsbakk@fastmail.com>
In-Reply-To: <e8bb57a2-8eff-4f72-96ca-72d8880901e0@gmail.com>

On Fri, May 1, 2026, at 12:16, Phillip Wood wrote:
>>[snip]
>> • You can’t feed commits piecemeal to these commands, one input
>>    for one output; they block until standard in is closed
>
> So you can feed them piecemeal but you don't get any output until you
> close stdin. That can be helpful as it means the calling process can
> write to "git log --stdin" and then read the output without worrying
> about getting deadlocked.

Okay. I don’t have much experience with concurrent programming.

> The Implementation below works fine if there
> are separate processes or threads writing to and reading from "git
> format-rev", but if we want a single process to be able to read from and
> write to "git format-rev --stdin-mode=text" there will need to be a way
> to delimit message boundaries so that git knows where the input message
> ends and the caller knows where the response ends.

Okay, so I guess a null-terminator mode for output.

> 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.

> 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?

> I think the functionality implemented here is useful (transforming the
> output of 'git blame' or 'git-last-modified' are convicing examples) and
> it is probably better to do it as a command rather than adding a
> "--format" option to name-rev.
>
>> • You can’t feed a list of possibly duplicate commits, like the output
>>    of git-last-modified(1); they effectively deduplicate the output
>
> That is definitely a problem

Great, thanks.

>> Beyond these two points there’s also the input massage problem: you
>
> s/massagge/message/?

No. I meant massaging the input so that it can be processed by whatever
tool you have. :) In this case splitting the object name column and file
column because tools like git-log(1) can only deal with revision input.

Thanks for reviewing the usability design.

-- 
Happy May Day