Re: RFC: a plugin architecture for git extensions?

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

 



On Fri, May 6, 2011 at 4:56 PM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote:
> Jon Seymour wrote:
>
>> I would appreciate any feedback you (or others) have about:
>>
>> Â Â http://permalink.gmane.org/gmane.comp.version-control.git/172419
>>
>> In particular, I would be interested in feedback about how to best support:
>>
>> - multiple extensions - do we want support installing extensions in
>> their own directories, per Pau's suggestion or simply allow them to
>> write to a common directory?
>> - multiple extension directories - how to support Jonathan's
>> requirement to allow user specific extension directories?
>
> Well, let's step back for a moment. ÂWhat problem are we solving?
> I still don't even know the answer to that!
>

Jonathan,

Thanks for your detailed reply.

I think the problem we are trying to solve is this: how to make it as
easy as possible to install, and get operational, an extension to git.

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.

If there is no post-installation configuration step, then it becomes
much easier to write an adhoc script that produces a working
environment that has the extension already operational.

The idea is that the person or distribution who(/which) installed git
onto the system has already made decisions about where artifacts
should go. Neither the user nor the extension author should have to
second guess or reverse engineer these decisions. Given that git has
been installed in X, then let's use convention to say that extensions
can install in X/lib/git-plugins/ (say) and then have git able to use
those extensions immediately with no additional configuration step
because this directory is already (effectively) in the PATH.

To the extent that a configuration step is necessary, post install, it
would be good if the configuration was limited to facilities that are
available in every git installation (e.g. git config --global).

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]