

Git will do an automatic submodule update (see sidebar again) on git checkout in the superproject if you have set the recursion option for that checkout. There is no combination of options that makes git submodule update run the command you want. (See sidebar below.) If you consult the documentation, you will see that git submodule update has a huge number of options. What actually runs the git checkout inside each submodule is a git submodule update command. So when do you get branch-name behavior in submodules? There are no built in cases where exactly this occurs, but there are a few ways to make it happen. Where $branch is set to a branch name, that comes from somewhere. Or: git -C path/to/submodule switch $branch What you'd like to see, apparently, is: git -C path/to/submodule checkout $branch Declaring a branch for a submodule, with the git submodule add -b option for instance, does not change this behavior. But it's the way submodules are intended to work. Precisely when it goes into the submodule and does this gets us into all the gory details. It does so at some particular set of times. Now, this too is too strong a claim: the superproject doesn't always go into the submodule and run a detached-HEAD switch / checkout command. So it's the current commit that controls the hash ID that the superproject forces upon the submodule. The $hash value for this command is determined by the index in the superproject Git repository, and the index hash value is initially that from the current commit. Whenever you have the superproject in charge check out some commit in the superproject. Or equivalently: git -C path/to/submodule switch -detach $hash

The superproject Git will run: git -C path/to/submodule checkout $hash The key to understanding everything about submodules is that the superproject lists a raw commit hash. Second-and this is the part that makes it a submodule, rather than just a plain repository-it's controlled by some other Git repository, which Git calls the superproject for this submodule. It has branch and tag names that help Git find those commits, but it's really all about the commits. If you start with that idea in mind, the rest of it all makes sense.įirst, it is a Git repository, so it consists of commits. This is a slight overstatement, but the main thing here is that it's only slight.

You'll want to write or find a little wrapper to deal with it (or hooks: see see philb's comment).
