On Thursday, April 28, 2011, Pau Garcia i Quiles <pgquiles@xxxxxxxxxxx> wrote: > On Thu, Apr 28, 2011 at 10:09 AM, Jon Seymour <jon.seymour@xxxxxxxxx> wrote: > >> Ok, I have tried to explain why separating the concerns of package >> management and plugin management is an appropriate thing to do, and >> why one directory for each plugin is also a good thing to do. BTW: I >> thought you actually suggested this concept yourself in your earlier >> post. > > Please, re-read my mails. I *am* suggesting that plugins store data in > different directories! Good. Sorry I explained why an activation step is good for performance, particularly if you have a plugin architecture that uses multiple directories, one per plugin. I misinterpreted your confusion about why an activate step was necessary as an explicit rejection of my arguments that an activation step was a plus for performance and conflict detection in an environment in which each plugin is installed in it's own directory. Apologies. Supposed you have 100 plugins. Suppose the user invoked git foobar where foobar is an installed plugin. How does git find the plugin to invoke? Why it has to scan 100 directories looking for a match. If you use an activation step (just after installation) you get O(1) performance instead of O(n). Small gain for 2 plugins, I agree. But then that isn't the only reason to use an activation step. As I said, an activation step alllows precise detection and prevention of conflicts that just isn't possible if you rely on first-in-PATH semantics. It is true, you can delegate conflict detection to the package manager, but do you know what, that would be in Andreas"s words "Brilliant" as it would force package maintainers become git extension experts. My proposal makes the git-core maintainerrthathe experts on git extension management and relieves plugin authors, package authors and package-manager authors of this responsibility. I ask. is that not a very good thing? > > - The "main command" (git-atomic, for instance) would be stored in > GIT_PREFIX/lib/git-plugins (instead of GIT_PREFIX/lib/git-core, which > is where git stores its commands). Git would have to learn to search > in GIT_PREFIX/lib/git-plugins in addition to git-core, of course. > > - Porcelain for git-atomic would go to > GIT_PREFIX/lib/git-plugins/git-atomic (or something like this) > > - The documentation would be stored in GIT_PREFIX/doc/git-atomic > > - Resources in GIT_PREFIX/share/git-atomic > > - etc > > I. e. each plugin stores its stuff in a separate directory, it's just > that directory is not a *single* directory but *many* directories, > each one inside the proper path under GIT_PREFIX, just like it is for > anything you install on a Unix system > > -- > Pau Garcia i Quiles > http://www.elpauer.org > (Due to my workload, I may need 10 days to answer) > -- 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