On Mon, May 9, 2011 at 8:44 PM, Jeff King <peff@xxxxxxxx> wrote:
> 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.
>
The problem with presenting a list of possible directories is that
given a list, the choice is ambiguous. Sure a decision procedure can
be arrived at to choose, but it might be hard for the user to predict
what decision the procedure will reach. In that case, the user must be
prompted for a selection.
Ideally most extension installs would not require any kind of
configuration or decision by the user - simply a statement, I want
this installed and I want it to be available immediately.
The idea, I think, is to make this decision once, not every single
extension install. Chances are
git's default guess will be pretty good (say, /usr/local), but if a
user decides that he wants to install
this, and all future extensions in ~/.gitplugins, then this can be
indicated once, with global configuration
that overrides the compiled in default.
Again, part of the idea is to give the extension installer some degree
of confidence that the selected prefix/bin is, in fact,
in the path and to give the user an override in case the compiled in
default isn't workable for some reason (for example, due to a
permissions issue).
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