On 22/11/09 11:13PM, Eric Sunshine wrote: > On Fri, Nov 4, 2022 at 12:42 PM Jacob Abel <jacobabel@xxxxxxxxxx> wrote: > > On 22/11/04 01:03AM, Eric Sunshine wrote: > > > On Thu, Nov 3, 2022 at 9:07 PM Jacob Abel <jacobabel@xxxxxxxxxx> wrote: > > > Are we sure we want to be modeling this after `git checkout --orphan`? > > > If I understand correctly, that option has long been considered (by > > > some) too clunky, which is why `git switch --orphan` was simplified to > > > accept only a branch name but no commit-ish, and to start the orphan > > > branch with an empty directory. My own feeling is that modeling it > > > after `git switch --orphan` is probably the way to go... > > > > I would argue that the `git checkout --orphan` command format is preferable to > > `git switch --orphan` when creating new worktrees. Reason being that in many > > cases (except when working in a new repo), if you are trying to create a > > worktree from an orphan you will be doing it with a different commit-ish > > currently checked out in your worktree than the one you want to use for the > > orphan (or you aren't in any worktree). > > I guess I'm not understanding the use-case being described here or > that this series is trying to address. In my own experience, the very, > very few times I've used --orphan was when I needed a branch with no > existing history (i.e. "orphan") and with no existing files. For that > use-case, `git switch --orphan` is ideal, whereas `git checkout > --orphan` is a bother since it requires manually removing all content > from the directory and clearing the index. > > > Requiring the commit-ish to be inferred would limit the user to checking out > > an orphan from an existing worktree (in which case they could just create a > > new worktree normally and use `git switch --orphan` to move that to an orphan > > branch). > > I'm not following what you mean by inferred commit-ish. `git switch > --orphan` does not infer any commit-ish; it starts the orphaned branch > with an empty directory, hence there is no commit-ish involved. > > The `git switch --orphan` behavior was intentionally implemented to > "fix" what has long been considered (by some) a UX botch in the > behavior of `git checkout --orphan`. It was argued that in the vast > majority of cases, people wanted an orphan branch to mean both "no > history" and "no files". So, in that sense, it feels like a step > backward to adopt `git checkout --orphan` when introducing `git > worktree --orphan`. > > But, as I said, I'm genuinely not grasping your use-case, so I'm > having trouble understanding why you consider `git checkout --orphan` > a better model. If you can elaborate your use-case more thoroughly, > perhaps it would help (at least me). Ah I see where my misunderstanding was. I have significantly less experience with `git switch` vs `git checkout` so prior to responding I was trying to understand the difference in behaviour and I ended up misunderstanding what `git switch --orphan` was doing. I wrongly assumed that `git switch --orphan` was doing the same thing as `git checkout --orphan` but using the currently checked out branch. Additionally I had assumed that there was an important reason for being able to create orphans from existing branches and that not being able to select which branch to use would somehow be removing functionality. After re-reading your replies, I can see that this is not the case and that I jumped the gun on my reply prior to doing my research properly. I will make the requested change (moving from `git checkout` to `git switch` semantics) for v3. Apologies for the misunderstanding.
