On Mon, May 09, 2011 at 09:07:31PM +1000, Jon Seymour wrote:
> > 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.
Well, yeah. Though between git and the package script, I think it ends
up being simplified to the --system-extension-dir thing, because out of
the three places I mentioned you might want to install something:
1. You definitely don't want to install in the distro location. If you
did, then you would be a distro package, and therefore would not
have to be asking git where that location is.
2. You do need to know where the locally-installed system path is, so
we provide an option to query that.
3. You don't need to ask git where the per-user path is. It will be at
some well-known location like $HOME/.gitplugins.
That being said, I think you are more concerned with not presenting
too many choices to the user. And that still leaves one choice: system
(2) versus user (3) install.
But I don't think there's a way around that. You are going to have users
of both types, and you will want to serve them. You can make a guess
based on something like writability of the system directory, I suppose,
and let them override via the command-line if they want to.
That strikes me as somewhat flaky and unpredictable, but I am perhaps
not a representative sample. I have always thought the Windows "if you
install as Administrator, it is available to everybody, but otherwise it
is available only to you" behavior was confusing, and this seems like
the same thing.
> 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.
I think this is in agreement with what I just wrote above.
> 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).
So from this, I gather you would like to see something like:
$ cd git-work && ./install
fatal: unable to write to /usr/local/share/git: permission denied
You may install git-work just for the current user with:
./install --user
I.e., the script has a predictable and sane behavior, but you guide the
user through overriding it if need be. That doesn't seem unreasonable to
me.
Anyway, with respect to "core.preferredPluginPath", if you do want to go
in that direction, I don't think any extra git support is needed. You
can already just do "git config --path core.preferredPluginPath" to get
the value (with tilde-expansion, even).
-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