On Mon, May 9, 2011 at 9:24 PM, Jeff King <peff@xxxxxxxx> wrote: > 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 > I still think it would be useful for the git wrapper to add core.preferredPluginPrefix/bin to the PATH, so that there is no requirement for the user to do this separately via mechanisms that will differ according to platform, shell etc. 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