Hi David! Glad to discuss this and update my knowledge with your help!
I've tried to use git-submodules back a few years (sub 1.6). Back then it was pretty unusable. Maybe something has changed which went under my radar, but imo the restrictions (from the back of my head) which we must check if they still apply are: 1.) each git-submodule is still an own GIT repo. There is imo no move possible out of the submodules without loosing history 2.) each git-submodule is still an own GIT repo. Maybe this got added lately, but they imo don't share git-remotes. All this needs to maintained manually. Is there a way now to update all the remotes for all contained git-submodules in 1 step? 3.) nested git-submodules are NOT nested on the disk in the object store! They are imo in fact independent GIT repos and there is just a kind of 'symlink' (gitlink resp via the .gitsubmodules: "the submodule support just stores the submodule repository location and commit ID") to include them 'inplace'. 4.) you can clone/checkout 'nested' git-submodules since (1.6.4 or even later?) automatically, but you cannot push isn't?. This might have been fixed? Also see here: > git submodule add ~/git/$i $i > NOTE: Do not use local URLs here if you plan to publish your superproject! The reason is that you need to use a full git-remote URL here if you publish this. Now let's consider forking. As far as I've tested out, all the submodules _still_ point (git-remote origin) to the original repo ^^ Can you please verify that nowadays? This was quite a while back when I tried it. I now found a hint that this maybe work now (though didn't test it myself): > git clone --recursive URL 5.) The .gitsubmodules file is part or the working set (similar to .gitignore). Thus changing it (for adopting the remote URL) will change the sha1. 6.) by using git-submodules you are basically almost always working with a detached HEAD. Working with detached HEADs is pretty hard to get for git newbies. 7.) git-submodules makes working with branches sometimes pretty ugly. Because any directory content might not get updated. Just create a sample project and try to work with it. Or try to split Geronimo into smaller pieces with git-submodules and work with it. Would love to see that a few of those questions are non-issues today! LieGrue, strub ----- Original Message ----- > From: David Jencks <[email protected]> > To: [email protected] > Cc: > Sent: Saturday, December 3, 2011 7:07 PM > Subject: Re: Accepting proposals regarding early git adoption > > Hi Mark, > > Your couchdb links don't seem to me to argue for or against what I was > suggesting, other than pointing out that unless git project == releasable > subproject you'll have an impedance mismatch, which is what I was trying to > point out and avoid. > > The git docs http://book.git-scm.com/5_submodules.html certainly seem to > indicate that my suggestion should work fine and when I suggested it on the > aries list David Bosschart mentioned that JBoss has been using submodules in > this way for a long time with great success. > > What's your evidence that submodules won't work for this? >
