On Mon, May 9, 2011 at 5:35 PM, Jeff King <peff@xxxxxxxx> wrote:
> On Sun, May 08, 2011 at 02:44:54PM +1000, Jon Seymour wrote:
>
>> > Â4. Users can set GIT_PLUGIN_PATH in the environment if they want to do
>> > Â Â something fancy (they can also always just set PATH and MANPATH
>> > Â Â manually if they want, too).
>>
>> If the need for multiple plugin directories were accepted, then I
>> wonder if there might not be some advantages for the configuration of
>> this path being in git configuration rather than an environment
>> variable?
>
> I think in general most users would not need to set this (since after
> all, the point of your proposal is to avoid such tweaks), so it may not
> be worth troubling about. But it is much simpler to tell users to run:
>
> Âgit config core.pluginpath /path/to/wherever
>
> than trying to figure out whether they need to use bashrc, cshrc,
> whatever Windows uses, etc.
Yep, that was part of the motivation for the suggestion - something
that works consistently, assuming only a working git installation.
Per one of my other notes, my initial inclination is to provide a
patch that implements support for
git --system-extensions-dir
which would:
- provide the caller with location that extensions could be
installed in (assuming the caller can acquire write privileges)
- provide a guarantee that $(git --system-extensions-dir)/bin will
be on the path set up by the git wrapper and $(git
--system-extensions-dir)/man will be in the MANPATH searched by git
help
Extensions could then use this information, together with git
--html-path to install themselves into these places using whatever
mechanism seems appropriate (either a POSIX shell script or a
make/install script).
The default value of git --system-extensions-dir could be supplied
during the build and might naturally default to the build prefix, but
distributions and other builders could specify an alternative.
An enhancement to this would then allow core.system-extensions-dir to
override the compiled in version.
Anything wrong with this so far?
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