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

[Jeff King <peff@peff.net>]

On Tue, Jun 09, 2026 at 09:40:25AM -0400, D. Ben Knoble wrote:

> > 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.
> 
> [You probably know this] It is common in academic papers to report
> benchmarks with details about the hardware and how they were run to
> contextualize the results and help with reproducibility.

Yeah, I almost drew the same comparison in my original email. I agree
that having every last detail _could_ help with reproducing in the
future. And that's important when producing a high quality dataset or
academic paper. But the tradeoff seems worse in a commit message, where
it is easy to obscure the main point or overwhelm the reader in what is
otherwise a short-ish document.

> Of course, Git's commits do not form an academic paper… so I have no
> real opinion on what to see here. But I've seen a few other mails
> where having perf test outputs or similar was suggested (maybe that
> was to be reserved for the cover letter? idk).
> 
> _If_ we show all the hyperfine details, I think it's reasonable to use
> --command-name to make distinguishing the versions easy, unless it's
> obvious from the path/to/git in each benchmark (which I think I've
> seen from Peff's benchmark reports before?).

Yeah, I tend to copy the various versions to their own executables,
which gives them short names (so you see "./git.old vs ./git.new" or
something). That's not always completely obvious either, though.

The "short" example I showed may have been a little hyperbolic. I'm OK
with hyperfine output in general, and sometimes show it myself. It is
kind of verbose, but occasionally the distribution of values, or user vs
system vs clock times are important. I'm even OK with --command-name if
it makes things more readable.

I guess what I was really responding to is that I think it is helpful
when the incoming data is cut down to the minimal set of useful details.
That helps a reader immediately assess what is important to the point
being made. Humans tend to do this naturally because we are lazy and
do not want to bother typing or pasting the uninteresting details.
Program output (whether AI or just verbose software) has less of that
impulse.

> Someone with better lore skills can probably dig up a few exemplars of
> how to write about performance in a commit message?

Probably searching for emails from René. :)

-Peff