On Mon, May 09, 2011 at 05:49:27PM +1000, Jon Seymour wrote:
> 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).
But is the system extension dir always the right place to do so? If I'm
not root, then that probably won't be writable (or even if I am, I may
want to install the extension only for the root user).
If your proposal is for the user to decide on one of:
unzip -d "$(git --system-extension-dir)" git-foo.zip
or
unzip -d "$HOME/.gitplugins" git-foo.zip
then they can make that decision. But if you're proposing that the
extension-writer distribute a script, then it's more complicated. They
would probably need to provide a "--user" versus "--system" option.
It would also be tempting to write something like:
install_dir() {
if test "`id -u`" = "0"; then
git --system-extension-dir
else
echo $HOME/.gitplugins
fi
}
but that is:
1. Not portable.
2. Does not allow for user-only installation by root.
But all of this is a packaging best-practices issue, not an issue of
what git needs to do to support it (you _could_ address the portability
issue by having "git --preferred-extension-path" that did the
appropriate platform-specific UID check, but that still doesn't address
the second point).
-Peff
--
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