git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Elijah Newren <newren@gmail.com>
Cc: "brian m. carlson" <sandals@crustytoothpaste.net>,
	 Christian Couder <christian.couder@gmail.com>,
	 git@vger.kernel.org,  Taylor Blau <me@ttaylorr.com>,
	 Rick Sanders <rick@sfconservancy.org>,
	 Git at SFC <git@sfconservancy.org>,
	 Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	 Patrick Steinhardt <ps@pks.im>,
	 Christian Couder <chriscool@tuxfamily.org>
Subject: Re: [PATCH v2] SubmittingPatches: add section about AI
Date: Sun, 12 Oct 2025 08:07:47 -0700	[thread overview]
Message-ID: <xmqq5xck5fb0.fsf@gitster.g> (raw)
In-Reply-To: <CABPp-BFf+_8cUc6sWZci9F0voosOQFWQ3x8dNs0YXEZ-uRvhNg@mail.gmail.com> (Elijah Newren's message of "Tue, 7 Oct 2025 21:18:12 -0700")

Elijah Newren <newren@gmail.com> writes:

>> ...
>> This policy may evolve as AI tools mature and the legal situation is
>> clarifed. In the meanwhile, requests for exceptions to this policy will be
>> evaluated by the Git project on a case by case basis. To be granted an
>> exception, a contributor will need to demonstrate clarity of the license and
>> copyright status for the tool's output in relation to its training model and
>> code, to the satisfaction of the project maintainers.
>
> I preferred the version Christian sent, but *if* we end up adopting
> some of the QEMU wording, I've got a logistics question:
>
>     Will we grandfather already accepted series, or proactively revert them?

Stepping back a bit, can we treat this new guideline element just
like any other guidelines in SubmittingPatches and also
CodingGuidelines?

We have certain rules in our SubmittingPatches and CodingGuidelines
to help us not get into trouble in the future.  We require the log
messages to follow certain style to give them uniformity as
otherwise it would become harder to dig the history later to find
cause of an issue we are having today, and more importantly what the
design parameters were back when the change we are having trouble
with was written.  We ask people to follow certain style in the code
as it would make it more work to understand code if different styles
are mixed together without reason.

But we also frown upon churning the codebase for the sake of
strictly match the prescribed coding style.  The rules are mostly to
control newly written things so that they do not make our codebase
into worse shape than it currently is.  When we update a part of our
codebase for some reason, other than "there is no particular reason
but we want to fix them to match guidelines", we would take existing
guideline violations the touched part may have into account, of
course.  And we find no need in our other non-AI guidelines to say
"we grandfather badness that already exists, but we try our best to
enforce the guidelines as strictly as possible", and the reason, I
think, is because that is implicitly what everybody expects.  Should
the "We tell you again not to blindly add things with unknown
origin, given the recent proliferation of AI coding product" rule be
any special and different?


  reply	other threads:[~2025-10-12 15:07 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-30 20:32 [RFC/PATCH] SubmittingPatches: forbid use of genAI to generate changes Junio C Hamano
2025-06-30 21:07 ` brian m. carlson
2025-06-30 21:23   ` Collin Funk
2025-07-01 10:36 ` Christian Couder
2025-07-01 11:07   ` Christian Couder
2025-07-01 17:33     ` Junio C Hamano
2025-07-01 16:20   ` Junio C Hamano
2025-07-08 14:23     ` Christian Couder
2025-10-01 14:02 ` [PATCH v2] SubmittingPatches: add section about AI Christian Couder
2025-10-01 18:59   ` Chuck Wolber
2025-10-01 23:32     ` brian m. carlson
2025-10-02  2:30       ` Ben Knoble
2025-10-03 13:33     ` Christian Couder
2025-10-01 20:59   ` Junio C Hamano
2025-10-03  8:51     ` Christian Couder
2025-10-03 16:20       ` Junio C Hamano
2025-10-03 16:45         ` rsbecker
2025-10-08  7:22         ` Christian Couder
2025-10-01 21:37   ` brian m. carlson
2025-10-03 14:25     ` Christian Couder
2025-10-03 20:48     ` Elijah Newren
2025-10-03 22:20       ` brian m. carlson
2025-10-06 17:45         ` Junio C Hamano
2025-10-08  4:18           ` Elijah Newren
2025-10-12 15:07             ` Junio C Hamano [this message]
2025-10-08  9:28           ` Christian Couder
2025-10-13 18:14             ` Junio C Hamano
2025-10-23 17:32               ` Junio C Hamano
2025-10-08  4:18         ` Elijah Newren
2025-10-08  8:37         ` Christian Couder
2025-10-08  9:28           ` Michal Suchánek
2025-10-08  9:35             ` Christian Couder
2025-10-09  1:13           ` Collin Funk
2025-10-08  7:30       ` Christian Couder

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=xmqq5xck5fb0.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=chriscool@tuxfamily.org \
    --cc=christian.couder@gmail.com \
    --cc=git@sfconservancy.org \
    --cc=git@vger.kernel.org \
    --cc=me@ttaylorr.com \
    --cc=newren@gmail.com \
    --cc=ps@pks.im \
    --cc=rick@sfconservancy.org \
    --cc=sandals@crustytoothpaste.net \
    /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;
as well as URLs for NNTP newsgroup(s).