Question

I’m working with a framework that more or less forces me to mix my own code in with framework code–that is, neither can be isolated neatly into its own subdirectory. I have thus far kept them separate by using .gitignore to ignore all framework code, but when I needed to upgrade the framework I created an upgrade branch, and did the upgrade, not initially realizing that this would mean previously untracked/ignored files would be tracked in the new branch, and therefore would no longer exist when I switched back to the master branch.

After recovering from the massive facepalm moment, I thought I’d have to switch to using Git Submodules. The problem this poses, however, is that it appears that code belonging to a submodule must be kept in a subdirectory. From Pro Git:

Submodules allow you to keep a Git repository as a subdirectory of another Git repository.

Is this truly a limitation of git submodules, or is there any way around it?

Answer 1

I believe so (a submodule is a complete git repository on its own, and the same folder cannot contain two git repositories). I also believe that when there is a submodule in the folder Foo, the outer repository will ignore everything in Foo except that it will keep track of which revision the submodule is at.

(Warning: huge hack) However, you could have two separate git repositories, one inside the other, and “just” be very careful with the respective .gitignores – however, you won’t be able to make one repository control which revision the other repository is at. Also, the outermost repository will have to be one folder level outside of where your project is located (if it needs to include top-level files from that folder and you already have your main repository there), so if your project is at /foo/bar/Project, you need to have the framework repository in /foo/bar, in addition to the main repository in /foo/bar/Project.