git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Glen Choo <chooglen@google.com>
To: git@vger.kernel.org
Subject: Re: [RFC] Branches with --recurse-submodules
Date: Wed, 10 Nov 2021 10:21:08 -0800	[thread overview]
Message-ID: <kl6lh7cjvpm3.fsf@chooglen-macbookpro.roam.corp.google.com> (raw)
In-Reply-To: <kl6lv912uvjv.fsf@chooglen-macbookpro.roam.corp.google.com>


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.

> === Switching _from_ a branch `topic`, i.e. `git {switch,checkout}`
>
> Check `topic` if each submodule’s worktree is clean (except for
> gitlinks), and has one of the following checked out:
>
> * `topic`
> * the commit id in the superproject gitlink
>
> This allows the user to switch with a dirty worktree (with respect to
> the superproject). We consider this acceptable because the submodule
> commits are tracked by the submodule branch. This is helpful when a user
> needs to switch branches before they are ready to commit to the
> superproject.

Note that this is how git switch with submodules already works - users
can switch away from a dirty superproject worktree as long as the
submodule worktrees are not dirty. However, without branches, this is
perilous because a user could unintentionally switch away from their
submodule WIP and have no easy way of recovering their work.

The proposed UX solves this by making the WIP tracked by a branch by
default. If a user switches _away_ from their WIP 'topic' branch...

> === Switching _to_ a branch `topic`, i.e. `git {switch,checkout} topic`
>
> Switch to `topic` in the superproject. Then in each submodule, switch to:
>
> * `topic`, if it exists
> * Otherwise, the commit id in the superproject gitlink (and warn the
>   user that HEAD is detached)
>
> If the submodule `topic` points to a different commit from the
> superproject gitlink, this will leave the superproject with a dirty
> worktree with respect to the gitlinks. This allows a user to recover
> work if they had previously switched _away from_ "topic".

they can still recover their WIP state by switching _back_ to their WIP
'topic' branch.

  reply	other threads:[~2021-11-10 18:21 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 [this message]
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
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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=kl6lh7cjvpm3.fsf@chooglen-macbookpro.roam.corp.google.com \
    --to=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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).