I loved the simple increasing numbers of Subversion. This was better then CVS "ad-hoc" versioning and also far better then git's hashes. Single numbers are easy for humans. I would love git would make it possible to work that way (there is one way: `git describe` can show something like "v1.0.4-14-g2414721" which means "14 commits ahead of tag v1.0.4".)
replySome form of "increment authority" that simply appends to a list of hashes whenever it encounters a commit not yet on the list? Then you could use URI like $authorityhost/orderedcommits/$number as synonyms for the hashes. Multiple increment authorities would not necessarily have them in the exact same order (and "current latest" would likely differ by an order of magnitude or two after some time if you ever had multiple authorities), but it would still provide a lot of intuitive understanding.
replyI wonder how the tag mechanism would perform if you just burned it with this content. I suspect that it would not perform well...
Mercurial has serial numbers which work like this ("revision numbers"), but you can only see your local repo's serial number. There's no concept of a public revision number authority.
replyMy release code uses `git rev-list --count $tag` to output the release number.
replygit rev-list --count HEAD
replyYes but the .svn dirs everywhere keep being annoying
replySince Subversion 1.7 (2011), working copies only use a single .svn directory at the top level.
reply