Brandon Williams <bmwill@xxxxxxxxxx> writes: > I don't know why submodules were originally designed to be in a > detached HEAD state but I much prefer working on branches (as I'm sure > many other developers do) so the prospect of this becoming the norm is > exciting! :D The reason is because the superproject already records where the HEAD in the submodule should be, when any of its commits is checked out. The tip of a branch (which one???) in a submodule may match that commit, in which case there is nothing gained by having you on that branch, or it may not match that commit, in which case it is unclear what should happen. Leaving your submodule on the branch would mean the state of your tree as a whole does not match what the checkout operation in the superproject wanted to create. Resetting the branch would mean you may lose the history of the branch. Thinking of the detached HEAD state as an implicit unnamed branch that matches the state the superproject checkout expects was conceptually one of the cleanest choices. But all of the above concentrates on what should happen immediately after you do a checkout in the superproject, and it would be OK for a sight-seer. Once you want to work in the submodules to build on their histories, not being on a branch does become awkward. For one thing, after you are done with the work in your submodule, you would want to update the superproject and make a commit that records the commit in the submodule, and then you would want to publish both the superproject and the submodule because both of them are now updated. The commit in the superproject may be on the branch that is currently checked out, but we don't know what branch the commit in the submoudule should go. The submodule.<name>.branch configuration may be a good source to learn that piece of information, but it does not fully solve the issue. It is OK for the tip of that branch to be at or behind the commit the superproject records, but it is unclear what should happen if the local tip of that branch is ahead of the commit in the superproject when checkout happens. By the way, how does this topic work with the various checkout modes that can be specified with submodule.<name>.update?