Re: RFC: a plugin architecture for git extensions?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, May 9, 2011 at 9:07 PM, Jon Seymour <jon.seymour@xxxxxxxxx> wrote:
> 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.
>>
>

BTW: the reason why I want the git actually installed to provide this
hint about the best place to install,
rather than use installation script heuristics is that the locally
installed git + the user supplied configuration
is in a much better situation to suggest a good choice than an install
script that is trying to be platform and distribution agnostic.

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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]