On Thu, Apr 28, 2011 at 10:50 AM, Jon Seymour <jon.seymour@xxxxxxxxx> wrote:
> On Thu, Apr 28, 2011 at 10:10 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>> Jonathan Nieder <jrnieder@xxxxxxxxx> writes:
>>
>>> Right, my worry was based on the usual way programs find their way
>>> onto my $PATH. ÂThat is:
>>>
>>> Â- if they are installed via a package from the distro, they are in
>>> Â Â/usr/bin.
>>>
>>> Â- if they are installed with "make install" by the local sysadmin for
>>> Â Âall users, they are in /usr/local/bin.
>>>
>>> Â- if I am trying them out for myself, they are in $HOME/opt/foo/bin
>>> Â Âand when it is time to remove it, "rm -fr $HOME/opt/foo".
>>>
>>> Â- if I have adopted them, symlinks go in $HOME/bin.
>>>
>>> With a local gcc-4.6 in $HOME/bin, if the sysadmin upgrades gcc so
>>> gcc-4.6 is to appear in /usr/bin or /usr/local/bin, my setup still
>>> works without trouble. ÂSo, barring bugs, each installation method
>>> does not interfere with the other ones.
>>>
>>> Call it overengineering, but I would want a way for installing new git
>>> commands to have the same attributes (installable by normal users in
>>> multiuser systems and name conflicts not being a terrible
>>> administrative burden).
>>
>> Ok, I wasn't thinking about folks who use repackaged /usr/bin/git together
>> with their own choice of third-party enhancements.
>>
>> Probably we would be better off if we define a new set of paths that is
>> independent from GIT_EXEC_PATH and friends. ÂThe installed git and nothing
>> else will occupy GIT_EXEC_PATH etc., but at the runtime, git would look at
>> a user-writable location GIT_PLUGIN_PATH/{bin,man,...} to see if the user
>> has her own customization, and add them to its vocabulary.
>>
>> Or something like that. ÂI am not all that interested, but it feels like a
>> good direction.
>>
>
> 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.
>
> 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.
>
> 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
>
> It probably does require a git plugin command of some kind, however,
> in order to perform the activation step.
>
> 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.
>
Sorry, sorry/. git-core stops at #1!!
> 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