Re: git remote vs. submodules
- From
Tomas Carnecky <tom@dbservice.com>
- Date
- Nov 11, 2010, 11:34 UTC
- Message-ID
- <4CDBD4D4.1080607@dbservice.com>
- In-Reply-To
- <AANLkTinev0W7-mm9wXmnZwY6DxN0Y2X0hJdpBOgM_4q=@mail.gmail.com>
On 11/11/10 2:45 AM, Patrick Doyle wrote:
Show 23 quoted lines
> Hello All, > I was just reading about git remote and I started thinking to myself, > "Gee, nothing I've read says that the remotes have to share a common > ancestor. I wonder what would happen if I added two independent > repositories as remotes to a superproject?" > > So I tried it in a very trivial case. The first thing I learned was > that I need to make the subprojects subdirectories of a top level > .git-housing directory. Or else, when I merge them in, everything in > the top level of subproject1 gets mixed in with everything in the top > level of subproject2. So this doesn't seem to be a good solution for > marrying arbitrary subprojects together. But if I set up a library of > subprojects properly, it seems like I could do this. > > So now I'm wondering... has anybody else ever had thoughts along these > lines? Has anybody tried this? Has anybody seen it work (or fail > miserably)? > > Why would I want to do this instead of using submodules? I dunno. It > just came to mind when I started trying to understand what's really > going on with remotes. And I vaguely (and perhaps even correctly) > recall there being some controversy regarding submodules when they > were first introduced.
Are you maybe looking for a subtree merge? http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html
tom