Re: [PATCH v2 1/3] last-modified: rewrite error message when more than one revision given

["Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com>]

On Fri, Jan 16, 2026, at 08:09, Patrick Steinhardt wrote:
> On Thu, Jan 15, 2026 at 03:34:50PM +0100, Kristoffer Haugsbakk wrote:
>> On Thu, Jan 15, 2026, at 12:54, Patrick Steinhardt wrote:
>> > On Thu, Jan 15, 2026 at 12:33:36PM +0100, Toon Claes wrote:
>> >>[snip]
>> >> I was thinking about mentioning something like "commit-ish" instead, but
>> >> I felt "commit-ish" isn't a commonly used term toward end-users. Looking
>> >> at gitglossary(7), it says "revision" is a "synonym for commit". I'm
>> >> happy to change this message, but I'm not sure s/revision/commit-ish/ is
>> >> the best change for this.
>> >
>> > gitglossary(7) also defines commit-ish, but I guess you're right that
>> > revision is the more common term. I'm a bit surprised that it's defined
>> > to be a synonym for a commit, but oh, well.
>>
>> Surprised that “revision” is a synonym for commit? Why is that?
>
> Because in my mind a revision can resolve to any object type.
> "<rev>^{<type>}" for example is a revision, but it can resolve for
> example to a tree if you say "HEAD^{tree}". Still a revision, but
> definitely does not resolve to a commit.
>
> Also, it's confusing to conflate the way to name a commit with a commit
> itself. "HEAD~10" is a revision, but taken by itself it's not a commit.
> It's not even clear whether it resolves, so it feels sensible to me to
> keep these two concepts separate from one another.

Maybe I didn’t read the context well enough. I always read “revision” as
a generic word like “commit”. Not as the gitrevisions(7) expressions.