Johan Herland <johan@xxxxxxxxxxx> writes: > True, but as I've argued above, I'm not sure that adding another setting > (aka. .merge_branch) for this special/limited kind of branch tracking is > worth it. I don't think .merge_branch is necessary nor even desired. In fact, I think your use of .branch, especially in the variant that does not have any submodule entry in the superproject tree, of your version (B) does not have conceptual advantage. You checkout the superproject first (which would be the natural thing to do, as you may get update to its .gitmodules there), and checkout the then-tip of the named branch of the submodule, you would immediately get a stale checkout when you then go fetch the updates to the submodule. And the worst part is that you wouldn't even _notice_ that your checkout is stale, as there is no record in the superproject which commit you were supposed to be using to be consistent with the version the committer of the superproject commit used to record it. I on the other hand think what you called "hybrid" makes sense (and I don't even think it is hybrid but rather is a natural way to do this). With the submodule.*.branch entry, you can: - make sure that your checkout is consistent; if your submodule checks out a different commit or branch from what the superproject records in its tree or in its .gitmodules (e.g. you forgot to update the submodule when you switched superproject branch), git can notice the situation and can help you implement policy decisions; - record a commit that is different from the tip of the submodule branch when making a superproject commit; git can notice the situation and can help you implement policy decisions (e.g. you could choose to reject and tell the user to advance the submodule branch first before making the commit in the superproject); - use it as an advisory "existing merge commit selector", as discussed in this thread. Thinking about what would happen in your (B) that doesn't record the exact commit, I think that it doesn't have any advantage over the "hybrid" one. The "hybrid" one can help you to make sure that what you commit in the superproject's .gitmodules and submodule's branch tip are kept consistent. When they are kept consistent, then switching branches in the superproject should always flip between the tips of branches, no? -- 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