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

[Patrick Steinhardt <ps@pks.im>]

On Fri, Jan 16, 2026 at 09:16:03AM -0800, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> 
> >> Surprised that “revision” is a synonym for commit? Why is that?
> >
> > Because in my mind a revision can resolve to any object type.
> 
> Yup, in the early days of this mailing list (like in 2005 ;-), the
> word "revision" was used more or less interchangeably with "object
> name", but "a revision" was much more likely to refer to a commit
> than "an object name". 

It's probably still much more likely that a revision refers to a commit
rather than anything else.

> The name of the file that implements one of the more core-ish part of
> the system is "revision.c" and talks about "revision traversal", which
> is mostly about following parent pointers in commit DAG, but also
> follows into trees starting from commits.

This discussion makes me wonder whether we should maybe update how we
define a "revision" in our glossary. One could take gitrevisions(1) as a
starting point:

    A revision typically, but not necessarily, names a commit object. It
    uses what is called an extended SHA-1 syntax.

We should probably get rid of "SHA-1" though. So maybe:

    A revision is used to refer to a specific object, typically a
    commit, using extended object name syntax. Refer to
    gitlink:gitrevisions[7] for more information.

> > 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.
> 
> I do not know about this.  If HEAD~10 does not resolve to anything,
> it would not be a commit and it would not be a revision, either.

I guess things are getting philosophical here :) I rather see it like a
pointer: a pointer is still a pointer even if it doesn't point to
anything.

Patrick