Git development
 help / color / mirror / Atom feed
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: Arijit Banerjee <arijit@effectiveailabs.com>
Cc: Arijit Banerjee via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org, Jonathan Tan <jonathantanmy@fastmail.com>,
	Patrick Steinhardt <ps@pks.im>,
	Junio C Hamano <gitster@pobox.com>,
	Arijit Banerjee <arijit91@gmail.com>,
	ttaylorr@openai.com
Subject: Re: [PATCH] index-pack: speed up promisor link recording
Date: Sun, 2 Aug 2026 22:32:16 +0000	[thread overview]
Message-ID: <am_Fb79hCnwmRzjL@fruit.crustytoothpaste.net> (raw)
In-Reply-To: <CAFwoC-7wUzce_XvuviXZe=5eTxJ5yyCpz=vsOheWKPCnz9Kr4A@mail.gmail.com>

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

On 2026-08-02 at 22:12:16, Arijit Banerjee wrote:
> Thanks, Brian. I am not trying to bypass the project's policy.
> 
> The investigation is in the same general spirit as the Git performance work
> being tracked here:
> https://openai-git-upstream.openai.chatgpt.site/
> 
> I do not claim to be an expert on this topic, but Codex appears to have found
> a material performance improvement of about 15% on end-to-end blobless clone
> times.
> 
> Would it be appropriate to treat the current submission as an RFC? It seems
> worth trying to preserve the technical result.

I don't think the project's policy prevents you from doing analysis and
investigation with an LLM, although it does require you to verify the
correctness of the results and be accountable for them.  If, based on
the analysis of the performance impact, you write some code without the
use of an LLM that improves things, I think that would be allowed and
probably welcome, assuming it is otherwise acceptable.  Some
contributors will be willing to review such a contribution and others
will not, but it is not outside of the policy.

However, writing substantial code with an LLM doesn't appear to be
allowed.  The kinds of trivial changes that I think would be allowed to
be generated would be things like fixing spelling errors or adding
include guards to header files that lack them.  Of course, these are
also the kinds of things you could mostly fix with a small script, which
is why they are generally considered so trivial as to be
uncopyrightable.

So I think to have a patch accepted in this case, you would need to
totally discard the existing patch and rewrite it by hand without
recourse to the generated code.

I understand that the SubmittingPatches documentation is a bit long, but
I do suggest giving it at least a glance so you know what to expect.  I
think reading this sort of contributing documentation is more important
than ever since, in the era of LLMs, projects tend to have strong
opinions on what is and is not acceptable, not only just in terms of LLM
usage, but in how code and documentation are to be written and
formatted.
-- 
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-02 22:32 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 [this message]
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
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_Fb79hCnwmRzjL@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 \
    --cc=ttaylorr@openai.com \
    /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