[PATCH] Git support for plugin installation

Nice!

The SVN version uses export, which is an unversioned dump. Your git version uses clone, which is a full copy of the repo. Would that really play nice with an app that is in git already?

Not sure if git has an equivalent of export. http://www.koziarski.net/archives/2008/2/23/on-git#comments suggest git archive.

I'd love to know the command to just grab the latest full piece of code from a git repo but I haven't found it yet. git-archive just keeps giving me errors.

Having a .git directory in the plugin doesn't interfere with the main git repo for the app. The patch could easily be extended to just remove the .git directory after cloninig. But it would so nice to just export it!

use git clone --depth 1

From man git-clone:

       --depth <depth>
              Create a shallow clone with a history truncated to the specified number of
              revisions. A shallow repository has a number of limitations (you cannot clone or
              fetch from it, nor push from nor into it), but is adequate if you are only
              interested in the recent history of a large project with a long history, and would
              want to send in fixes as patches.

Using "--depth 1" to get a shallow checkout of the git repo

evolving_jerk is highly evolved. Thanks for actually learning stuff so I don't have to!

Patch is attached and it seems to work much better like this. I have it delete the .git directory once the plugin is checked but if anyone think it's better to keep it please attach a modified patch.

Oh, cool. I thought about that (Capistrano with git uses --depth 1, too) but didn't realize it was such a good fit here. Good work, evolving_jerk.

I believe there should be an option --keep-git-metadata. Will submit a patch with that.

Danger,

I took a look at the patch and believe plugin.rb should be refactored to use installation adapters. As long as it uses OptParse for options we can conveniently add options like --use-git or --keep-git-metadata. Later we can add --use-hg or --use-darcs or --use-bazaar.

Your approach implies that I use git:// protocol access but I tend to access my own plugins using ssh://user@host, and there are folks using http://.

Will submit a patch after my 3 days trip.

another way I way acceptable is to add git-plugin.rb, hg-plugin.rb and so forth. This would give you all set of cmd options you want to pass to your git-oriented installer, for example, and you won't have to check that options for different VCSs passed simultaneously do not conflict somehow.

What do you guys think?

Replying to evolving_jerk:

another way I way acceptable is to add git-plugin.rb, hg-plugin.rb and so forth. This would give you all set of cmd options you want to pass to your git-oriented installer, for example, and you won't have to check that options for different VCSs passed simultaneously do not conflict somehow. What do you guys think?

I think that's a helpful refactoring down the road but that this should be done in two parts. There's a lot in plugin.rb that's poorly written and poorly coupled but that's something that should be done once we get a functioning prototype in place.

Replying to evolving_jerk:

Danger, I took a look at the patch and believe plugin.rb should be refactored to use installation adapters. As long as it uses OptParse for options we can conveniently add options like --use-git or --keep-git-metadata. Later we can add --use-hg or --use-darcs or --use-bazaar. Your approach implies that I use git:// protocol access but I tend to access my own plugins using ssh://user@host, and there are folks using http://.

It checks for anything that uses the git:// protocol OR ends in ".git". I wasn't sure how else to distinguish a git repository.

Will submit a patch after my 3 days trip.

That would be most welcome :-)

danger,

I have done some investigation. It seems that current implementation has to be refactored first to use SCM adapter abstraction. Also stuff like commands should be carried out from a single plugin.rb.

I'd like to have it applied in it's current form (or something near to it) and then start work on some decent refactoring.

+1 then :)

+1

+1. Also, it may be a good idea to install plugin as a git submodule. As an optional feature.

(In [9049]) Added support for installing plugins hosted at git repositories (closes #11294) [danger]