Using git for plugin development

Similar questions to this have already been asked, although they're not exactly what I'm trying to do.

At first I thought I needed a git submodule, then to set up a superproject and then a sub tree merge but I'm not sure if any of these really fit.

I have a project (Eva), and I'm writing some extensions for it that are optional. So if you were to pull down a copy Eva from Github, it wouldn't contain the optional plugins but you could fetch them separately and use them.

The optional extensions reside in the same directory structure as Eva. Simple so far ...

Eva
 |
 --- system/
 --- events/
   |
   --- core_events
 --- tests/
   |
   --- core_tests

Extension A
 |
 --- events/
   |
   --- [extension A]
 --- tests/
   |
   --- [extension A tests]

I wanted to add tests to those extensions tonight, and at present I have them in a separate directory outside of my local Eva git repo. In order to run these tests I really need these extension to live in the same directory as Eva, the events rely on the core system to run.

Eva
 |
 --- system/
 --- even开发者_如何学编程ts/
   |
   --- core_events
   --- [extension A]
   --- [extension B]
 --- tests/
   |
   --- core_tests
   --- [extension A tests]
   --- [extension B tests]

I could copy the Eva project files into the extensions repo directory but if I modify Eva's source, then I have to keep copying those changes across.

Should I continue with this clumsy set up or is there a more graceful way git can accomodate this?

Maybe my requirements are the reverse of the other questions. My extensions are a sub project of Eva and I need to pull in updates from the Eva repo around it occasionally.

If I add my extensions repo as a submodule when someone clones Eva they'll get all the optional plugins too? I don't want that.

Not sure a subtree merge fits either, I will never have to pull the extensions project into the core Eva project.

---

I think your best option is to try to change the project layout such that each extension is more self-contained, I.E. resides in it's own directory under say, /extensions.

On framework startup/testrun, scan that directory and dynamically load the extensions. That way you not only makes it easy to develop and work with git, but you also makes it easier for various packaging-options, I.E. tarballs. It makes it easy for the user to see what extensions are used.

You would then also allow 3d-parties to develop "out-of-tree" extensions easily using their VCS of choice.

---

What about a simple shell script that sits in hour project's root directory, call it plugin_manager, that lets a user list installed plugins, list available plugins on the project's server, and download and install new ones? That might be more intuitive to an end-user than wrangling git submodules, especially if they aren't otherwise familiar with Git.

Downloading and running the tests could just be one of the steps that the script does when the user runs $ plugin-manager download foo-module

For a good example pattern check out the documentation for The Drush (Drupal shell) commands.

---

I think this can be achieved using a git hook set up such that each commit (or push) to either the core or the extension repos (kept separately) causing an update of a release testing directory containing up-to-date copies of both. Lacking VonC's knowledge on this, I can however only redirect you to e.g. the manpage and Chapter 5 of the git community book.

In fact, an even easier solution would be setting up that release testing directory using softlink copies of both repos (cp -rs). Unfortunately in this case you have to remember adding new softlinks whenever you add new files to either repo.