Re: Nesting a submodule inside of another...

>    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.

> 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.