Re: [PATCH v3] object-name: explain why <rev>~N fails in a shallow clone

[Patrick Steinhardt <ps@pks.im>]

On Mon, Nov 02, 2026 at 12:07:29PM +0100, Harald Nordgren wrote:
> > > Is it possible that maybe the review process needs to change if too
> > > many things are getting stuck?
> >
> > The regular reviewers have been talking about review work being scarce
> > compared to contributions (contributor work) for at least several years
> > now. How can this be changed if there simply aren’t enough people to
> > review everything?
> 
> We can loosen the requirements on perfect code, as long as it does
> what it's supposed to and doesn't have security backdoors.
> 
> Many things like tests, leaks and linting are already handled
> automatically by GitHub CI. It's a good time investment to automate
> more, because it frees up resources long-term.

Even if we automate more of it, that would still not fix our bottleneck.
I do no trust automated reviews enough to just merge patches without a
human review, as part of the review is also the conceptual direction
that we are moving towards. And that can only really be reviewed by
someone who is familiar with the project overall.

Now automation could of course still help us. For example, if
contributors started to self-review their patch series before sending
them out, or if we had a tool like Sashiko [1]. If so, the human review
would happen on a patch series that is in a better shape already, and
that would likely require less of a time investment overall.

Granted, at times we err too much on the side of polishing the last tiny
nits. But quite often that's also us trying to train newcomers to write
proper commit histories in the first place.

What I would very much like to avoid is reducing our standards just
because "carving in to AI is inevitable". I've heard that argument way
too often by now, and I don't think that it's a reasonable stance to
have. It is very much not "inevitable" that a project must move faster.

Patrick

[1]: https://sashiko.dev/