And you are assuming that there never will be a need for parallel development?
Further more, having that kind of naming scheme might actually hold you back from doing parallel development - aka using git to its full potential. I regularly make use of branching even in my personal projects. For example starting the development of new experimental feature while still continuing fixing bugs in the master branch.
The larger the commit numbers grow the smaller will be difference between a number 1935 and git hash af23cc. Besides, git provides easy means for referring to the most recent commits using HEAD, HEAD^, HEAD^^ and so on. There's also --since option for going further back in time.
As a result your commits now have two revision numbers: the hash used and maintained by git and the number used and maintained by you. But there's no escaping from hashes. You're forced to use them anyway. So why supplement them with your own revision numbers? That's like having a digital library system and maintaining a perfo-cards archive at parallel.
You'll notice that I am using branches. Branches != parallel development. Multiple developers != parallel development. This is a learning exercise. I don't need all the rush and hurly-burly of doing multiple things at once.
I'm not talking about referring to commits on the commandline. You're right, I use hashes for that[1]. I'm talking about referring to commits in later commits: http://github.com/akkartik/wart/commit/0f087dbaee. It's immediately obvious that I'd broken the app for a dozen commits.
If the project were ever to get so popular that people started submitting bugs and it needed parallel development I'd.. stop using numbers. If I were to get to 293547, ditto. But I think 1935 will be perfectly useable.
[1] I like hashes. I also like separating concerns. My friends have seen me wearing a woolen cap, a raincoat hoodie and a baseball cap, all at once. What? It gets cold and rainy and sunny all at once in Texas, and hoodies suck at keeping the sun out. Every cap or number should do one thing well.
Further more, having that kind of naming scheme might actually hold you back from doing parallel development - aka using git to its full potential. I regularly make use of branching even in my personal projects. For example starting the development of new experimental feature while still continuing fixing bugs in the master branch.
The larger the commit numbers grow the smaller will be difference between a number 1935 and git hash af23cc. Besides, git provides easy means for referring to the most recent commits using HEAD, HEAD^, HEAD^^ and so on. There's also --since option for going further back in time.
As a result your commits now have two revision numbers: the hash used and maintained by git and the number used and maintained by you. But there's no escaping from hashes. You're forced to use them anyway. So why supplement them with your own revision numbers? That's like having a digital library system and maintaining a perfo-cards archive at parallel.