From: Patrick Steinhardt Date: Mon, 19 Jan 2026 06:57:51 GMT Subject: Re: [PATCH v2 1/3] last-modified: rewrite error message when more than one revision given Message-ID: In-Reply-To: On Fri, Jan 16, 2026 at 09:16:03AM -0800, Junio C Hamano wrote: > Patrick Steinhardt 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