Sorry, I wasn't totally clear. Forgive me as I'm in the middle of a bad flu :)
As Ryan says, hosting both the monolithic stuff AND the modules can be dangerous, unless the modules are actually independent. The Symfony project, for example, hosts the whole framework in a large github repo, and maintains a read only version of most of its modules in separate repos. This seems to be a good use-case for subtree. For your scenario, I would suggest submodules. On 27 February 2013 23:41, Ryan Hodson <hodson.r...@gmail.com> wrote: > Hi Ben, > > To expand on Gergely's reply a bit, it sounds like what you're looking for > is `git submodule`, not `git subtree`. Submodules were designed to solve > exactly the problem you're facing. > > Each submodule is essentially its own independent Git repository. If you > have RepoA that relies on RepoB, you would add RepoB as a submodule to > RepoA. Then you can pull in upstream commits from RepoB as you would with a > normal Git workflow and access them from RepoA. There are a few extra `git > submodule` commands you would need to learn to keep things in sync. > > If I have GitHub host both monolithic and splitted out repos, it seems >> unclear as to how I keep those repos in sync and make sure all the >> developers in our company push their changes to both repos. > > > This sounds like a dangerous idea. I would use submodules instead. > > Ryan > > -- > You received this message because you are subscribed to the Google Groups > "Git for human beings" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to git-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
