On Thu, Jul 14, 2011 at 10:33 AM, Seth Robertson <in-gitvger@xxxxxxxx> wrote: [snip] > 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. > > You might find that gitslave (http://gitslave.sf.net) might be a > better solution for you than git-submodules in this case. It works > better for many workflows (and worse for others) but is much simpler > to understand since with gitslave you have JBOR (just a bunch of > repositories) with a program which can be thought of as running the > requested git command over each repository in turn. Gitslave thus has > a loose binding between the repositories, and you can only guarantee > the relationship between repositories at tagged locations, though in > practice this isn't a major concern. Interesting. I'll take a look! > gitslave supports nested repositories (and recursive gitslave > repositories, but those are different). With gitslave nested > repositories it is also true that you would have to have a > supplemental gitignore entry in framework1 (which gitslave will > create). > > If you have any questions, please let me know. I appreciate it. Thanks Seth! -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