我目前正在尝试评估Mercurial，以了解系统试图推广的理念 - 但令我困惑的一件事是捆绑的“扩展”的存在以及它们如何适应混合。
在核心软件包中，Mercurial附带了许多实现为扩展但仍默认禁用的功能。 （见：https://www.mercurial-scm.org/wiki/UsingExtensions#Extensions_Bundled_with_Mercurial）
这是我很困惑的事情：
这些扩展是否被Mercurial开发团队视为一等公民，因此是整体Mercurial方法的一部分？
为什么它们是在默认功能之外实现的，默认情况下是禁用的？
我不需要有关如何激活扩展的信息，这是非常直接的 - 这是我很好奇的分离背后的逻辑。
我试图理解这个问题的原因是因为如果它与项目的整体理念不同，我真的不想尝试通过扩展来反对Mercurial的反对方法。
答案 0 :(得分：9)
这些扩展是否被Mercurial开发团队视为一等公民，因此是整体Mercurial方法的一部分？
是的，尽管我们通常不会主张将它们用于新用户，但它们对于高级用户非常有用。我想开发团队中的每个人都启用了扩展（至少是mq，patchbomb，有时还有记录）。
hgext/中接受的扩展程序会在包含之前进行审核，我们通常会要求它们提供测试。但它们通常由外部贡献者拥有，并且除了核心hg中的API更改之外，开发团队不会更新它们。
为什么它们在默认功能之外实现并默认禁用？
我们通常认为hg应该保持简单，添加更多命令可能会使用户感到困惑（例如，如果您有一个简单的工作流程，则无需了解mq）。但是，如果一个命令被认为对大多数用户有用，它可以从扩展转移到核心（对于bisect，情况就是subrepo功能）。
答案 1 :(得分：5)
发布后，我几乎立即了解了以下hg命令：
hg help extensions
这包含一些我认为在Mercurial帮助文档中没有的信息：
默认情况下，由于各种原因未加载扩展名：它们会增加启动开销;它们可能仅用于高级用途;它们可能提供潜在的危险能力（例如让你摧毁或修改历史）;他们可能还没准备好迎接黄金时段;或者他们可能会改变Mercurial股票的一些常规行为。因此，用户可以根据需要激活扩展。
这有助于回答我的部分问题。