On Mon, Jun 19, 2017 at 11:09 AM, Patrick Lehmann <Patrick.Lehmann@xxxxxxx> wrote: > Hello Stefan, > > the use case is as follows: > > The projects consists of circa 18 IP cores. Each IP core is represented by a Git repository. Think of an IP core as of a lonestanding DLL or SO file project. Each IP core references 2 submodules, which bring the verification environments for testing the IP core standalone. So phrased differently: You are using submodules to avoid "DLL hell" (sharing a lib, with ease of versioning as the submodules in the different IP cores may be pointing at different versions). > > These 18 IP cores are grouped to bigger IP cores, referencing the low-level IP cores and each again the 2 verification submodules. Finally, the main project references the bigger IP cores and again the 2 verification cores. > > TOPLEVEL > o- IP1 > o- UVVM > o- VUnit > o- IP2 > o- UVVM > o- VUnit > o- IP3 > o- UVVM > o- VUnit > o- IP4 > o- UVVM > o- VUnit > o- IP5 > o- UVVM > o- VUnit > o- IP6 > o- UVVM > o- VUnit > o- IP7 > o- UVVM > o- VUnit > o- IP8 > o- UVVM > o- VUnit > o- IP9 > o- UVVM > o- VUnit > o- IP10 > o- UVVM > o- VUnit > o- IP11 > o- UVVM > o- VUnit > o- IP9 > o- UVVM > o- VUnit > o- IP12 > o- UVVM > o- VUnit > o- UVVM > o- VUnit > > That's the simplified structure. I can't write more, because it's a closed source project. You can find other usecases e.g. in my other open source projects. E.g. The PoC-Library or The PicoBlaze-Library and the corresponding PoC-Examples repository. > > Example: PoC > Pile of Cores includes 4 Git submodules and is itself an IP core library. > So PoC-Examples again references PoC. This looks like this tree: > > PoC-Examples > |- lib/ > o- PoC > |- lib > o- Cocotb > o- OSVVM > o- VUnit > o- .... OSVVM > o- UVVM > > The library VUnit itself already includes OSVVM as a library. > > ---------------------- > Forcast: > I'll write a new question / idea about multiple equal submodules and the memory footprint soon... > Here is my original question posted on StackOverflow: https://stackoverflow.com/questions/44585425/how-to-reduce-the-memory-footprint-for-multiple-submodules-of-the-same-source > ---------------------- > > Do you need more use cases? > Well this use case points out a different issue than I hoped for. ;) >From the stackoverflow post and from looking at the layout here, one of the major questions is how to deduplicate the submodule object store for example. By use case I rather meant a sales pitch for your initial email: I use this bash script because it fits in my workflow because I need branches instead of detached HEADS, because $REASONS and I'd be interested in these $REASONS, which I assumed to be * easier to work with branches than detached HEADS (it aids the workflow) * we're not challenging the underlying mental model of tracking sha1s in the superproject rather than branches. At least I gave these reasons in the "reattach HEAD" stuff that I wrote, but maybe there are others? (I know the code base of submodules very well, but I do not work with submodules on a day-to-day basis myself...)