4

We are currently using SVN to develop an internal application that has most of its functionality in plugins. In our approach to switch git, this app is causing some headaches as to what the best practice is regarding handling this kind of project in git.

I.e. should we put every plugin into its own git repository? This would seem a logical choice as the plugins are mostly not depending on each other and rather stand-alone (just using the core app for framework functionality and management of common functions), often developed by different persons and occasionally deprecated. However there are now well over a dozen plugins with more to come and building the whole project would usually require checking out all (or most) of the plugins one by one. And there does not seem to be an easy way to check out ALL of them at once, i.e. there probably needs to be some kind of "list" out there so people know what to get and what not.

On the other hand, putting everything in one git repository seems to be not in the spirit of git, esp. as we would carry around old dead code and working on just one plugin would require checking out a lot of code (though then most developers working on it would check out everything anyway). Also branching would always branch everything (which makes for example cross-testing of branched features difficult if the plugins can't branch individually)

One idea is to use submodules, but I don't know whether the overhead (mental overhead, I mean) is bigger than the gain (or, whether we gain less than we lose with using the one-for-all approach).

How would/do you handle this kind of project in git?

Mike
  • 65
  • 2

1 Answers1

4

This kind of system (as in "collection of writable components") would be best managed with:

  • each plugin in its own repository
  • one parent project which would declare all the relevant plugins as submodules.

As detailed in "true nature of submodules", you can then modify any plugin directly from that one parent project.
(See also Duplicate submodules with Git if you have duplicate dependencies) And recent Git releases comes with commands able to recursively checkout all the submodules of a parent project.

So when I check the parent project out and remember to call "git submodule init" for each plugin, I would have all projects on my desktop.

But you shouldn't have to remember to do anything beside git submodule update --init --recursive (just one command). As I said, it will recursively initialize all your submodules.

However submodules are pinned to versions, wouldn't this cause some more complicated workflow?

The principle of dependency management is to always reference a specific version (as opposed to reference "the latest code out there" for one component).
But that doesn't prevent you to:

  • work in that component (working from that specific version *as a starting point")
  • commit
  • push that one component to its remote repo
  • go up one level, back in the parent project
  • commit the parent project (in order to reference the new version of the submodule you just modified)

Again, true nature of submodules details that process.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • So when I check the parent project out and remember to call "git submodule init" for each plugin, I would have all projects on my desktop. However submodules are pinned to versions (http://stackoverflow.com/questions/720669), wouldn't this cause some more complicated workflow? – Mike Nov 30 '10 at 07:32
  • Thanks for the link, this is really interesting, though frankly more a reason not to use submodules (or do I read this wrong?) – Mike Nov 30 '10 at 07:36
  • @Mike: I have completed my answer to address your questions. Submodules are very important when you have a component-approach (see http://stackoverflow.com/questions/769786/vendor-branches-in-git/769941#769941) What do you find against their usage? – VonC Nov 30 '10 at 07:41
  • I have not actually used them, so my musings are all in theory. But from what I read I find it cumbersome to have to do a commit (and possibly push) in the parent project for every push that I do in a subproject. Also there will be more than one person working on the different subprojects (and hence parent project) which could become messy regarding when/what to pull to keep everything synchronized ??And I'm not even talking about accidental pulls in the parent repo. – Mike Nov 30 '10 at 09:50
  • I think the bullet points at http://nopugs.com/why-ext summarize quite well what I find potentially troubling with submodules in this particular case. They really seem to be intended (and there probably doing a splendid job) to have external dependencies connected to your project. – Mike Nov 30 '10 at 10:22
  • @Mike: 1/ it is an old post (status, for instance, can show submodules status recursively) 2/ submodules are not the same than external http://stackoverflow.com/questions/3131912/why-are-git-submodules-incompatible-with-svn-externals/3132221#3132221 3/ I agree with you, a full "system" approach is not easy to pull off with git submodules. I prefer developing each modules separately, and update my main project with the right set of new commits from those plugins (component approach) See http://stackoverflow.com/questions/769786/vendor-branches-in-git/769941#769941 – VonC Nov 30 '10 at 12:09
  • Thanks for your detailed answers, very much appreciated. It's not entirely clear to me yet how I will handle this, but I have a better grasp now. I guess I will just have to test it out. – Mike Dec 01 '10 at 16:48