[mal10c]

My personal setup is: /home/eric/repos/

All git repos end up in that folder - it's basically my project folder. Before explaining more, I should specify that this setup works well for me, but I could see how others may not agree with it.

Let's say I have 2 projects called prj1 and prj2. In that case, I would have the following directories:

/home/eric/repos/prj1 /home/eric/repos/prj2

Both of those would be git repos. Now, let's say that both of those repos rely on a shared repo, which I'll called shared-repo. In that case, I would have this:

/home/eric/repos/shared-repo

Then (and here's the part that probably won't sit well with folks), I just reference the parent directory from either prj1 or prj2 to access shared-repo.

Down sides: I'm forcing a hard coded directory hierarchy and directory naming. Up side: it's simple. If symlinks worked just as well on Windows as they do on Linux, I could just create a symlink in both prj1 and prj2 that points to my shared-repo directory and that could solve this whole mess too.

Having said all that, submodules have worked for me in the past, but I use them so rarely that I always need to look them up - so I've gotten in the habit of keeping things simple for myself and just doing things the way I mentioned above.

[TOGoS]

I've used a similar system, and tried to formalize this approach at work. The directory containing the projects is the "workspace" or "deployment" (depending if you're talking about your dev machine or a server, but same structure), and it contains "projects". Take whatever set of projects at whatever versions they need, check them out to the workspace, maybe set some environment variables (or symlink apache config files) as applicable, and hit the run button.

The biggest downsides of this approach that I discovered are that (A) projects are not self-contained, which meant some expert (i.e. me) always had to go and fix the deployments, because nobody else understood the system, and (B) a lot of the frameworks we used had their own system for organizing dependencies, which meant that we'd end up with projects inside projects inside projects anyway, and this system, whose intended purpose was to _flatten_ the directory tree, effectively just added another level to it.

Edit: (C), which is a variation of (B): if some projects are in monorepos, that throws off the system, too. Now instead of workspace/project you have workspace/monorepo-project/subproject, so now in some cases you have to reference "../../something" instead of just "../something". Not everything fits into the nice flattened-out system where relative paths are easy to guess, so you end up having to either merge things together with symlinks, which gets confusing because now you have two parallel structures going on, or just configuring dependencies with environment variables after all (at which point you wish you had just formalized the environment variables from the beginning to make everything explicit).

[okamiueru]

The more important downside I see is code traceability and verification. You would completely be void of both with that setup.

I'm not saying you shouldn't, as it works for you, and that's of course fine.

But, the key functionality of submodules is that the sumodule can exist on its own, as a git repo. The degree of dependency is then entirely controlled by the parent git repo.