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