Brandon Savage wrote a controversial blog post about why subversion is still more relevant than git.  His main point was that enterprise requires canonical version numbering to track progress in the application and that git cannot do this.   There was a lot of debate about this on Brandson's, but a recent comment by Morgan proved Brandon wrong.

I have never had a problem with the lack of canonical version numbers, but I can see why companies who have used CVS or subversion for a long time would be wary of getting rid of them.  Morgan explains how to use the git describe command to generate canonical version numbers.  I have used git for a while for personal projects and at HauteLook, but have never used this command.  I thought this was a great solution to a problem a lot of companies face when trying to migrate from subversion to git.

Morgan's comment:

git describe –tags –long

This gives you a string like (in the case of one of my projects)

2.1pre5-4-g675eae1

which is formatted as

{last reachable tag name}-{# of commits since that tag}-#{SHA of HEAD}

This gives you a ‘canonical version number’ (spelling corrected) that is monotonically increasing by commits, and unique across multiple repositories of development. If we’re all on the same HEAD, it will return the same value. If we all share the same most-recent-tag, but have different commits, the SHA will be different.