Re: RFC: a plugin architecture for git extensions?

From: Junio C Hamano <gitster@pobox.com>
Date: May 5, 2011, 21:53 UTC
Message-ID: <7vhb986chl.fsf@alter.siamese.dyndns.org>
In-Reply-To: <88795B20-6994-46A5-9710-2ADC84E04695@gmail.com>

David Aguilar <davvid@gmail.com> writes:

Show 11 quoted lines

> On Apr 28, 2011, at 3:56 AM, Jon Seymour <jon.seymour@gmail.com> wrote:
> 
>> What is so hard about the concept of an application providing a
>> facility that allows it to request, merely request, the installation
>> of a plugin for itself by what ever happens to be the users choice of
>> package manager or distribution.
>
> It's not hard.  We simply don't need it. 
>
> Why do I need to activate my "plugin"?  That seems like a needless
> feature. If I don't want "git gui" I apt-get uninstall git-gui.

I mostly agree with you that what Jon has wrote so far is overengineering to solve a problem that does not exist [*1*].

But here is one thought.

Imagine this "git gui" is not "git gui" but "git superadd" package that changes the behaviour of "git add" slightly.

    Side note: Of course, for this kind of usage, the "git potty" needs to
    be extended to look for things in different places, and also it needs
    to be made easy for the implementation of "superadd" to call the
    underlying "git add", bypassing itself, when necessary.

You do not want that new interface, you are old timer and you like the old way of doing things like me ;-). But your wife wants to use it. You two share a computer.

Do you or do you not run "apt-get install git-superadd"?

One possible answer may be to run "apt-get install git-superadd", and then the users who want "git add" to behave in a new way to opt-in to use the "plug-in". I think that is what Jon is getting at.

[Footnote]

*1* I admit that I didn't read all of them carefully, as I was repelled by them as soon as I saw phrases like "for people who can grok this concept".