我目前正在尝试评估 Mercurial，以了解该系统试图推广的理念 - 但让我感到困惑的一件事是捆绑“扩展”的存在以及它们如何融入其中。
在核心包中，Mercurial 附带了一系列作为扩展实现的功能，但默认情况下处于禁用状态。 (参见:https://www.mercurial-scm.org/wiki/UsingExtensions#Extensions_Bundled_with_Mercurial)
这是我感到困惑的事情:
这些扩展是否被 Mercurial 开发团队视为一等公民，因此是 Mercurial DVCS 总体方法的一部分？
为什么它们在默认功能之外实现并默认禁用？
我不需要有关如何激活扩展的信息，这非常简单 - 这是我好奇的分离背后的逻辑。
我之所以试图解决这个问题，是因为我真的不想尝试通过扩展将相反的方法强行引入 Mercurial，如果它与项目的整体理念不同的话。
最佳答案
Are these extensions considered first class citizens by the Mercurial dev team and therefore part of the overall Mercurial approach to DVCS?
是的，虽然我们通常不会向新用户推荐它们的使用，但它们对于高级使用非常有用。我想开发团队中的每个人都启用了扩展(至少是 mq、patchbomb，有时还有 record)。
hgext/ 中接受的扩展在包含之前经过审核，我们通常要求它们提供测试。但它们通常由外部贡献者拥有，并且除了核心 hg 内的 API 更改之外，开发团队不会对其进行更新。
Why are they implemented outside of the default features and disabled by default?
我们通常认为 hg 应该保持简单，添加更多命令可能会让用户感到困惑(例如，如果您有一个简单的工作流程，则不需要了解 mq)。但是，如果一个命令被认为对大多数用户有用，它可以从扩展迁移到核心(bisect 就是这种情况，子存储库功能就是这种情况)。
关于mercurial - Mercurials 捆绑扩展是否被视为其核心功能集和版本控制方法的一部分？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1740896/