Sean <seanlkml@xxxxxxxxxxxx> writes: > On Tue, 17 Oct 2006 17:27:44 -0400 > Aaron Bentley <aaron.bentley@xxxxxxxxxxx> wrote: > >> Bzr has plugin autoloading, Protocol plugins, Repository format plugins, >> and more. Because Python supports monkey-patching, a plugin can change >> absolutely anything. > > But really why does any of that matter? This is the open source world. > We don't need plugins to extend features, we just add the feature to > the source. The example I asked about earlier is a case in point. > Apparently in bzr "bisect" was implemented as a plugin, yet in Git it > was implemented as a command without any issue at all, The plugin Vs core feature is not a technical problem. The code for a plugin and for a core functionality will roughly be the same, but in a different file. There can be many reasons why you want to implement something as a plugin: * This is project-specific, upstream is not interested (for example, bzr has a plugin to submit a merge request to a robot, it will probably never come in the core). * The feature is not matured enough, so you don't want to merge it in upstream, but you want to make it available to people without patching (for example, "bzr uncommit" was once in the bzrtools plugin, and finally landed in upstream). * The feature you're adding are only of use to a small subset of users. You don't want to pollute, in particular "bzr help commands" with it, especially not to disturb beginners. I've been arguing in favor of a configuration option to hide commands from "bzr help commands" instead, but nobody seemed interested. * Explicit divergent points of view between the implementor of the plugin and upstream. That avoids a fork. I don't remember any such case with bzr. I'd compare bzr's plugins to Firefox extensions. Geeks used to like the big Mozilla-with-tons-of-config-options, but Firefox-with-only-the-most-relevant-features is the one which allowed a wide adoption by non-geeks. Still, geeks can customize their browser, and add features without having to wait for Mozilla Fundation to incorporate it in upstream. Now, I don't know git enough to know whether the way it is extensible allow all of the above, but bzr's plugin system it quite good at that. At the time git was almost exclusively used by the kernel, you didn't have all those problems since you targeted only one community, but I guess you already had some needs for flexibility. -- Matthieu - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html