Am 04.04.2013 21:17, schrieb Junio C Hamano: > 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? Nope, that perfectly sums it up. -- 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