Linus Torvalds <torva...@linux-foundation.org> 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
- A submodule can be marked as floating in .gitmodules and be
specified how (typially, "use the tip of this branch in the
- 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html