In my case the effort was minimal. I certainly wouldn't measure the effort in "man-months". Here's how it went for me:
0. Research. This is one small part of why I read HN, and other assorted "news" sites. I like to stay current with the tools I use. I don't jump at every new tool just because it's new, but I understand that my current set of tools is not perfect. Sooner or later, I'm going to replace every tool in my toolbox with an even better tool. I may like my current set of tools today, but I understand that it's important not to get so attached to them that I stagnate as a developer. I think it's critically important for good developers to stay "intellectually curious".
1. I decided that git was worth trying. So, I started using it with my next new project. This allowed me to establish a new work flow without interrupting active projects. Yes, you'll need to read man pages, cheat sheets, etc. There's no point to adopting a new tool if it behaves exactly like the old one. So, it shouldn't be a surprise when you actually have to commit to learning the new tool. That said, I found git to be more user friendly than I'd expected based on the negative comments I'd read online.
2. I decided I liked the new work flow and that git was worth switching to. I moved my old projects over to git in less than a day and used git for all my work moving forward.
I'm sure this transition is different for everyone. I'm also sure that git is not yet (and may never be) a good fit for some people. But, I really don't see the point in disparaging those who think the switch is worthwhile for them.
I don't think I'm "disparaging" people who make the switch. If you want to use git (or mercurial or darcs or whatever), that's your choice; there are situations where it makes sense. But in most cases, I question the technical judgment. I use Git myself right now, and don't find that its benefits outweigh its costs for non-distributed projects.
I think that Linus Torvalds scratched a very personal itch with git, but that it needs a lot of time and polish to be a valid, general-purpose competitor to subversion. Couple that with the fact that I've seen very few rational discussions of the benefits of the environment, and lots of references to the hype, and I've become quite skeptical.
The major benefits to me is that git is fast, branching is cheap (and yes, cheap branching does change how you approach a project; I never did figure out branching under cvs and apparently, it's just as easy under svn as it is under cvs) and the merging is incredible (I'm using it to maintain two versions of a PHP project, one for MySQL and one for PostgreSQL: http://boston.conman.org/2008/08/07.1 )
Granted, if you are used to a centralized workflow, then I can see where git might be different enough to cause some strain. But even on a one-person project (and I have plenty of those), I found git much easier to use than cvs (or svn for that matter) even though it took some time to get used to the decentralized nature of git.
I was still in a "centralized frame of mind" when I started using git. I do development on one machine, but deployments go to the server, and for the occasional oversight, bug fixes that happen on the server need to be pushed back to the development machine. git didn't work quite the same as cvs in that reguard, and thus, I had to change my workflow just a bit.