Subject: Re: [PATCH v8 3/4] worktree add: add --orphan flag

From: Junio C Hamano <[email-masked]>
Date: Sat, 14 Jan 2023 19:09:16 -0800

Jacob Abel <[email-masked]> writes:

>> 	git worktree add --orphan -b topic main
>> 	git worktree add --orphan -B topic main
>
> I am hesitant to add these as they break away from the syntax used in
> `git switch` and `git checkout`.

Not that I care too deeply, but doesn't it introduce end-user
confusion if we try to be compatible with "git checkout --orphan
<branch>", while allowing this to be compatible with the default
choice of the branch name done by "git worktree add"?  "--orphan" in
"git checkout" behaves similar to "-b|-B" in that it always wants a
name, but "git worktree add" wants to make it optional.

By the way "--orphan" in checkout|switch wants to take a name for
itself, e.g.

	git checkout --orphan $name [$commit]
	git checkout -b $name [$commit]
	git checkout -B $name [$commit]

so it is impossible to force their "--orphan" to rename an existing
branch, which is probalby a design mistake we may want to fix.

In any case, as I said, I do not care too deeply which way you guys
decide to go, because I think the whole "orphan" UI is a design
mistake that instills a broken mental model to its users [*].

But let's wait a bit more to see which among

(1) git worktree add [[--orphan] -b $branch] $path
    This allows --orphan to act as a modifier to existing -b,

(2) git worktree add [(--orphan|-b) $branch] $path
    This allows --orphan to be another mode of -b, or

(3) git worktree add [--orphan [$branch]|(-b $branch)] $path
    This allows --orphan to default to $(basename $path)

people prefer.

[Footnote]

* I am not saying that it is wrong or useless to keep an unrelated
  history, especially one that records trees that have no relevance
  to the main history like created with "switch --orphan", in the
  same repository.  Allowing "git switch --orphan" to create such a
  separate history in the same repository blurs the distinction.  It
  would help newbies to form the right mental model if they start a
  separate repository that the separate history originates in, and
  pull from it to bootstrap the unrelated history in the local
  repository.