On Thu, Apr 28, 2011 at 10:55 AM, <david@xxxxxxx> wrote: > On Thu, 28 Apr 2011, Jon Seymour wrote: > >> On Thu, Apr 28, 2011 at 10:10 AM, Junio C Hamano <gitster@xxxxxxxxx> >> wrote: >>> >>> Jonathan Nieder <jrnieder@xxxxxxxxx> 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. > Suppose a plugin contains a file called LICENSE or README.txt. Which LICENSE or README.txt wins? >> 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 I don't think so. Perhaps Pau can give us his view on the desirability of a single directory for all plugins artifacts from a distribution maintainers perspective. >> 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? No, but you can manage the conflicts. Hence _managed_ plugins. git plugin activate can fail with a non-zero exit code if there will be a conflict. > >> 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. > For the reasons of managed conflict management. I don't want to drop a new plugin into a common directory only to find it has blitzed some other plugin I previously did the same with. Still, I guess it is horses for courses. jon. -- 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