Re: [PATCH v2] describe: limit default ref iteration to tags

[Patrick Steinhardt <ps@pks.im>]

On Tue, Jun 09, 2026 at 07:09:57AM -0400, Jeff King wrote:
> On Mon, Jun 08, 2026 at 07:32:14PM -0700, Tamir Duberstein wrote:
> 
> > The benchmark checkout had 120,532 refs, of which 330 were tags. With
> > `$repo` naming the checkout, `$commit` an exactly tagged commit, and
> > `$parent` and `$this` the two binaries, I ran:
> > 
> >     hyperfine --warmup 3 --runs 15 \
> >         --command-name parent \
> >         '$parent -C $repo describe --exact-match $commit' \
> >         --command-name 'this commit' \
> >         '$this -C $repo describe --exact-match $commit'
> > 
> > The results were:
> > 
> >     Benchmark 1: parent
> >       Time (mean ± σ):     171.7 ms ±  18.5 ms    [User: 23.9 ms, System: 133.6 ms]
> >       Range (min … max):   142.3 ms … 198.3 ms    15 runs
> > 
> >     Benchmark 2: this commit
> >       Time (mean ± σ):       9.9 ms ±   1.1 ms    [User: 3.3 ms, System: 4.7 ms]
> >       Range (min … max):     8.8 ms …  13.1 ms    15 runs
> > 
> >     Summary
> >       this commit ran
> >        17.35 ± 2.63 times faster than parent
> > 
> > Both revisions were built with -O3, -mcpu=native, and ThinLTO using
> > Apple clang 21.0.0 on macOS 26.5. The machine was a MacBook Pro
> > (Mac16,6) with a 16-core Apple M4 Max (12 performance and four
> > efficiency cores) and 128 GB RAM.
> 
> This patch looks fine to me, but let me pick a nit for a minute, because
> I think there is a broader conversation to be had.
> 
> Given the discussion in earlier rounds and sibling topics, I assume the
> commit message here was AI-generated. And it's OK in the sense that it
> is describing what happened and I assume is entirely accurate. But as a
> human reader, it feels so much more verbose than what I'd expect, as it
> is full of semi-irrelevant details. Why set --warmup and --runs? Why
> bother with --command-name, which just means you have to show the
> commands separately anyway? Is the amount of RAM in the machine
> important for this test? Surely it could be if it was absurdly tiny, but
> in general, no, I would not expect it to be.

I agree. Earlier this week I also drafted a message that was going down
this angle, but I think I didn't end up sending it to the mailing list.
Or at least I'm not able to find it anymore.

To me the biggest problem is not the verbosity, even though it _is_
overly verbose. The bigger problem though is the incoherence of the
story that the commit message is trying to tell where it jumps around
randomly. It almost feels like rambling to me, and that makes it
extremely hard to follow the narrative and figure out what the message
even wants to tell the reader in the first place.

[snip]
> I dunno. I am not trying to pick apart your commit in particular, but am
> more interested in the broader use of AI commit messages going forward.
> This kind of verbosity is quite common in the output (from my limited
> experience), and I think creates more work for reviewers. Should we be
> expecting contributors to make things more concise before submitting
> (either manually or through prompting)? Or do people even agree that the
> shorter version is preferable? I could be the only one.

I very much think that we should and even have to expect that
contributors adapt, because if we don't we will basically reinforce
whatever AI is doing right now and increase the load on reviewers even
more.

I also think that we should reserve the right to reject a patch series
completely in case we notice that we're basically just talking to a
middleman that sits between an AI prompt and us (please note that I
don't refer to this patch series specifically, this is more of a general
statement). My assumption is that this will become more important as AI
gets established in more workflows. The number of patch series that look
sane on the surface but that are utter garbage will very likely increase
quite significantly going forward.

Patrick