Are Mercurial's bundled extensions considered part of it's core feature set and approach to version control?

Question

I'm currently trying to evaluate Mercurial, to get a feel for the philosophy the system tries to promote - but one thing that's got me confused is the presence of the bundled 'extensions' and how they fit into the mix.

In the core package, Mercurial ships with a bunch of functionality that is implemented as extensions but is disabled by default. (See: http://mercurial.selenic.com/wiki/UsingExtensions#Extensions_Bundled_with_Mercurial)

Here's the thing I'm confused about:

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

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

I don't need info on how activate extensions, that's pretty straight forward - it's the logic behind the separation that I'm curious about.

The reason I'm trying to get my head around this is because I don't really want to try and crowbar an opposing approach into Mercurial via extensions if it differs from the overall philosophy of the project.

Answer 1

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

hg help extensions

This contained some information that I don't think is available in the Mercurial help docs:

Extensions are not loaded by default for a variety of reasons: they can increase startup overhead; they may be meant for advanced usage only; they may provide potentially dangerous abilities (such as letting you destroy or modify history); they might not be ready for prime time; or they may alter some usual behaviors of stock Mercurial. It is thus up to the user to activate extensions as needed.

This helps answer part of my question.

Answer 2

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

Yes, although we won't generally advocate their use to new users, they are very useful for advanced usage. I guess everybody in the dev team has extension enabled (at least mq, patchbomb, and sometimes record).

Extension accepted in hgext/ are reviewed priori to inclusion, and we generally require them to provides tests. But they are often owned by outside contributors and aren't updated by the dev team except for API changes within core hg.

Why are they implemented outside of the default features and disabled by default?

We generally think that hg should stay simple and adding more commands might confuse users (e.g. if you have a simple workflow you don't need to learn about mq). But if a command is deemed useful for most users, it can migrate from an extension into core (that was the case for bisect, and it is the case of the subrepo functionality).