> Technically I think Mercurial would be better for engineering wise in the long term. I don't see why. I've seen companies switch from Mercurial to Git even

> Technically I think Mercurial would be better for engineering wise in the long term. I don't see why. I've seen companies switch from Mercurial to Git even though many employees loved Mercurial -- the driver was the fact the new employees were much more likely to prefer Git or not even know what Mercurial is. Mindshare matters. > Mercurial has a single implementation (Git has 5), Eh? I very much like that there are multiple Git implementations. Besides choice, this means there are more people who really understand its guts and can support it and its implementations. > and they greatly discourage anyone from implementing a second. That's not a good thing. > This gives them a single source of truth for the implementation. That gives them too much power to make changes the users might not like. > Mercurial has better hooks in place. Sounds like one of the ways in which Git implementations might differentiate from each other. > It had better windows support than Git did for a long time. I believe it is still better because you don't rely on MinGW or some other Linux abstraction layer (though it uses python). MSFT is doing amazing work on Git on Windows, making it scale in ways no other distributed VCS is likely to any time soon without adopting similar ideas. If you want Windows support, then Git is going to rock your boat more than Mercurial soon if not already.