Have you ever thought about why do you only have 1-5 commits a day? I do 70 to 100 commits a day. I commit each and every semantic change. I do not commit changes so that I have a backup of my code, I create a commit so that I can track my 'semantic code change'.
Let me give you an example:
Let's say I have a working website. The website has header/footer/content style. I spend one hour to customize my website layout by modifying html/css.
When I am done with header, I commit my HTML/css.
When I am done with footer, I commit my HTML/css.
When I am done with content, I commit my HTML/css.
During my work, I found a bug in CSS which fixes float in IE and I created another commit for this particular bug fix.
The most important point being that each of my commit is 'independent' and represent a meaningful unit of work.
You may ask, why create 4 commits instead of one? The reason is that git will let me use these commits anyway I chose.
It's 2.30pm and my manager stops at my desk and tells me that I have to fix the float but in IE 'RIGHT NOW' before the 3pm meeting. I am only needed to fix the float bug and nothing else because the website has to match with printed material for the meeting. How do you do it? Easy. git will let me 'cherry-pick' my last float bug commit and merge it in to current production branch. After merging the one particular commit, I test everything to make sure nothing is broken and I am all set before the 3pm meeting.
Obviously, this was a simple case. There will be cases where you can not just pick one commit as it depends on other commits. You will have to do more work to get the fix in. Git is the helping hand which can let you play with the commits to get the answer you want. SVN can not do that.
Going back to my point, I think you may not realize that you do far fewer commits than you should because your subconscious brain knows that commits are slow. Once your brain will realize that commit can take less than a second, you will automatically commit more often.
To give a unrelated example: Back in the day when we didn't have access to high speed Internet, we would consult local documentation only because searching online was slower than finding it locally. Now, with Google and high speed Internet, I have stopped downloading documentation locally and rely on Google to find it for me.
'caring about rename history'.
Again, this is dependent on the way you code. I like to re-factor my code a lot. I rename my classes whenever I find a better name. I move my code around in different folders as I find better way to organize my code. And as I re-factor a LOT, I DEFINITELY care about my code history. Git can track renames/folder movement and still show you the file history. You may not care about rename history now but you may care about it in future. With SVN, you have no choice. Git offers you that choice.
Now to your workflow comment. The beauty of git is that it is a 'content tracking' tool. You can use it to FIT any work flow you like. git does not force you to use any particular workflow. You can use it in the exact same way you currently use SVN. Or you can come up with your own workflow which no other team in the world uses. It's all fine.
Finally, the revision number comment. Generally, I haven't had a need to figure out which revision came first based on 'revision numbers' alone. But once again, git has an answer. You can use git describe command. It will give you something like:
"git describe gives you a version description like the following: v2.0-64-g835c907. The v2.0 part is the name of the latest annotated tag preceding the commit, 64 is the number of commits after that, and 835c907 is the abbreviated commit id. It is basically there to identify any revision in an exact and convenient (although technical) way."
And that's the beauty of git. Git already has a way to address your common concerns and if it doesn't, you have enough meta data to make it work the way you want to.
Once again, I really understand where you are coming from because I was on that side once. But I sincerely believe that git is a much better tool and it will change your life as a developer. It has definitely changed mine.
Please, please, do yourself a favor and at least experiment with git before dismissing it.
Have you ever thought about why do you only have 1-5 commits a day? I do 70 to 100 commits a day. I commit each and every semantic change. I do not commit changes so that I have a backup of my code, I create a commit so that I can track my 'semantic code change'.
Let me give you an example:
Let's say I have a working website. The website has header/footer/content style. I spend one hour to customize my website layout by modifying html/css.
When I am done with header, I commit my HTML/css.
When I am done with footer, I commit my HTML/css.
When I am done with content, I commit my HTML/css.
During my work, I found a bug in CSS which fixes float in IE and I created another commit for this particular bug fix.
The most important point being that each of my commit is 'independent' and represent a meaningful unit of work.
You may ask, why create 4 commits instead of one? The reason is that git will let me use these commits anyway I chose.
It's 2.30pm and my manager stops at my desk and tells me that I have to fix the float but in IE 'RIGHT NOW' before the 3pm meeting. I am only needed to fix the float bug and nothing else because the website has to match with printed material for the meeting. How do you do it? Easy. git will let me 'cherry-pick' my last float bug commit and merge it in to current production branch. After merging the one particular commit, I test everything to make sure nothing is broken and I am all set before the 3pm meeting.
Obviously, this was a simple case. There will be cases where you can not just pick one commit as it depends on other commits. You will have to do more work to get the fix in. Git is the helping hand which can let you play with the commits to get the answer you want. SVN can not do that.
Going back to my point, I think you may not realize that you do far fewer commits than you should because your subconscious brain knows that commits are slow. Once your brain will realize that commit can take less than a second, you will automatically commit more often.
To give a unrelated example: Back in the day when we didn't have access to high speed Internet, we would consult local documentation only because searching online was slower than finding it locally. Now, with Google and high speed Internet, I have stopped downloading documentation locally and rely on Google to find it for me.
'caring about rename history'.
Again, this is dependent on the way you code. I like to re-factor my code a lot. I rename my classes whenever I find a better name. I move my code around in different folders as I find better way to organize my code. And as I re-factor a LOT, I DEFINITELY care about my code history. Git can track renames/folder movement and still show you the file history. You may not care about rename history now but you may care about it in future. With SVN, you have no choice. Git offers you that choice.
Now to your workflow comment. The beauty of git is that it is a 'content tracking' tool. You can use it to FIT any work flow you like. git does not force you to use any particular workflow. You can use it in the exact same way you currently use SVN. Or you can come up with your own workflow which no other team in the world uses. It's all fine.
Finally, the revision number comment. Generally, I haven't had a need to figure out which revision came first based on 'revision numbers' alone. But once again, git has an answer. You can use git describe command. It will give you something like:
"git describe gives you a version description like the following: v2.0-64-g835c907. The v2.0 part is the name of the latest annotated tag preceding the commit, 64 is the number of commits after that, and 835c907 is the abbreviated commit id. It is basically there to identify any revision in an exact and convenient (although technical) way."
From: http://stackoverflow.com/a/1817099/92414
And that's the beauty of git. Git already has a way to address your common concerns and if it doesn't, you have enough meta data to make it work the way you want to.
Once again, I really understand where you are coming from because I was on that side once. But I sincerely believe that git is a much better tool and it will change your life as a developer. It has definitely changed mine.
Please, please, do yourself a favor and at least experiment with git before dismissing it.