On Wed, Jul 13, 2011 at 5:20 PM, Jens Lehmann <Jens.Lehmann@xxxxxx> wrote: > Am 13.07.2011 03:21, schrieb John Szakmeister: [snip] >> 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 > > But that would mean the superproject would have to scan framework1's > work tree for changes too, which is conflicting with the idea that each > submodule is a repo of it's own, so that won't fly. I guess I just don't see that. Even though the path is inside of a submodules, it would be part of the superproject's work tree. But, I can see how it's a violation of a submodule being a repo of it's own. And I certainly understand the desire to maintain that quality. >> 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. > > It can't be communicated, as submodules are unaware of their superproject. > And adding module manually to framework1's .gitignore is just a problem > waiting to happen. Having a file or submodule in the work tree of one > git repository being referenced by another is just asking for trouble ... Again, I don't see how the submodule needs to be aware of the superproject. In this case, it'd be the responsibility of the superproject to setup whatever is necessary at 'git submodule init/add'. I don't see how the submodule *must* know about the superproject for it to succeed. I see the opposite, the superproject needs to communicate some information down to the submodule, but I don't see the reverse. What I'm hearing is that while it may be possible, the idea of violating the concept that the "subrepo is standalone" is unacceptable. Which means, unfortunately, git isn't a solution for us in this case. [snip] >> 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. > > You're right, the error message of "git submodule add" should be better > here. I'll write a patch for this. Thanks. And thanks for the input. I was just looking to see if there were any technical/morale reasons that submodules weren't allowed in this way. I appreciate you all taking the time to answer. -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