Hi Glen,
Le 2021-11-10 à 13:21, Glen Choo a écrit :
I found some points that I should have given more attention to in the
RFC. I'd appreciate any and all feedback :)
Glen Choo <chooglen@xxxxxxxxxx> writes:
In a superproject-submodule relationship there is some ambiguity in what
‘checkout the branch `topic`’ should mean (does the submodule use its
topic branch, or the version recorded in the superproject’s gitlink?).
Our approach is to preserve existing semantics where reasonable - the
ref name refers to the superproject’s ref, just as it does without
--recurse-submodules.
Because a gitlink only contains a commit id, the submodule branch will
use a plain commit id as the branch point. This gives the correct ref,
but it gives no hints as to what the submodule branch should track.
The current thought process is to set up tracking using the ref name and
the submodule's config. Thus, a more complete description of
git branch --recurse-submodules topic origin/main
is something like:
* for each repository, create the 'topic' branch where each 'topic'
branch points to the version recorded in the superproject's
'origin/main'
* for each repository, setup tracking for the 'topic' branch using the
repository's own 'origin/main' as the branch point
Note that there is no guarantee that a submodule's 'origin/main' points
to the same commit as the superproject's 'origin/main', or if the
submodule's 'origin/main' even exists.
If tracking information cannot be setup, we will still create the
branch; we will only warn users when they run a command that requires
tracking information e.g. fetch or push.
OK. That makes sense. Another option could be to track the branch pointed
to by origin/HEAD in the submodule (in an ideal world, that would point to
the default branch, but that has to be done mostly manually as of today...)
