Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > ... The features you seem to be after (ie that whole > floating/refname thing) don't seem fundamentally antithetical to the > current model (a "commit" SHA1 of all zeroes for floating, with a new > refname field in .submodules? I dunno).. Just on this part. I think Heiko and Jens's (by the way, why aren't they on the Cc: list when this topic is clearly discussing submodules? Don't we want to learn how the current submodule subsystem is used to solve what real-world problems?) .gitmodules updates is exactly going in that direction. - A submodule can be marked as floating in .gitmodules and be specified how (typially, "use the tip of this branch in the submodule"); - Running "submodule update" a floating submodule does not detach the submodule working tree to commit in the index of the superproject; instead it will use the specified branch tip; - A floating submodule records a concrete commit object name in the index of the superproject (no need to stuff an unusual SHA-1 there to signal that the submodule is floating---it is recorded in the .gitmodules). Thanks to this, a release out of the top-level can still describe the state of the entire tree; - It would be normal for the commit recorded in the index of the superproject not to match what is checked out in the submodule working tree (i.e. the tip of the branch in the submodule may have advanced). A traditional non-floating submodule has many mechanisms to be noisy about this situation to prevent users from making an incomplete commits, but they may have to be toned down or squelched for floating submodules. Anything I missed, Jens, Heiko? -- 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