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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 7, 2026, 22:44 UTC
Message-ID: <xmqqcxtl3zda.fsf@gitster.g>
In-Reply-To: <20261007142954.31761-2-scott@gitbutler.net>

Scott Chacon <scott@gitbutler.net> writes:

Show 6 quoted lines

> As an example, an OpenAI model was used to help me research, compare and
> craft the appropriate legal language for this policy change to help us
> match the modern, legally reviewed approaches now taken by peer GPL
> projects such as the Linux kernel [1].
>
> [1] https://docs.kernel.org/process/coding-assistants.html

That makes it sound as if this is just as legally sound as what the kernel project uses. However, the only assurance we get (unless you are willing to act as our lawyer, and I do not know if you are one) is that an OpenAI model produced plausible-sounding utterances.

Indeed, the proposed text seems to instruct developers and reviewers to do quite different things from the rules I see in the above URL. Note that in the following, I will be playing devil's advocate for much of the time, so please accept my apologies in advance if I sound too skeptical.

Show 12 quoted lines

> +AI tools may be used to help prepare contributions, including code,
> +tests, documentation, and commit messages. AI assistance does not by
> +itself disqualify a contribution. The same requirements for correctness,
> +maintainability, licensing, and review apply regardless of the tools
> +used.
> +
> +You are responsible for the entire contribution. Before submitting it,
> +review and understand the changes, check factual claims, and perform
> +the testing appropriate to the change. Be prepared to explain your
> +decisions and respond to review comments. Do not pass unreviewed tool
> +output on to reviewers, including in commit messages or mailing list
> +replies. Keep explanations concise and relevant to the change.

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?

Show 8 quoted lines

> +The <<dco,Developer's Certificate of Origin>> applies unchanged. Only a
> +human can make that certification; an AI tool cannot sign off on your
> +behalf. Consider the origin and licensing of generated material,
> +including any third-party material it reproduces, and comply with
> +applicable license and attribution requirements. A tool's assurance
> +that its output is original or compatible with our license is not a
> +substitute for checking those requirements. If you cannot certify the
> +DCO for a contribution, do not submit it.

Again, this is a good aspiration to have, but I doubt that anyone can practically certify that the output of an LLM is devoid of content borrowed from problematic sources under the rule the text above gives. Would it not be more useful to help contributors by defining what not to do more clearly? Our current text says as much more directly: you cannot practically certify, so do not send in AI-generated slop, period.

Show 7 quoted lines

> +Disclose substantial AI assistance in each affected commit with an
> +`Assisted-by:` trailer naming the tool and, when available, its model
> +or version. For example:
> +
> +....
> +	Assisted-by: ExampleTool version 1.2
> +....

I thought the kernel guidelines instructed us to say only "LLM" these days, to avoid giving free advertising. On the other hand, they ask contributors to also list non-LLM tools, like coccinelle and clang-tidy, that were used in their machine-assisted contributions. I am undecided on the merit of specifying the exact model and version, but listing non-LLM tools alongside materials for independent reproduction looks like a good idea.

> +Maintainers may request more explanation, testing, or information about
> +provenance, and may decline contributions they cannot confidently
> +assess.

The text of the kernel guidelines appears to give maintainers more latitude (cf. https://docs.kernel.org/process/generated-content.html). They can treat it just like any other contribution, reject it outright, or choose any approach in between. The proposed text above does not account for cases where reviewers simply lack the bandwidth to even think about what explanation and proof to request, and it makes it sound as if declining a submission in such a case an unfair rejection.