Multiple GIT projects in a folder

Question

I have a cpp folder with all the libraries and programs ordered like so

cpp/libraries
cpp/programs

cpp/programs/proj1
cpp/programs/proj2
cpp/testing/

Until now, it was quite ok to use one big cpp git, which just had everything in it. However, because I do more than one project at a time at the moment, it has become rather inconvenient to have all the commits to both projects mixed. I've read a lot about submodules, including why they're not so good. My specific case is 100% offline (only pushed to a USB stick for taking it with me).

My ideal solution would be several gits in the subfolders (for projects), which are completely independent, but keeping the "all over" git (for testing and libraries etc), which has the whole cpp folder in it. Much like using .gitignore and just init the ignored subfolders project1 and 2 to be new gits. It is !not! necessary for me to have the libraries in the same git as the projects. But if I start a new one within the current one, I allways get "modifications to untracked files" instead of working directory clean...

Are submodules really a solution to this? Is there some other simple way? As I said, it's a special case, since these are my private/local gits and I just need it to be as simple as can be (no need to be strictly consistent or anything).

I use git as cli tool, and unless there is a huge benefit in a gui thing (mac) I don't really want to change this.

Thanks for suggestions.

Answer 1

There are two solutions built into Git: submodules and subtrees. There are also a number of external solutions that use tools to implement a similar process (e.g. git-repo).

Submodules are implemented using full independent repositories for the subprojects. These repositories are typically cloned from a remote and then the clone is stored in the superproject's .git directory and have their work tree projected into the subdirectory in the superproject work tree. The subprojects' history remains directly related to the "upstream" or shared history on the remote. That is, the Git commit hashes are identical for the same commits.

Subtrees are implemented in a more "clever" way (for good and bad). The subproject is imported into the superproject as a file tree but Git remembers that it did so, and can support remembering the URL of the remote that was imported etc. Because the subproject becomes a real and direct part of the superproject, it is easy to make changes. You don't have to separately commit or manage changes to the subproject. But IMO this is both good and bad. Often you explicitly want to make subproject (e.g. library) changes intentionally separate from the superproject (e.g. application using the library). And it's easier to overlook this distinction with subtrees than with submodules. Also with subtrees, all the subproject commits will be mixed in with the superproject commits. You can "squash" the subtree commits, but that makes pushing and pulling changes from the subtree remote more difficult (and time consuming) as the squashed tree diverges from the remote every time it is updated in the superproject.

One nice thing with Git is that you can, as I did, try creating two versions of your project in a temporary directory, one each using subtrees and submodules, and see which works better for you.

Answer 2

I do this routinely for the WIKI repository that is allowed on Github and Bitbucket. Simply ignore the subfolder, and manage the repositories as individual repositories. Not an issue.

So, I don't use submodules for this purpose.