Git development
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: m@suozzo.co,
	 Matthew Suozzo via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org
Subject: Re: [PATCH] reftable/record: bound an object record's offset count by its length
Date: Tue, 20 Oct 2026 08:08:01 -0700	[thread overview]
Message-ID: <xmqqqzhkxve6.fsf@gitster.g> (raw)
In-Reply-To: <atcKOhm0Kd5XryAg@pks.im> (Patrick Steinhardt's message of "Tue, 20 Oct 2026 08:29:14 +0200")

Patrick Steinhardt <ps@pks.im> writes:

> It's hard to say. With AI-generated commit messages you very often have
> the feeling that you end up understanding everything and nothing. It
> just feels off in a way that is hard to describe, and consequently it's
> also hard to say what exactly needs changing.
>
> My typical suggestion is to not use AI to write your commit message at
> all and instead write it yourself. Commit messages have always been the
> place where you can demonstrate that you understand what you are doing
> as part of the patch by properly explaining it in a way that another
> human being understands it. And I think that role is becoming even more
> important now: in a world where we cannot trust that the contributor has
> the slightest understanding of what they are contributing, they need to
> go the extra mile to prove it to us by having a well-written explanation
> thereof.
>
> I know that this is putting more of a burden on contributors, and I'm
> not a fan of that. But I think it's becoming abundantly clear that AI
> does not really give open communities much of a choice, at least not if
> they want to keep standards high.

Putting more burden on the user is fine, and the AI output, when
used correctly, can be not so bad.

Having said that, the real problem is that nobody seems to guide
generative AI machinery well enough to make intelligible output.  In
order for a user to guide the machinery well enough, they must know
what they want to discuss, and the output would be different from
what a clueless and hands-off "here is a bug report from somewhere I
saw, I do not understand the system well enough, solve it and
describe the solution" prompt would result in.

Writing the first draft manually and having a machine check and
correct typos and grammar is not a bad practice, as you remain in
control of the overall structure and contents of the final result.

Going in the other direction?  If you are not familiar with the area
and are easily fooled by intelligent-sounding nonsense uttered by
generative AI, correcting such nonsense into a usable shape would be
difficult, and would make those on the receiving end who have to
read it miserable.

By the way, I cannot help but wonder what happened to the AI policy
discussion that the contributors' summit promised we would have
soon.  Who is organizing it?

  reply	other threads:[~2026-10-20 15:08 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-14 14:58 [PATCH] reftable/record: bound an object record's offset count by its length Matthew Suozzo via GitGitGadget
2026-10-19  7:46 ` Patrick Steinhardt
2026-10-19 17:14   ` m
2026-10-20  6:29     ` Patrick Steinhardt
2026-10-20 15:08       ` Junio C Hamano [this message]
2026-10-20 15:10         ` Patrick Steinhardt
2026-10-20 16:54       ` Aniket Gupta

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=xmqqqzhkxve6.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=m@suozzo.co \
    --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