Re: [RFC PATCH 1/1] SubmittingPatches: allow responsible AI assistance

[Patrick Steinhardt <ps@pks.im>]

On Thu, Oct 08, 2026 at 03:53:11PM +0200, Scott Chacon wrote:
> On Thu, Oct 8, 2026 at 12:44 AM Junio C Hamano <gitster@pobox.com> wrote:
> > Scott Chacon <scott@gitbutler.net> writes:
[snip]
> > It looks, at least to me, that there is not much that can be
> > meaningfully enforced by reviewers and followed by contributors in
> > the above text.  It seems to be little more than "the world would be
> > a wonderful place if everybody behaved this way."
> >
> > A violation of "concise and relevant" seems to be the recent trend
> > of much AI-generated slop, so it may be a good suggestion to give
> > today.  But would we need to update it once the trend of text
> > generated by AI tools becomes "concise and relevant" nonsense that
> > merely sounds plausible?  What if an "AI-assisted" contributor lacks
> > common sense to tell between plausible-sounding nonsense and a
> > well-written description?  What if reviewers get too many such
> > "contributions" and cannot allocate enough review bandwidth to sift
> > good contributions from plausible-sounding nonsense?
> 
> This is a fair point, but you'll get unreviewed crap either way. I'm
> sure you already are. However, I don't think people who submit
> complete bullshit are reading the SubmittingPatches file in the first
> place, so I'm not sure that opening this wording up a little is going
> to make much of a difference here.
> 
> My recent patch series converting the sha1dc is a possible example. I
> don't understand all of the code it wrote. I read through it, but
> there are some crazy tables and complex math in there. The first pass
> did a weird Rust to C machine translation rather than reimplement it
> in more idiomatic C, so I had it rewrite that - so there was some
> approach guidance, but again, I wasn't hand crafting the code. I did,
> however, spend a lot of time and resources testing and benchmarking it
> on multiple architectures so that I was reasonably confident that it
> was fast and correct.
> 
> But I hesitated to submit it at all because I knew the policy. I only
> sent it so that if someone at GitHub or OpenAI or whatever wanted to
> use it in an internal fork so they could save a ton of CPU, this would
> be a way to get the implementation. I was aware that, although I
> believe the patch is quite reasonable and valuable, due to the
> conservative AI policies of this project, it would not seriously be
> considered no matter what.

I would argue that this is a good thing though. We want people to thing
twice before submitting code that they don't fully understand, don't we?
Otherwise we will get even more slop than we already get.

> My point with this change is to open the possibility for AI assisted
> change that is reasonable, similar to the Linux kernel's approach.

We already are accepting AI-generated code. So if the change would have
the effect that people _don't_ think twice anymore about sending their
AI generated code to the mailing list then I think that's a net-negative
change.

The bottleneck of the Git project has never really been the amount of
code that people can write, but the number of developers that we have
reviewing it. And you can feel that this bottleneck is getting tighter
now with AI -- over the last couple months I have spent way more time
reviewing stuff, and the number of times that I noticed too late that
I'm reviewing slop is going up steadily. I guess for Junio that must be
even worse.

So I think loosening our AI policy shouldn't go without finding
solutions for this problem first, because otherwise I feel like we are
just going to make a preexisting problem significantly worse.

Patrick