[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: [PATCH v3 1/8] clone: teach --detach option
From:       Glen Choo <chooglen () google ! com>
Date:       2022-10-31 17:07:12
Message-ID: kl6l5yfzdirj.fsf () chooglen-macbookpro ! roam ! corp ! google ! com
[Download RAW message or body]

Taylor Blau <me@ttaylorr.com> writes:

> On Fri, Oct 28, 2022 at 03:55:25PM -0700, Glen Choo wrote:
> > So a better way forward is to add the new flag, which I imagine might
> > be useful to certain end users.
> 
> Disappointing, though I understand why such a new flag was needed. Do we
> really care about whether or not the branch exists so long as we are
> detached from it, though?

Yes.

- With submodule branching, the "main" branch should correspond to the
  gitlink of the superproject's "main" branch. So when we clone, we
  can't _already_ have a "main" branch coming from the submodule's
  remote.
- Without submodule branching, submodules are always in detached HEAD
  (e.g. when updating the worktree recursively) and no submodule
  recursing functions create branches, _except_ "git clone
  --recurse-submodules" (which as we've seen, may create the branch
  corresponding to the submodule's remote). This just looks like an
  oversight IMO, which is why I noted that even without branching, "git
  clone --recurse-submodules" should probably also use "--detach" [1].
- Outside of submodules, I can imagine there's at least one person who's
  performed a clone and then "git branch -D master" (maybe followed by
  "git checkout -b main"), and "git clone --detach" lets them skip the
  branch deletion.

[1] https://lore.kernel.org/git/5a24d7e9255de407e343ce8bd60edb63293505bb.1666988096.git.gitgitgadget@gmail.com


> 
> Thanks,
> Taylor


[prev in list] [next in list] [prev in thread] [next in thread]