Martin Waitz <tali@xxxxxxxxxxxxxx> writes: > What is stored in the supermodule? It stores a reference to a specific > point in the history of the submodule. As such I am convinced that > the right counterpart inside the submodule is a refs/heads/whatever, > and not the branch selector HEAD. Because 'submodule' is a project on its own, it can make progress while the parent project is still using the stable commit. Think of this: - Your application uses product of another project as a library (e.g. you are doing video application and embedding ffmpeg). - Your 'master' commit records a commit in the library subproject. Maybe library subproject declared stable 1.0 and that is what you used to integrate. - But being an independent project on its own, the library project can make progress, outside the context of this aggregated work (i.e. your application). Next time you do: $ cd ffmpeg ; git fetch there may not be any branch that points at the exact "stable 1.0" commit. When you do a "checkout -f --recurse-into-subprojects" from the toplevel, I suspect that you would need to detach HEAD in the subproject repository grafted in your application tree to move it to the exact commit the toplevel project (i.e. your application) wants, and match the working tree to that commit. The toplevel simply should _not_ have to care what branch that commit comes from. - 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