1

I'm building a front-end framework, and in my current setup I have a development repo, a gem version, and a documentation app. Currently, I have the app and the gem in subfolders within the dev repo, allowing my taskrunner to automate building everything at once, keeping everything in line. I'm then manually copying the distribution versions of each to their respective repos. What this means though, is an enormous master repo that's doing far too much, and other repos that I'm having to be very careful about ensuring are in line. It's becoming extremely unwieldy; errors are creeping in.

Ideally, I want to work on the development version, and for changes to propagate out to the other two repos - for example, maybe when I test, commit and push the dev repo, this could then trigger an update on the other two to bring the versions inline. This would allow me to expand as/when needed - if I needed to add packages for other languages, I could build a new repo and add it into the project, and be confident it would work the same way.

I've tried submoduling, but this a. seems to work in opposition to what I want, and b. from past experience, git submodules are a nightmare to manage.

I've also tried having all the repos as folders within a parent, which has its own taskrunner that is in charge of cross-subproject concerns, but this is effectively the same what I have at the minute with a prettier structure; I'm still left needing to push each subproject to an individual repo.

Gitslave looks as if it might be helpful, but I'm not quite sure how I can leverage it.

Any advice specifically on this situation (or on how others have managed linked subprojects using git) would be really helpful.

DanCouper
  • 850
  • 6
  • 15
  • submodule remains the most likely approach. "seems to work in opposition to what I want": could you detail why it works in opposition? – VonC Sep 10 '14 at 09:28
  • I want to have a central repo from which changes propagate outwards. Whereas with submodules, I have a series of modules which sit within the central repo, and when individually updated, I can use `submodule update` on. I could have the central repo as a submodule within the other projects, but this is non-optimal, as it makes each of those individual projects huge, instead of keeping them extremely slim as they should be. – DanCouper Sep 10 '14 at 09:32
  • or just one command from the main parent repo: `git submodule update --init` – VonC Sep 10 '14 at 09:33
  • @VonC: submodules are yesterday's stale crust of bread, subtree - today's buns with raisins – Lazy Badger Sep 10 '14 at 10:32
  • @LazyBadger funny considering submodules were developer *after* subtrees. But if subtree (http://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/) is more your thing, here is an example: http://stackoverflow.com/a/24709789/6309 – VonC Sep 10 '14 at 12:20

1 Answers1

0
  1. Submodules can not work " in opposition" in principle - just grok it better
  2. Subtree in common is alternative for submodule in order to solve the same tasks, eliminate most of submodule's headaches (and don't touch standard Git-workflow, contrary to submodules)

Future reading and good use-case in details

Lazy Badger
  • 94,711
  • 9
  • 78
  • 110
  • Yeah, bad wording on my part I think; it's not that it's in opposition, it's the one-way communication that makes it...a pain in the arse, shall we say; the way it breaks up the workflow is not good. However, that case study looks very interesting; I'll just have a go at testing it out. – DanCouper Sep 10 '14 at 10:58