Keep submodule outside working tree
I have a library, which I use in multiple projects as a git submodule.
Generally, there’s three ways one can go about this:
Let each project have its own copy of the library. This is what happens if you clone the projects with
--recursive. Obviously, this is wasteful, and can get confusing when working on more than one project at a time.
Don’t clone or register the submodule (i.e. leave it as the blank directory that git creates by default), and configure your build tools to look for the submodule elsewhere. Aside this complication, this also has the downside that new commits in the submodule will not be seen in the parent projects’
git statusoutput, and you can’t easily
git addthe new submodule state.
Make the library repository accessible as an alias in the submodule directory. On Windows, this is achievable using junction points; on Linux, symlinks don’t work (git thinks you deleted the submodule and replaced it with a symlink), but
--bindmounts do work. Although the repository layout is different (
lib/.gitis a real gitdir instead of just a file pointing to the one in
../.git/modules/lib/), this works fine, but creating the bind mount is annoying and does require
Is there a better way to do this, i.e. tell git to look for a submodule’s repository elsewhere on the filesystem?
One Solution collect form web for “Keep submodule outside working tree”
What you can do is to use the submodule with the
file:// protocol so it will be pointing to the desired folder. but it will only work on your local machine.
This is also known as the local protocol
The most basic is the
Local protocol, in which the remote repository is in another directory on disk.
This is often used if everyone on your team has access to a shared filesystem such as an NFS mount, or in the less likely case that everyone logs in to the same computer. The latter wouldn’t be ideal, because all your code repository instances would reside on the same computer, making a catastrophic loss much more likely.