Francesco Pretto <ceztko@xxxxxxxxx> writes: > by default "git submodule" performs its add or update operations on a detached > HEAD. This works well when using an existing full-fledged/indipendent project as > the submodule, as there's less frequent need to update it or commit back > changes. When the submodule is actually a large portion of shareable code > between different projects, and the superproject needs to track very closely > the evolution of the submodule (or the other way around), I feel more confortable > to reattach the HEAD of the submodule with an existing branch. I may be missing some fundamental assumption in your mind when you did this change, but in a workflow where somebody wants submodule checkout to be on branches (as opposed to detached), wouldn't it make more sense not to detach in the first place, rather than introducing yet another option to "re-attach"? The documentation of "submodule update" seems to say that its "merge" and "rebase" modes do not detach in the first place (and it alludes to "--checkout" but it is unclear what it does purely from the documentation, as "git submodule --help" does not even list it as one of the options). And if there is a good reason why detaching to update and then (perhaps after verifying the result or cleaning it up? I dunno what the expected use case is, so I am purely guessing) attaching the result to a specific branch in separate steps, does it make sense to give "--attach" option to "update" in the first place? That makes the whole thing into a single step, not giving the user a chance to do anything in between, which I am guessing is the whole point of your not using the existing "do not detach, work on a branch" modes. Puzzled... -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html