On Sun, May 8, 2011 at 4:49 PM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote:
> Jon Seymour wrote:
>
>> The idea isn't to replace standard operating system facilities for
>> application installation. The idea is to provide a uniform interface
>> for accomplishing the rather limited task of extending git that can
>> work the same way, irrespective of platform, irrespective of file
>> system layouts, irrespective of assumptions about which directories
>> are already in the user's paths.
> [...]
>> If at the end of the day, we say make and install are the way to do
>> it, then fine. However, this makes the dependencies for a successful
>> install strictly greater than the existence of git and a POSIX shell
>> which we can assume if git is already installed.
>
> Thanks for explaining, and sorry to have given so much grief by not
> understanding.
>
> If this whole conversation were about how to add a new menu item to
> git gui, I would have understood completely. ÂHaving to figure out how
> to get something in a directory listed in PATH would be undue
> complication.
>
> After going in circles a few times, I think you're saying there are
> also some people using git on the command line for whom "make
> prefix=<whereever> install" won't cut it. ÂWith such a person in mind,
> what you're trying to do makes sense --- and why not do it, when it
> will bring some other benefits as a side-effect, like the ability to
> add new commands without them showing up in git-<TAB> tab completion?
> So I'll be quiet now.
>
Admittedly, I think there might be concrete advantages in making at
hard as possible for such users to get anywhere near a git command
line, but hey, I work in an environment where ClearCase looks like a
reasonable option to some people :-)
Your point about support for extension supplied HTML is an interesting
one, that I don't think I have an answer for other than an
installation script that is aware of git --html-path. The reason is,
you want links to descriptions of core git commands to just work in
such html, and the only way you can get that to happen reliably is to
install in some directory that is strictly relative to the location
that git's own HTML is stored in.
So, in the end, I think I would be happy with a solution like:
git --system-extensions-prefix
which answers the recommended prefix for the installation of
extensions. This might default git's own prefix, but may be configured
differently by distribution or builder preference. If we did allow it
to be different to the git prefix, then I think the git runtime would
need to be extended to allow $(git --system-plugins-prefix)/bin to
appear in the path, and then use the existing gt help mechanisms to
find the
man pages.
Would a patch along these lines be acceptable, do you think?
jon seymour.
--
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