tags:

views:

778

answers:

2

When switching branches with git checkout I would assume that most of the time you would want to update your submodules.

  • In what situation do you not want to update submodules after switching?
  • What would break if this was done automatically by git checkout?

Updated with example:

  • Branch A has submodule S at 3852f1
  • Branch B has submodule S at fd72d7

On branch A, git checkout B will result in a working copy of branch B with submodule S at 3852f1 (with a modified S). git submodule update will checkout S at fd72d7.

+6  A: 

I believe that the submodules not updating automatically is in line with the development goals of Git. Git is meant to work in a distributed mode and doesn't presume that you are even able to connect to a non-local repository unless you explicitly tell it to. Git not auto-refreshing a submodule would be the expected behavior when thought of that way.

With that being said, if you know that you always want those sub-modules to be pulled in and you know that you would never branch off of those submodules to another local repository, then it shouldn't break anything if you automatically refreshed them after a checkout.

Aaron
I think git checkout should just complain if the commit for a submodule was unavailable instead of leaving the working directory in an inconsistent state by default. Then you could do git submodule update to fetch the referenced commit. Again, normally the commit will be available and the checkout can be done without any network access. Accepting your answer since it sounds reasonable (but I don't like it ;)
Serbaut
+3  A: 

From the git submodule man page (emphasis mine):

Submodules allow foreign repositories to be embedded within a dedicated subdirectory of the source tree, always pointed at a particular commit.

Given that submodules point to a specific commit, it would not make sense for them to automically update. The only time they will update is when you change the commit to which they point.

This Frasier Speirs blog entry provides a good overview of git submodules. It includes a comparison to svn:externals for those familiar with that system. The relevent quote from the blog:

The big thing to remember is that, unlike svn:externals, updating your superproject from a master repository does not do the same for the project's submodules. If you think about it, this makes sense: the submodules are locked to specific commits in their respective repositories.

Tim Henigan
Updated the question with an example, I think you missed the point.
Serbaut