From: Philippe Blain <levraiphilippeblain@gmail.com>
To: Glen Choo <chooglen@google.com>, git@vger.kernel.org
Subject: Re: [RFC] Branches with --recurse-submodules
Date: Thu, 11 Nov 2021 22:22:49 -0500 [thread overview]
Message-ID: <f88923bc-4a3d-e6e8-2c04-d75bef8a35d9@gmail.com> (raw)
In-Reply-To: <kl6lh7cjvpm3.fsf@chooglen-macbookpro.roam.corp.google.com>
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@google.com> 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...)
next prev parent reply other threads:[~2021-11-12 3:22 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-08 22:33 [RFC] Branches with --recurse-submodules Glen Choo
2021-11-10 18:21 ` Glen Choo
2021-11-10 18:35 ` rsbecker
2021-11-10 19:35 ` Glen Choo
2021-11-10 20:25 ` rsbecker
2021-11-11 18:12 ` Glen Choo
2021-11-12 3:22 ` Philippe Blain [this message]
2021-11-12 3:19 ` Philippe Blain
2021-11-15 19:03 ` Glen Choo
2021-11-23 18:36 ` Philippe Blain
2021-11-23 19:04 ` Glen Choo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f88923bc-4a3d-e6e8-2c04-d75bef8a35d9@gmail.com \
--to=levraiphilippeblain@gmail.com \
--cc=chooglen@google.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).