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.
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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