CODEWITHSUNDEEP
gitgit-submodules
poke
poke

Reputation: 387607

Submodule for independent plugins

I’m looking for a way to organize my project’s repository. The project is closed source but it contains a single subfolder which I want to make publically available. That folder contains “plugins” that are called from the main project. All those plugins require that the main project is there, but of course the main project does not need them to work.

The usual approach would be to use a submodule for the plugins, but I’m not too happy with what this means to the main project. As the main development is completely separate from the plugins, I don’t want to mess up its history with updates from the plugins submodule, and I actually don’t want the plugins to be part of the main (core) program.

So what I rather want to have is the reverse situation where the main program is a submodule of the plugins repository so that the main development is completely independent from the plugins. The problem is that my program structure requires the plugins to be inside of the main directory tree, so that they can be accessed correctly.

Is there some standard approach to such a situation where the submodule is the “bigger” or “outer” repository? Or do you have another idea to solve this?

Upvotes: 2

Views: 216

Answers (1)

ColinM
ColinM

Reputation: 13936

Three options:

  1. Simply do a separate clone of the plugins repo manually. Add "plugins" directory to the runtime repo's .gitignore file and put a note in the README detailing the location of the plugins repo and how to clone it. Plugins repo can be updated at any time with a simple cd plugins; git pull. You could add a post-receive hook on the main git repo locally to update the plugins repo if you wish to avoid extra steps, but this would only affect your local repo.

  2. Use a submodule. In order to get the latest plugins into your runtime environment you'd have to do commits to track the head of the plugins submodule. E.g. git add plugins; git commit -m "tracking latest plugins". Updating/deploying could then be done with git pull; git submodule update --init --recursive

  3. Use a subtree. I don't think this is what you want, but you can read about it at Pro Git. Updating the plugins would require multiple steps which may not even be doable while in production.

If you have some sort of automated build system I'd consider a submodule. Otherwise I'd just go with 1 since it will have the least maintenance.

Upvotes: 2

Related Questions