Get revision number from commit ID and vice versa in Git

Question

I know that this is possible because I've seen it done before. That Git uses hashes to identify revisions is irrelevant because a repository still has a record of the order that various revisions were committed in.

Given a Git repository's commit ID, how do you get the ordinal revision number that corresponds to it (NOT for a particular file)? Given a revision number (i.e., 1, 2, etc.) of the repository (NOT of a particular file), how do you obtain the commit ID?

Answer 1

I know that this is possible because I've seen it done before.

It Ain’t What You Don’t Know That Gets You Into Trouble. It’s What You Know for Sure That Just Ain’t So.

The best way to get close to something like what you want is to use git describe. See the git describe documentation for details.

Mercurial repositories do have simple ordinal numbers, as Mercurial's repository structure is a relatively simple append-only database. Each commit in a Mercurial repository also has a unique hash ID. You can use either with -r, so -r 123 gets you commit #123, which might have hash ID a123456 (abbreviated). This is quite convenient ... and a deadly trap. What happens is that Alice and Bob both clone some particular Mercurial repository, which has, say, 1326 commits in it. Their -r numbers now correspond exactly for all these commits because their clones started with the same 1326 commits, in the same sequence.

Now Alice adds, to her clone, a few new commits, perhaps on a new branch or bookmark. Bob adds a few new commits as well, to his clone. Both of them get the same -r numbers for their new commits.

Bob and Alice start chatting (perhaps by email, or on Slack, or super-old-school at the water cooler, or however this works wherever they work). They talk about something in -r 734, and they both look and see the same commit. They wonder if a bug was introduced in -r 922, and they both look at that, and see the same commit again. Aha, they think to themselves, we can ignore those big ugly hash IDs, these simple sequential revision numbers are so much easier, let's just use them!

Eventually, Alice and Bob send their commits to the company's main Mercurial repository. One of them—let's say Alice—pushes before the other ... so in the central repository, Alice's commits keep their numbers, but when Bob gets to it, Bob's commits get renumbered there. Bob pulls (before or after) and gets Alice's commits, using new and different numbers.

From now on, Bob's revision numbers are out of sync with everyone else's. Bob's -r 1328, in Bob's Mercurial repository, is Bob's commit. But to Alice and others, -r 1328 is Alice's commit. Bob's commits don't start until -r 1331.

In a later conversation, Alice and Bob are trying to talk about one or both of their new commits. They get totally mixed up, because Bob thinks Alice is talking about Bob's commits, and Alice thinks Bob is talking about Alice's commits. This all falls apart because these simple, linear -r numbers are not universal.

Git never made this particular mistake (though Git made plenty of others of course). Do not try to do this; it is a bad idea. If a particular commit is important enough to have a universal-ish name, give it a tag.