If you are familiar with symlinks under Linux, you can think of submodules
as such. You add a reference to another git repository, check it out to a
subdirectory, and you are done. The Git book has a chapter on it:
http://git-scm.com/book/en/Git-Tools-Submodules
On 27 February 2013 23:21, Ben
Hmm, I just assumed I should use subtree because pretty much every single
thing I've ever read that references them says that subtree
is preferable to submodules in nearly every way. Are submodules better in
this case for some reason?
On Wed, Feb 27, 2013 at 2:29 PM, Gergely Polonkai
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,
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
Hmm, that's interesting to hear. I'd read a couple articles that led me to
believe I shouldn't consider submodules at all (e.g. these two on HN: Git
Subtree merged into mainline githttp://news.ycombinator.com/item?id=3926683
, Why your company shouldn't use Git
Ben,
That second article is a bit preachy. The `git submodule` command exists
for a reason, and I would trust it over any of the 3rd-party alternatives.
That said, it can be a bit finicky to work with at times. The key to
remember is that the parent project always points to a *snapshot* (i.e., a
