Re: b4 review available in master

Konstantin Ryabitsev
2026-03-18T13:26:18Z

On Wed, Mar 18, 2026 at 08:56:56AM +0100, Geert Uytterhoeven wrote:
> > However, I am now curious to hear your feedback. The idea with the review app
> > is that you are not really sending an email, you're adding comments to code
> > and adding review trailers. The app will render and send that out for you,
> > trimming and formatting things nicely so you don't have to do it on your own
>
> I haven't tried b4 review yet, but how do you decide what (not) to trim?
> It is not uncommon to explicitly not trim some parts, as they are important
> to understand the comment on a seemingly unrelated part.

We are obviously opinionated, but so is git, which by default gives 3 lines of
before/after context. Our logic is:

- always leave file and hunk headers intact
- give at least 6 lines of context above your content (double git's)
- check the remaining lines between the previous comment or the hunk start
(@@ .. @@) and trim if more than 10 lines, replacing with
[... skip NN lines ...]

If you're commenting on some code that requires a lot of context, it's easy to
do:

Let's look at this chunk:

> context
> -bar
> +foo

Using foo here is not correct.

> context
> context
>-baz
>+quux

etc

But, honestly, I think we're giving lots of context for the original
maintainer to understand what the comment is about, and since the file/hunk
headers are there, they can always find the code in question.

> > (I've noticed that many maintainers don't bother anyway -- there are emails
> > with a terse comment at the top and then a huge quoted bottom that is only
> > followed by their sig.
>
> IMHO this is very bad behavior: not trimming replies forces everyone
> to skim the remainder for more comments.

I wholeheartedly agree, but pointing and shaming probably isn't the right
course of action.

Regards,
--
KR