Linus Torvalds [off-list ref] 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?
Junio C Hamano wrote:
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.
Because it's pointless. We're not discussing a git-submodule
alternative. We're discussing how to fix git-core so that
git-submodule becomes much simpler; to the extent that it will be
unnecessary soon.
git-submodule is years of hard work and it can do a limited version of
floating with great difficulty. Mine is two days of work, and can
already do true floating submodules. What is going on?
Am 04.04.2013 21:17, schrieb Junio C Hamano:
Linus Torvalds [off-list ref] writes:
quoted
... 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.