Re: RFC: a plugin architecture for git extensions?

On 04/28/2011 12:32 AM, Jon Seymour wrote:

Why not just flip executable bits on commands in the git directory? That way, built-ins can't be disabled no matter what you type, and the list of out-of-core helpers will be kept shorter.

Either way, the "activate" thing requires you to maintain state of downloaded extensions that aren't part of the core package. I'd say it's safe to assume that anything downloaded is supposed to be active and deactivating it is done by means of uninstalling it.

But seriously. Don't you see how complex this is? If you want to make
things easier for people, put up a website or a database somewhere and
ship a (very, very small) addon with core git that just goes to fetch
that list and present it to users upon request. The list should contain
3 fields and 3 fields only.
1. Short name of extension (must be unique)
2. Url for where to get the extension
3. Free-form text, containing info of why anyone would want to use it,
   preferrably in the style of git.git commit messages so the brief
   description is the first line and the full info comes later.

Then your extension manager becomes really straightforward and can easily be extended over time to also uninstall applications.

This assumes that git core itself can provide paths for where the user wants man-pages and whatnot, ofcourse, but such a patch is so trivial anyone who's seen code in any language can easily hack it up blindfolded. Even for versions that doesn't support it, the man- pages of any extension can be guessed from the --exec-path or just ignored and all of them put into /usr/share/man or whatever the path might be on the system we're on, so long as the extension manager remembers where they ended up. This could easily be handled by the extension itself creating a manifest file after it's done installing which is stashed away by the extension manager.

A decent first step would be to have "git pm list" just show what extensions are available, what they do and where to get them.

However, that info could just as easily be distributed to users by letting "git help" or something print a link to a wiki page and by letting extension devs know about some officially blessed way of installing and uninstalling extensions properly. Once all extensions use that same way and there are more than a small handful of extensions, the idea of having a script download and automagically install those extensions will probably be opened up again, but by then with more than a single user backing it up with a request that it be implemented (without showing any code).

Shipping a bunch of extensions with git core or making distro package maintainers ship them as deactivated by default makes absolutely no sense what so ever. Shipping a (very small) extension manager with git that aids users obtaining more extensions makes sense when there's a proper flora of them rather than just a few.

Either way, it's time to put your money where your mouth is and show us some code that does what you think is a good idea.

If I were you, I'd start with the blindfolded patch mentioned above and then follow up with a configurable directory where git will search for additional commands, with a sensible default in the user's home directory (.git-plugins, perhaps?).

Let conflicts go hang for now. They will be thoroughly frowned upon
by the community anyway, since providing any sort of help for the
command "git fniggle" will be totally impossible if there are 100
different implementations of it.
 
With those two patches in place in core git (which I'm fairly sure
Junio won't reject out of hand given his opinions in this thread),
coding up the "make install" part of extensions become trivial and
starting on the real extension manager becomes at least possible for
both types of core git users, namely:
1. Those who get core git from yum/brew/apt-get
2. Those who build it from sources.