Are the included Mercurial add-ons part of its core set of features and approach to version control?

Question

I'm currently trying to evaluate Mercurial to understand the philosophy that the system is trying to promote, but one thing that confused me was the presence of related extensions and how they fit into the mix.

In the base package, Mercurial comes with a set of functions that are implemented as extensions, but are disabled by default. (See: https://www.mercurial-scm.org/wiki/UsingExtensions#Extensions_Bundled_with_Mercurial )

Here's what bothers me:

• Are these extensions considered First Class citizens by the Mercurial dev team, and therefore part of Mercurial’s overall approach to DVCS?

• Why are they implemented outside the default functions and disabled by default?

I don't need information on how to activate extensions that are pretty straightforward - this is the separation logic I'm interested in.

The reason I'm trying to understand this problem is because I really don't want to try to break the opposite approach in Mercurial through extensions, if it differs from the general philosophy of the project.

Answer 1

Are these extensions considered first-class citizens by the Mercurial dev team, and therefore part of Mercurial’s overall approach to DVCS?

Yes, although we will not recommend their use for new users at all, they are very useful for extended use. I think everyone in the development team has an extension (at least mq, patchbomb, and sometimes a record).

The extension adopted by hgext/ is considered a priori for inclusion, and we usually require them to run tests. But they are often owned by third-party contributors and are not updated by the development team, except for API changes inside the main hg.

Why are they implemented outside the default functions and disabled by default?

We usually think that hg should stay simple, and adding more commands can confuse users (for example, if you have a simple workflow, you don't need to learn about mq). But if the command is considered useful to most users, it can migrate from the extension to the kernel (this was the case for bisect, and this applies to subrepo functions).

Answer 2

Almost immediately after posting, I found out about the following hg command:

 hg help extensions 

This contained some information that, it seems to me, is not available in the Mercurial help docs:

Extensions are not loaded by default for various reasons: they can increase startup overhead; they may be intended for extended use only; they can provide potentially dangerous abilities (for example, allow you to destroy or change history); they may not be ready for prime time; or they can change some normal Mercurial stock behavior. In this way, the user can activate extensions as necessary.

This helps answer part of my question.