Re: Auto update submodules after merge and reset
- From
Phil Hord <phil.hord@gmail.com>
- Date
- Dec 11, 2011, 14:43 UTC
- Message-ID
- <CABURp0qmOQy0=1d7RwXMO3Bm7GwXh-60fwOKFHhyG3kDkxqxxg@mail.gmail.com>
- In-Reply-To
- <4EE2B8C3.6000906@ursus.ath.cx>
On Fri, Dec 9, 2011 at 8:41 PM, Andreas T.Auer <andreas.t.auer_gtml_37453@ursus.ath.cx> wrote:
Show 17 quoted lines
>>> It is even nice to see which commits in the submodule belong to what >>> branches in the superproject or to what release version (so tracking >>> superproject tags would make sense, too). If you have a submodule that >>> has >>> more than one superproject but these are well-defined, it could be solved >>> using refspecs (e.g. refs/super/foo/* for one and refs/super/bar/* for >>> the >>> other superproject), but currently I can't think of a context where this >>> makes sense. >> >> I can, but this does put the cart before the horse. The submodule is >> subservient to the super project in all my setups. The submodule is >> not aware who owns him. He is a bit like the DAG in reverse. He >> knows one direction only (children), not the other (parents). > > In the setup I have in mind, the submodules are not subservient to the > superproject, but a part of the whole project.
I see that. I have a similar project with about 20 submodules. None of them are useful on their own; they are logical divisions of a large project.
Architecturally, submodules are oblivious of their super-projects in all other respects. Changing the architectural underpinnings should be a last resort, I think.
Phil