Actually if you follow the thread(s) relating to this, a less invasive change to speed up "git tag --contains" was adopted (see git.git@ffc4b8012), so "soon" probably isn't the right word.

So imagine your history looks like this:

     __C__
    /     \
   A---B---D

A is commit number one. D is commit number three. If B is two, then what is C? Assuming you can come up with a consistent view when all the information about the branch topology is available, what about when people have disconnected branches? How do you avoid duplicate generation numbers? If you can't avoid duplicate generation numbers, what's the point of having them? "Fixed in commit 2." Great, which commit 2 did you mean?

You have duplicates, B and C would have the same generation number. It just represents length of the longest path from the root commit. This is already calculated internally to optimize several operations, so they were considering making it part of the commit data.

It often won't uniquely identify commits, but revision numbers in SVN are also sometimes used imprecisely ("oh, it was around R1500"), so I think it would have value.

Yeah, but you know people want this so they can write things in their bug tracker like "fixed in r1232" instead of "fixed in 2c4d96d1dc2d12afd486561329a9a7b74d4ae110".

This will give you r/1232:

https://github.com/stephenh/git-central/blob/master/server/p...

(It makes a tag-per-commit; I'm not saying that's necessarily a good idea, but if you really want revision numbers...)

I wouldn't mind "fixed in 981db17b8 (gen 1853)".

That's what `git describe` is for.