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

[Phillip Wood <phillip.wood123@gmail.com>]

On 02/11/2026 12:24, Patrick Steinhardt wrote:
> On Mon, Nov 02, 2026 at 12:07:29PM +0100, Harald Nordgren wrote:
>> 
>> 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,

The CI checks that the tests pass. It does not tell is if there is a 
sensible amount of test coverage for the change that's being made. 
Stolee used to run a coverage report which was helpful to highlight any 
glaring holes in our coverage but I think he stopped running it because 
it was quite time consuming to maintain. Even having that doesn't tell 
us if someone has added a million pointless tests that slow the test 
suite down - that still requires someone to read and understand them.

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

Having automated checks for common errors is certainly a good idea

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

Agreed - it is no good having a "perfect" patch if it implements a bad idea.

> Now automation could of course still help us. For example, if
> contributors started to self-review their patch series before sending
> them out, 

That would be really helpful. Once someone has submitted a few patches 
they should know what issues reviewers are likely to bring up and be 
able to preempt that by at least trying to fix those issues before the 
submitting their patches. I don't mind spending time helping new 
contributors get used to the process, but after a few series they really 
should have got the hang of writing a cover letter and thinking about 
how their changes affect other users.

A while ago Junio floated the idea of requiring review contributions 
from contributors who submit patches. I wonder it would help to say 
something like "for every three patch series you submit you should 
provide an in-depth review of one series from another contributor". I'm 
not sure how well that would work (I seem to remember reading PostgreSQL 
tried something similar and ended up abandoning it) but it might be 
worth a try.

Thanks

Phillip
  > 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/