https://bugzilla.novell.com/show_bug.cgi?id=466300
User tiwai@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=466300#c3
--- Comment #3 from Takashi Iwai
Plugins often change the substantially default behavior of the subcommands (meaning of switches, format of output), therefore can surprise users and can break other tools using mercurial. Due to the changed behavior, some of them (e.g. the 'purge' plugin) are even dangerous if the user is not aware of that they are turned on or (s)he is not familiar with them.
OTOH, I've got already bug reports several times that some extensions were disabled as default. Thus, from the usability POV, "disabling all" is no good choice at all. I'd be annoyed if I would have to change my hgrc at each time I install on new systems just for basic extensions like mq. Moreover, the change of command behavior can be seen even often for the hg core commands. I don't think there is much difference between the core and the extension commands in this regard.
Loading several unneeded plugins will also increase the start up time.
This is a good point.
Moreover, as far as I understand, mercurials provides less strict backward compatibility and stability for the plugins than for the core.
Well, this seems a bit strange argument. All the stuff comes from the mercurial tarball itself, and most of them is even installed as default. If it's really unstable and not recommended to use, they should stop shipping and installing craps in a single tarball. So, an ideal solution is to separate "core" and "others". This should be done in both the tarball level and in the packaging level. Frankly, I'm not sure (rather skeptical) that "disabling *all* extesions" is good overall. A practical solution would be "disabling some rare/uncommon extensions"... Thanks. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.