From: John Szakmeister <john@szakmeister.net>
Date: Fri, 15 Jul 2011 08:34:46 GMT
Subject: Re: Nesting a submodule inside of another...
Message-ID: <CAEBDL5XzhuSQSzEMQ8yRupcufyQ=shtiTWejez0Mt75e0sJ-Vg@mail.gmail.com>
In-Reply-To: <201107141433.p6EEXbb9023826@no.baka.org>

On Thu, Jul 14, 2011 at 10:33 AM, Seth Robertson <in-gitvger@baka.org> 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