I think of git more as a toolkit for a building bunch of possible revision control systems, each with different workflows rather than a revision control system

I think of git more as a toolkit for a building bunch of possible revision control systems, each with different workflows rather than a revision control system itself. There's commonalities between them all, but in fact it seems like most new shops I go to work at have very different ideas about what "git" means and the right way to hold the tool. Add in different code review tools and practices and it gets a bit crazy. Mercurial and Bazaar (and in fact Bitkeeper itself when I looked at it back in the day) tend I think to have far more assumptions baked into the CLI about how you'll use them -- or at least they started that way. I think for most teams this is in fact superior, but that's not how the industry went. Because github caught on in the early days, git itself became synonymous with DVCS and modernized revision control right at the time people were finally figuring out that, yeah, not only does CVS suck but Subversion isn't really an improvement. Back then I remember it being often very hard to convince people to try anything new at all, just even to get off CVS. A lot of suspicion, with SVN accepted as a kind of tolerable compromise because it acted mostly like CVS but better. And then the industry kind of just jumped all at once to git, and that was that.