Git development
 help / color / mirror / Atom feed
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: Arijit Banerjee <arijit@effectiveailabs.com>
Cc: Junio C Hamano <gitster@pobox.com>,
	Arijit Banerjee via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org, Jonathan Tan <jonathantanmy@fastmail.com>,
	Patrick Steinhardt <ps@pks.im>,
	Arijit Banerjee <arijit91@gmail.com>
Subject: Re: [PATCH] index-pack: speed up promisor link recording
Date: Mon, 3 Aug 2026 00:31:23 +0000	[thread overview]
Message-ID: <am_hWvag32v8yuNM@fruit.crustytoothpaste.net> (raw)
In-Reply-To: <CAFwoC-6EvoD-u7oceETi90MJ-FQA2zihdkn1i1wckKfoYRTKOw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3424 bytes --]

[please avoid top-posting]

On 2026-08-02 at 22:54:27, Arijit Banerjee wrote:
> Maybe software can ship experimental versions which is more indulging
> towards AI generated patches? Brave users get to try the features and they
> can baked into stable releases once there's enough soak time.
> 
> I have been holding onto my patch around hardware acceleration for SHA1-DC
> :)

The rationale, as Junio said, is based on the Developer's Certificate of
Origin.  That is a legal statement that a person has the legal right to
contribute those changes under the license and if they make a false or
misleading statement to that effect, they are responsible—legally and
otherwise—for it.

Considering the extensive litigation over LLM output at the moment, I
don't think anyone can clearly make that assertion.  Most of the
arguments I've heard are that it's fair use, which is a U.S. legal
concept.  That does not exist in Canada or the U.K., where there is fair
dealing, which is much more restricted.

If Company X includes LLM-generated code in their proprietary product
and it's found to be infringing in say, Germany, then they can simply
not distribute their code in Germany.  Git cannot do that: it's
distributed in Linux distributions around the planet, even in countries
subject to sanctions, such as Russia[0].  We must comply with the
license and the law everywhere in every country or we risk liability for
our contributors and distributors.  I, for one, am not willing to be
sued over this project and the project does not have the financial means
to deal with extensive litigation.

There are also concerns about the quality of the code and whether
submitters adequately understand the code well enough to have evaluated
and reviewed it thoroughly.  It's well known that when creating code
becomes cheap, the burden shifts to review and review becomes extremely
important.  That has been seen in lots of places, but we are an open
source project and we can't force contributors to do review like a
company can.  As Junio says, we already have trouble getting reviews
through and we don't want to make the problem worse.

LLM-generated content also has a negative quality reputation (see the
reaction to AI content in video games and books for an example) and
while all software has bugs, I appreciate the reputation that Git has
for quality and wish to retain that.

Those alone are reason enough for the policy, but there are other
concerns about the environmental impact, the impact on electricity and
hardware prices, the ethics of incorporating open source code without so
much as a credit[1], and a lot more.

So I don't think it's likely we're going to accept nontrivial
LLM-generated content in any capacity anytime soon and I don't think
trying to argue this or persuade us to accept it is going to be
productive or well received.  Of course, anyone can distribute their own
fork of Git with additional patches if they prefer, but we won't include
them.

[0] Debian, which distributes Git, has mirrors in Russia and Belarus:
https://www.debian.org/mirror/list
[1] For instance, as a member of ACM, I have to follow § 1.5 (Respect
the work required to produce new ideas, inventions, creative works, and
computing artifacts) of the Code of Ethics:
https://www.acm.org/code-of-ethics.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 325 bytes --]

  parent reply	other threads:[~2026-08-03  0:31 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-02 21:33 [PATCH] index-pack: speed up promisor link recording Arijit Banerjee via GitGitGadget
2026-08-02 21:51 ` brian m. carlson
2026-08-02 22:20   ` Arijit Banerjee
     [not found]   ` <CAFwoC-7wUzce_XvuviXZe=5eTxJ5yyCpz=vsOheWKPCnz9Kr4A@mail.gmail.com>
2026-08-02 22:32     ` brian m. carlson
2026-08-02 22:52       ` Junio C Hamano
2026-08-02 23:19         ` Arijit Banerjee
2026-08-02 22:46   ` Junio C Hamano
     [not found]     ` <CAFwoC-6EvoD-u7oceETi90MJ-FQA2zihdkn1i1wckKfoYRTKOw@mail.gmail.com>
2026-08-03  0:31       ` brian m. carlson [this message]
2026-08-03  0:55         ` Collin Funk

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=am_hWvag32v8yuNM@fruit.crustytoothpaste.net \
    --to=sandals@crustytoothpaste.net \
    --cc=arijit91@gmail.com \
    --cc=arijit@effectiveailabs.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    --cc=jonathantanmy@fastmail.com \
    --cc=ps@pks.im \
    /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