7

Judging just from the number of results for "git submodule" here on SO alone, this is clearly a commonly asked and easily confused topic, so I will try to be as precise as possible.

Forgetting everything about updating/committing/branching submodules (which I understand greatly complicates things), why do submodules get emptied each time I change branches? From my current understanding, this makes branches expensive; what if I'm at the airport, and can't easily/cheaply connect? Am I doing something wrong, or there's some development philosophy that I'm not yet aware of?

Examples never hurt:

## make a new project
$> git --version
git version 1.7.5.4
$> mkdir new_proj; cd new_proj; git init
$> touch new_file_1.txt; touch new_file_2.txt
$> git add . && git commit -m "first commit"

## move into some development branch
$> git checkout -b cool_feature
$> <hack hack hack>
# in the middle, I add a submodule
$> git submodule add https://github.com/some/other_proj.git other_proj
$> git submodule update --init
$> ls -lR
new_file_1.txt
new_file_2.txt
other_proj
other_proj/that_file
other_proj/another_file

## I have to go back to master to do some work
$> git checkout master
# Why is other_proj still around?
$> git status
Untracked: other_proj
## Fine, I'll remove it, since I want a clean working copy, because I need to do some work and commits
$> git clean -f -d
$> <work work work>

## Now I'm ready to go back to cool_feature, but my submodules are empty!
$> git checkout cool_feature

At this point, I'm supposed to git submodule update, but what if I can't/it's expensive (e.g. it's remote, and I don't have internet access/it's slow).

The best workaround I've come up with is to clone all the submodules that I care about into a completely separate location, and then submodule from my local clones; this preserves the cheapness of submodules. Of course, this adds another layer of complexity when you're working on a team. :/

Mat
  • 202,337
  • 40
  • 393
  • 406
Matt
  • 95
  • 1
  • 4

1 Answers1

2

Considering a submodule is nothing more than a pointer to a commit of another repo, the git submodule update is a bit unavoidable (in order to get back the content associated with said pointer).

One other workaround would be to clone your main repo:

  • one for the cool_feature branch, where you have your submodules
  • one for the master branch, where you don't have any submodules

Switching from one branch to another wouldn't require a git checkout (and its associated git submodule update), but a change of path.

The other workaround, if you want to work in one directory, has been described in "Replaced third party code with git submodules, now I can't switch branches"

move the submodule directory out of the way before switching to the master branch

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • 1
    Thanks for the response, and another workaround. It just seems... unfortunate... that you have to do stuff like this. It doesn't make sense to me why git can't keep the content of submodules local (it's a full git repo, right?) and just bring it back on checkout. Anyway, I'll leave this question up for a few more days, and then accept this as the answer. Cheers! – Matt Oct 21 '11 at 03:42
  • Me neither. Especially considering a copy is often found in ./.git/modules/**. 4-5 years later, still having to do the workaround. – jiku Jan 07 '16 at 00:18