From: Patrick Steinhardt <ps@pks.im>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Elia Pinto" <gitter.spiros@gmail.com>,
git@vger.kernel.org,
"Johannes Schindelin" <Johannes.Schindelin@gmx.de>,
"Jeff King" <peff@peff.net>,
"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Subject: Re: [PATCH v2 4/4] convert: use size_t for text statistics and ident counts
Date: Tue, 3 Nov 2026 07:59:33 +0100 [thread overview]
Message-ID: <aumGVZKfsCvdZ1T4@pks.im> (raw)
In-Reply-To: <xmqqzevrgfb0.fsf@gitster.g>
On Mon, Nov 02, 2026 at 12:16:03PM -0800, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
>
> >> You're completely right. I used AI tooling to help draft that commit
> >> message, and it definitely shows. Fair cop.
> >>
> >> To clarify my involvement: I review the code, check the cases, run the
> >> tests, and take full responsibility for what gets submitted. But the
> >> wording here missed the mark. For v3 I rewrote the message myself,
> >> keeping it much shorter, focusing on a single example (lone LFs), and
> >> dropping the heavy-handed explanations.
> >
> > Sorry, but is this reply to my ask to proof read what AI generates and
> > make it sound less AI generated repeating the _exact same thing_ that I
> > just asked you to change?
>
> [*]
>
> > To put it bluntly: behaviour like this is what will make me ignore your
> > patch series altogether going forward. It is frustrating to me, and I
> > only have limited time to spend on reviews. So I will much rather spend
> > my own time on patches where I don't feel like I'm talking to a meat
> > proxy, because I'm a (somewhat) social creature that prefers to talk to
> > humans.
> >
> > So please reevaluate what you are doing here.
>
> Sorry to interject but recognising the name as a rather long-time
> contributor from the pre-AI era, I am not sure what answer from Elia
> would have pleased you. Instead of saying that the initial work was
> done by AI, and that the human involvement was to sanity-check the
> product of the machine and tweak the messaging to reduce the
> machine-generated look, what do you want to see in contributors who
> work with AI?
>
> My question is not specifically about Elia's recent topics, but
> would apply more widely.
>
> Also, I had hard time to parse and understand [*] above. Did you
> mean "I asked you to proofread what AI generates so it sounds less
> AI-generated, and yet this very e-mail reply of yours is doing the
> exact same thing I just asked you to change", meaning "the message
> I am replying still sounds AI generated", or something?
Yes, my issue is that it is still obviously AI generated.
> Thinking aloud and letting my thoughts wander a bit.
>
> A contributor lets a machine generate a solution. Then he reads and
> understands every bit of it, writes a description of the solution as
> a commit log message from scratch without looking at the machine
> output, and from that message writes the code change from scratch.
> It is more like using the machine output as mere inspiration for his
> own iteration. I would imagine you do not have an issue with that.
Yes, that's totally fine. I wouldn't even mind if they didn't rewrite
everything from scratch. The important part to me is that I need to be
able to recognize that a human is involved. But especially AI-generated
messages have a very uncanny feeling to them, and one is very often able
to tell them apart from a message that is written by a human.
For code it's a different story: AI is very good at imitating the style
that we use in our code base, so my take is that you often wouldn't be
able to tell apart code written by AI and code written by humans. So the
only useful signal that I have left to identify whether an author has
invested time thinking about their changes is the prose that encompasses
the code change.
To me, this means that commit messages are becoming more important these
days with the current capabilities that AI has. Commit messages are the
one place where the author can demonstrate that they understand the
change they have submitted. So when the author submits a message 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", then I
will push back because I get the sense that there was no human involved
that understands the changes.
And that extends to messages that get sent on the mailing list, too.
> Now, which part would we find problematic in the above sequence if
> the contributor "cheats"? Perhaps he scans the machine output and,
> without understanding the most crucial bits, can still describe the
> outline of the solution from a superficial reading. He passes the
> code along as-is, together with the description he wrote with only a
> superficial understanding of the problem area. When the patch gets
> submitted, it would not look any different from the work of the
> earlier contributor who used the machine output as inspiration to
> write his own solution.
The pragmatic stance here is that I find none of that problematic: the
moment the author can prove that they understand their submission by
properly describing and explaining it I'm okay-ish (well, assuming the
code itself is of course fine). As said above, for many submissions it's
almost impossible to tell apart code written by AI and humans because AI
is able to imitate coding style quite well, and consequently I won't be
able to tell them apart anyway.
Now there's of course nuances here, and I'm still quite concerned about
copyright for AI-generated code. But especially for small contributions
I hope that's not going to be a huge liability going forward.
> However, if we later ask deeper questions when problems arise from the
> change, the latter contributor may not be able to provide as useful an
> answer as the former one who understood it deeply himself.
>
> But that is something we cannot easily tell just by looking at the
> submission, so ...
Yes. The moment they cannot answer questions or where those answers or
the descriptions of the change themselves are very likely written by AI,
that's where I start to question the submission.
Patrick
next prev parent reply other threads:[~2026-11-03 6:59 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-21 10:16 [PATCH 0/3] use size_t for a few more object and buffer sizes Elia Pinto
2026-10-21 10:16 ` [PATCH 1/3] odb: use size_t for the length of objects to write Elia Pinto
2026-10-21 11:24 ` Patrick Steinhardt
2026-10-21 10:16 ` [PATCH 2/3] diff: use size_t for the allocation size of word-diff buffers Elia Pinto
2026-10-21 11:24 ` Patrick Steinhardt
2026-10-21 10:16 ` [PATCH 3/3] convert: use size_t for buffer sizes Elia Pinto
2026-10-21 11:24 ` Patrick Steinhardt
2026-10-30 9:58 ` [PATCH v2 0/4] use size_t for a few more object and " Elia Pinto
2026-10-30 9:58 ` [PATCH v2 1/4] odb: use size_t for the length of objects to write Elia Pinto
2026-10-30 11:44 ` Patrick Steinhardt
2026-10-31 10:16 ` Elia Pinto
2026-10-30 9:58 ` [PATCH v2 2/4] diff: use size_t for the allocation size of word-diff buffers Elia Pinto
2026-10-30 9:58 ` [PATCH v2 3/4] convert: use size_t for buffer sizes Elia Pinto
2026-10-30 9:58 ` [PATCH v2 4/4] convert: use size_t for text statistics and ident counts Elia Pinto
2026-10-30 11:44 ` Patrick Steinhardt
2026-10-31 10:16 ` Elia Pinto
2026-11-02 11:09 ` Patrick Steinhardt
2026-11-02 20:16 ` Junio C Hamano
2026-11-03 6:59 ` Patrick Steinhardt [this message]
2026-10-31 10:16 ` [PATCH v3 0/4] use size_t for a few more object and buffer sizes Elia Pinto
2026-10-31 10:16 ` [PATCH v3 1/4] odb: use size_t for the length of objects to write Elia Pinto
2026-10-31 10:16 ` [PATCH v3 2/4] diff: use size_t for the allocation size of word-diff buffers Elia Pinto
2026-10-31 10:16 ` [PATCH v3 3/4] convert: use size_t for buffer sizes Elia Pinto
2026-10-31 10:16 ` [PATCH v3 4/4] convert: use size_t for text statistics and ident counts Elia Pinto
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=aumGVZKfsCvdZ1T4@pks.im \
--to=ps@pks.im \
--cc=Johannes.Schindelin@gmx.de \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=gitter.spiros@gmail.com \
--cc=peff@peff.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