Re: RFC: a plugin architecture for git extensions?

From: Jon Seymour <jon.seymour@gmail.com>
Date: Apr 27, 2011, 05:06 UTC
Message-ID: <BANLkTikUi5RKjgdmQHjg1-s0ND+ot4J3AA@mail.gmail.com>
In-Reply-To: <20110427035825.GA4546@elie>

On Wednesday, April 27, 2011, Jonathan Nieder <jrnieder@gmail.com> wrote:

Show 19 quoted lines

> Hi Jon,
>
> I haven't looked into 'git work' yet, but for my own private tweaks,
> two mechanisms have sufficed:
>
>  * adding a program named git-foo to the $PATH introduces a
>    'git foo' command.  For the git command look and feel, scripts
>    tend to start with
>
>         . "$(git --exec-path)"/git-sh-setup
>
>    (see git-sh-setup(1) for details).
>
>  * various existing git commands can have their behavior modified
>    through configuration and hooks.
>
> Does 'git work' require changing the behavior of existing commands,
> and if so, are there hooks that could be introduced to help in doing
> that?

git work is all new, so such considerations don't apply. Actually there is one thing - I proposed a new config variable whose description I left out of the tar ball version because I didn"t want to touch existing files in a git install. The other thing II needed to do was include my man pages so they get picked up by git help.

I can see that there might be a class of extension that 'enhances' existing git commands. No doubt that would be a tricky problem to solve and such a solution would not necessarily be good for the git platform in any case.

 I guess one thing a git plugin architecture could do is provide
management of the PATH for plugins, a way to manage man pages and a
way to manage plugin specific configuration help.

jon.

| missed the list unintentionally, the first time through