On Mon, May 09, 2011 at 06:45:56PM +1000, Jon Seymour wrote:
> I am starting to think that deploy-via-zip/tar is unworkable for the
> case where the extension wants to supply html, since I think an
> attempt has to be made to deploy HTML in the path reported by git
> --html-path for reasons of HTML linkability from extension back to
> the pages from git-core.
Yeah, I don't see a way around that without post-processing the HTML
links at install time (or creating a symlink farm with all of the HTML
pages).
> So, suppose we call it --preferred-extension-path*, then if the user
> (root or otherwise) defines
>
> git config core.preferrred-extension-path ${HOME}/.gitplugins
>
> then they get to choose where the installer next run will install extensions.
I thought about suggesting that, but a config option didn't seem a good
fit to me. The decision of where to put a package seems more likely to
be related to which _package_ it is, than which user you are. So a
command-line option would make more sense. And even if you have a config
option, you would sitll need a command-line one to override, so it's not
like you are reducing the amount of code or complexity.
Which again makes it not a git issue at all, but an issue for
package-writers who want to provide a script. It's their job to interact
with the user and find out where the user wants to put things (i.e.,
personal or system directories).
I don't really see any need for git's role in this to be more than:
1. Check a set list of directories for extra paths to add to PATH and
MANPATH.
2. Tell the packager's script what that set list is, so they can be
sure to put their files in the right spot.
-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