CODEWITHSUNDEEP
gitgit-submodules
Vladimir Panteleev
Vladimir Panteleev

Reputation: 25187

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:

  1. 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.

  2. 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 status output, and you can't easily git add the new submodule state.

  3. 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 --bind mounts do work. Although the repository layout is different (lib/.git is 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 sudo access.

Is there a better way to do this, i.e. tell git to look for a submodule's repository elsewhere on the filesystem?

Upvotes: 4

Views: 2015

Answers (1)

CodeWizard
CodeWizard

Reputation: 142214

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
https://git-scm.com/book/ch4-1.html#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.

Upvotes: 3

Related Questions