From: david@lang.hm Date: Thu, 28 Apr 2011 00:55:58 GMT Subject: Re: RFC: a plugin architecture for git extensions? Message-ID: In-Reply-To: On Thu, 28 Apr 2011, Jon Seymour wrote: > On Thu, Apr 28, 2011 at 10:10 AM, Junio C Hamano wrote: >> Jonathan Nieder writes: >> > > I agree. Apologies for confusing things by talking too much about a > git pm install command. > > I think there are 3 levels of functionality. FWIW, I am suggesting > git-core stops at #2. > > 0. unmanaged plugins > > git doesn't provide any explicit management of plugins, but will use > them if finds them. > > Without some kind of management, however, you will be forced to dump > the man pages and scripts > for the plugins in one place. > > This would be very distribution manager unfriendly since there could > be conflicts galore. every package manager I know of has no problem with multiple packages owning files in one directory. if the files are named the same thing you will have a conflict, but if the files are named the same thing, the commands are probably going to be named the same, and so you will have conflicts in any case. > I guess an unmanaged solution could use separate directories for each > plugin, but this would imply scanning all these paths each time you > invoke git. In my view, symbolic links from a dir already > GIT_EXEC_PATH to plugin directories would be a more efficient way to > do this. I think you are overanalyzing the problem > 1. managed plugins > > git provides minimal plugin management functionality. Each plugin has > its own directory, but an activate step is required to make the plugin > available to the GIT_EXEC_PATH and GIT_MAN_PATH. > > This has the advantage that conflicts between plugins would be more > readily avoided and is potentially more performant. As Pau suggests, > this option is much more package manager friendly I don't see how this will avoid conflicts. what files are you thinking that the different plugins will make that won't conflict any more than the commands themselves will? > It probably does require a git plugin command of some kind, however, > in order to perform the activation step. only if you think you need a 'installed but not active' mode of operation, and I don't understand why you would want that. David Lang > 2. managed packages > > A meta-package manager for plugins, that delegates plugin installation > concerns to a platform package manager. > > The thing is, you may absolutely hate #2, but if approach #1 is > adopted by git-core, someone can at least attempt this by, well, > writing a plugin for it. > > jon. > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >