Best tool for the job, can't agree more with that. We have a team that insists on using git when:
- it is just a small team (less than 5 devs)
- there is no github, just a locally hosted gitorious instance (proprietary project)
- the lead dev who picks git is using Windows half the time
- there are less technical people who need commit rights (e.g. changing reports layout, changing CSS, etc)
I believe the "git already won" mentality (which is very apparent in the comments of both OP article and HN) get these people to pick git over mercurial. And once they become familiar with git, they won't let go, due to the sunk cost of learning gitology[1].
"Git encourages micro-management, and git’s users end up loving this micro-management (and blog about it, and write books, and have conferences, and so on ad-nauseum). This is characteristic of the perversion that git promotes, focussing on details instead of getting work done."
What does the author know about how much work any of those people get done? But I'm glad he wrote that; it made me feel much better about writing the rest off as a rant.
Regarding sunk costs, that's true of pretty much any sufficiently complex tool or technology. You could make the same case with Emacs vs. vi, or pretty much any programming language, API, or framework.
Gitology is definitely a sunk cost, because of all the concepts you have to learn which are not applicable anywhere else. Here's a good example of what happens when a programmer learns git as the first DVCS:
- it is just a small team (less than 5 devs)
- there is no github, just a locally hosted gitorious instance (proprietary project)
- the lead dev who picks git is using Windows half the time
- there are less technical people who need commit rights (e.g. changing reports layout, changing CSS, etc)
I believe the "git already won" mentality (which is very apparent in the comments of both OP article and HN) get these people to pick git over mercurial. And once they become familiar with git, they won't let go, due to the sunk cost of learning gitology[1].
[1] http://jordi.inversethought.com/blog/on-gitology/