When arguing the merits of git versus Mercurial and bzr, some people
have mentioned that both of these systems have plugins to accomplish
things that git can do without need of plugins. This leaves a bad
taste in my mouth for several reasons.
- Users of my software must install these plugins to get the same
experience that I have when developing my projects. This is one
more rather complicated step that I must document in new developer
HOWTOs.
- Having this feature as a plugin means that it is a second-class
citizen.
- Such plugins can often lag behind the rest of the system. For
example, the bzr plugins, included in the
bzrtools debian package,
were usually updated a few days to a few weeks later than the bzr
package itself, which meant that I could not upgrade bzr until
both packages were updated, lest I lose functionality.
- It as if the developers of the VCS are saying, "We don't care so
much about this feature, but if someone else will do the work of
developing it for us, then we will include it so as to not appear
inferior to users of other systems."
- Since I consider some of these features absolutely essential, it
is clear that the developers of the VCS and myself are at odds
ideologically. If the developers and I do not share the same
technical vision, it makes me less willing to use their tools.
Blog - /Tech
![[FSF Associate Member]](http://mwolson.org/static/logos/fsf-member.png)
Posted by Brian Wahoff at Mon Mar 24 10:28:21 2008
While I agree with your point that features implemented as plugins are second class citizens, having a plugin system is a wonderful way for an application developer to find out what features users think their application is missing.What is missing is for application developers to roll popular plugins into the core application as new features.
If I can find a solution that already supports the core functionality, I will use it. But in the absence of a perfect solution or a situation where the perfect solution is not known, I'll choose an architecture that allows plugins for its flexibility.
Posted by Codemac at Mon Mar 24 11:17:02 2008
If the plugins ARE distributed with the vcs (like most are with mercurial) then your first point becomes invalid.2-5: You are making assumptions about the developers, and how they consider their plugins. I guaran-fucking-tee that the mercurial developers find MQ an essential part of mercurial. You are ignoring the high possibility that maybe they just wanted to organize their application to have a nice plugin structure for features, but still consider them an important part of the application.
Posted by Matt Mackall at Mon Mar 24 12:57:30 2008
Many of the things that are plugins in Mercurial -are- second-class citizens. MQ is a perfect example of this. By rewriting history, MQ breaks all the data integrity rules in Mercurial. Forcing users to manually enable MQ lets them know they're wandering out of the sandbox.There is no functionality in Mercurial plugins that the average user needs. And that includes MQ.
Posted by Michael Olson at Mon Mar 24 17:26:21 2008
Codemac,Even if the plugins were distributed with the VCS, my first point would still be valid. I would have to tell the users of my software to edit some configuration file somewhere and add a line or two to enable the plugin. This is yet another step that can turn off new contributors, and another step that can be forgotten by them, potentially leading to strange bug reports.
I really don't care whether features are implemented as plugins or not, because I don't want to hack on the code of the VCS itself. What I want is for these features to be activated by default, so that I can just use the commands that they provide without having to edit some wonky configuration file. Particularly one that has lines ending in a single "=" sign. Eww.
Posted by Michael Olson at Mon Mar 24 17:34:02 2008
Matt,Hi, thanks for the feedback.
I would argue that the transplant extension/plugin is absolutely essential for normal users, and should be enabled by default. That was the one I particularly had in mind WRT Mercurial. I frequently need to cherry-pick individual commits from branches, particularly when extracting changes made to ERC in Emacs 23 and applying them to upstream ERC (which has some features, such as XEmacs support, that need not be part of Emacs 23). In general, any project with more than one "vendor" will be likely to consider cherry-picking essential.
Add a comment