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