对于新项目而言 Mercurial 是否已不再值得考虑？
也就是说，之前用hg的原因之一是hg使用python写的，git不是。而显然这太狭隘。
而关于hg和git的对比，也有专门描述：
另外，最后他们决定了不用gitlab，而用github。[core-workflow] We will be moving to GitHub
至少，在不远的将来，我可以把我对python的修改：unicode编译、android支持、uwp支持，都推回去了。因为独裁者Guido 更喜欢 GitHub。
Benevolent Dictator For Life从 maillist 里的声明可以看出，对于已经习惯使用 hg 的用户来说，他们的建议是：在 hg 客户端上安装使用 hg-git 插件来操作 git 库，这样就使得客户端的体验与之前的 hg 完全一致。
但我并不长期看好这种做法，这样使用中间件进行转换操作显然是折衷的过渡策略，是一种暂时的妥协。git 协议还是在不断更新中，hg-git 这个插件以后会怎样也很难说。
即使 mercurial 仍然继续积极维护，失去了本语言平台最大项目的支撑，它也没有出头之日了。
不管怎样，为 mercurial 这一相比 git 来说更加简单易用的轻量级分布式版本控制系统感到惋惜。
回复内容：
看着个：PEP 0507 -- Migrate CPython to Git and GitLab也就是说，之前用hg的原因之一是hg使用python写的，git不是。而显然这太狭隘。
而关于hg和git的对比，也有专门描述：
另外，最后他们决定了不用gitlab，而用github。[core-workflow] We will be moving to GitHub
至少，在不远的将来，我可以把我对python的修改：unicode编译、android支持、uwp支持，都推回去了。因为独裁者Guido 更喜欢 GitHub。
Benevolent Dictator For Life从 maillist 里的声明可以看出，对于已经习惯使用 hg 的用户来说，他们的建议是：在 hg 客户端上安装使用 hg-git 插件来操作 git 库，这样就使得客户端的体验与之前的 hg 完全一致。
但我并不长期看好这种做法，这样使用中间件进行转换操作显然是折衷的过渡策略，是一种暂时的妥协。git 协议还是在不断更新中，hg-git 这个插件以后会怎样也很难说。
即使 mercurial 仍然继续积极维护，失去了本语言平台最大项目的支撑，它也没有出头之日了。
不管怎样，为 mercurial 这一相比 git 来说更加简单易用的轻量级分布式版本控制系统感到惋惜。