On Tue, Jul 12, 2011 at 3:23 PM, Jens Lehmann <Jens.Lehmann@xxxxxx> wrote: > Am 12.07.2011 14:01, schrieb John Szakmeister: >> I've got a project where we have several frameworks involved, and >> external modules we want to pull into the framework tree. We'd like >> to make use of submodules and have something like this: >> top-level/ <-- .gitmodules lives here >> src/ >> framework1/ <-- a submodule >> module/ <-- another submodule >> framework2/ <-- a submodule >> module2/ <-- another submodule >> >> Currently, git fails trying to do this. It's not happy about >> .gitmodules living at the top-level and nesting a submodule inside of >> another[1]. Is there a technical reason that this is not allowed? > > Submodules are repositories of their own, so their work tree is outside > the superproject's work tree. You're attempting to have a submodule of > the superproject inside another submodule of the superproject, but this > won't work because it does not live in the superproject's work tree (as > that doesn't include submodules and their subdirectories). I guess I still don't see how that's a problem. It seems to me that for the superproject the ignore rule needs to be: ignore framework1, except framework1/module And then it could check its status. Of course, framework1 would somehow need to know to ignore it... and I'm not sure how that can be communicated. > To have nested submodules you must add "module" as a submodule of > "framework1" and "module2" as a submodule of "framework2". Then git > will handle them just fine (assuming you use the --recursive option for > "git submodule update" and friends). Of course that means that if you > want to record a new commit of a sub-submodule in the superpoject, you'll > have to commit that in it's parent submodule first and then can record > that commit in the superproject. (But if "framework1" wouldn't depend on > a specific version of "module", there would be no reason to put it inside > it in the first place, right?) We can't do that. The base framework should not include the module in its repository. We drop in different modules that get shared across some projects, but not others. They get mixed and matched. This was pretty straight-forward to do with Subversion. Admittedly, I don't like the layout of it... but unfortunately, I'm not really in control of that either. >> Limiting the traversal up the tree, etc.? I've worked around the lack >> of support to do this for now, but it would be really nice if we could >> do such a thing. > > I can't think of a sane way to make that work. :-( [snip] > But at least since 1.6.2 git should issue a meaningful error message. > With current master I get: > > $ git add sub/file > fatal: Path 'sub/file' is in submodule 'sub' Sorry, I wasn't trying to do a 'git add'. I was trying to do a 'git submodule add'. > What version are you using? I'm using 1.7.6rc3. I updated to the latest trunk and still get the same error: :: git submodule add $PWD/../c b/c The following path is ignored by one of your .gitignore files: b/c Use -f if you really want to add it. HTH. -John -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html