Git development
 help / color / mirror / Atom feed
From: Scott Chacon <scott@gitbutler.net>
To: git@vger.kernel.org
Subject: [RFC PATCH 1/1] SubmittingPatches: allow responsible AI assistance
Date: Wed,  7 Oct 2026 16:29:54 +0200	[thread overview]
Message-ID: <20261007142954.31761-2-scott@gitbutler.net> (raw)
In-Reply-To: <20261007142954.31761-1-scott@gitbutler.net>

The AI section encourages careful use of AI tools, but also says we
will reject anything that looks AI generated. That leaves contributors
without a clear path for submitting useful, reviewed, understood work and
can discourage disclosure of the assistance they received.

Allow AI-assisted contributions under the usual quality and licensing
requirements. Require human understanding, appropriate testing, and
disclosure of substantial assistance. Retain the DCO without changing
its terms, and require contributors to consider provenance and meet
applicable license obligations. Reviewers can ask for further evidence
or decline work they cannot confidently assess.

Replace the appearance-based rejection rule with these concrete
expectations. AI assistance neither excuses an inadequate submission
nor prevents an otherwise acceptable one from being considered.

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

Assisted-by: OpenAI GPT-6 Astra
Signed-off-by: Scott Chacon <scott@gitbutler.net>
---
 Documentation/SubmittingPatches | 73 ++++++++++++++++++++++-----------
 1 file changed, 49 insertions(+), 24 deletions(-)

diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index c60855f706..f703f96667 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -571,30 +571,55 @@ the patches.
 [[ai]]
 === Use of Artificial Intelligence (AI)
 
-The Developer's Certificate of Origin requires contributors to certify
-that they know the origin of their contributions to the project and
-that they have the right to submit it under the project's license.
-It's not yet clear that this can be legally satisfied when submitting
-significant amount of content that has been generated by AI tools.
-
-Another issue with AI generated content is that AIs still often
-hallucinate or just produce bad code, commit messages, documentation
-or output, even when you point out their mistakes.
-
-To avoid these issues, we will reject anything that looks AI
-generated, that sounds overly formal or bloated, that looks like AI
-slop, that looks good on the surface but makes no sense, or that
-senders don’t understand or cannot explain.
-
-We strongly recommend using AI tools carefully and responsibly.
-
-Contributors would often benefit more from AI by using it to guide and
-help them step by step towards producing a solution by themselves
-rather than by asking for a full solution that they would then mostly
-copy-paste. They can also use AI to help with debugging, or with
-checking for obvious mistakes, things that can be improved, things
-that don’t match our style, guidelines or our feedback, before sending
-it to us.
+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.
+
+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.
+
+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
+....
+
+In the accompanying explanation, briefly describe how the tool helped,
+which parts of the contribution it affected, and how you checked the
+result. This can go in the cover letter or below the `---` line in the
+patch email. Disclose substantial assistance with mailing list replies
+in those replies as well. Trivial spelling corrections, formatting,
+and identifier completion do not need disclosure. When in doubt,
+disclose the assistance.
+
+Keep relevant prompts and outputs to help answer questions during
+review. Include short prompts, or a summary of longer sessions, when
+they help explain the change. Do not include credentials or private
+material in these records when sharing them.
+
+Maintainers may request more explanation, testing, or information about
+provenance, and may decline contributions they cannot confidently
+assess. Tool use does not entitle a contribution to review or
+acceptance. Discuss plans for large-scale automated submissions on the
+mailing list before sending them; generating patches faster does not
+increase the project's capacity to review them.
 
 [[git-tools]]
 === Generate your patch using Git tools out of your commits.
-- 
2.50.1 (Apple Git-155)


  reply	other threads:[~2026-10-07 14:29 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-07 14:29 [RFC PATCH 0/1] SubmittingPatches: allow responsible AI assistance Scott Chacon
2026-10-07 14:29 ` Scott Chacon [this message]
2026-10-07 21:42   ` [RFC PATCH 1/1] " brian m. carlson
2026-10-08  4:49     ` Scott Chacon
2026-10-08  5:29       ` Luca Milanesio
2026-10-08  5:53       ` Kristoffer Haugsbakk
2026-10-08 16:15       ` brian m. carlson
2026-10-07 22:44   ` Junio C Hamano
2026-10-08 13:53     ` Scott Chacon
2026-10-09 10:22       ` Patrick Steinhardt
2026-10-09 20:39         ` Junio C Hamano
2026-10-08 18:10 ` [RFC PATCH 0/1] " D. Ben Knoble

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261007142954.31761-2-scott@gitbutler.net \
    --to=scott@gitbutler.net \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox