Re: [PATCH] index-pack: speed up promisor link recording

--6mp01P19UApuZmTM
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2026-08-02 at 22:12:16, Arijit Banerjee wrote:
> Thanks, Brian. I am not trying to bypass the project's policy.
>=20
> The investigation is in the same general spirit as the Git performance wo=
rk
> being tracked here:
> https://openai-git-upstream.openai.chatgpt.site/
>=20
> I do not claim to be an expert on this topic, but Codex appears to have f=
ound
> a material performance improvement of about 15% on end-to-end blobless cl=
one
> times.
>=20
> Would it be appropriate to treat the current submission as an RFC? It see=
ms
> 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.
--=20
brian m. carlson (they/them)
Toronto, Ontario, CA

--6mp01P19UApuZmTM
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

wr0EABYKAG8FgmpvxW8JEHwMSWKIh6KBRxQAAAAAAB4AIHNhbHRAbm90YXRpb25z
LnNlcXVvaWEtcGdwLm9yZ6NHStjjiegAfhzFFedCOZvYjlnYSFbVlAkxPryCN19W
FiEECCzmip28ZfuD0cORfAxJYoiHooEAADqoAQDeMeIAyGbySniO7vl8ACc+GncL
jAAnzrJJgNGrYPIdVgEAyDoJblhfAzqAC9A5+xRurjB5zTQmqerftSzaZyTFCwQ=
=i5Wp
-----END PGP SIGNATURE-----

--6mp01P19UApuZmTM--