Re: [RFC/PATCH 0/7] Rework git core for native submodules

> Linus Torvalds <torvalds@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
>    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?