Re: RFC: a plugin architecture for git extensions?

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

 



On Sat, May 7, 2011 at 12:17 AM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote:
> Jon Seymour wrote:
>
>> If git supported the concept of a standard place to put extensions,
>> then it could be as simple as:
>>
>> Â Â unzip -d $(git --plugins-dir) plugin.zip
>>
>> with no need to configure or choose a prefix and no need to edit the
>> an .profile or .bashrc to permanently add a directory to the PATH.
>
> Why not use "/usr/local" in place of "git --plugins-dir"? Â(I can
> think of one answer --- namely root privileges --- but it would apply
> to any system with one standard place to put extensions.)
>

Partly because that is second guessing &/or reverse engineering the
distribution's decisions and
it won't work for a Windows install where there is no /usr/local

Not that I currently, have a need, but Junio did mention the case
where someone wants to enhance an existing git command with a wrapper
of some kind. This could be done more precisely if git itself
controlled the relative order of the path components than if one
relied on /usr/local being in a particular place in the path.


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]