In message <CAEBDL5VUPE9YCX1C4pqkjb+EODkAWo9h774B=Jv5eUNbocMuZQ@xxxxxxxxxxxxxx>, John Szakmeister writes:
> 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
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.
-Seth Robertson
--
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