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

Jacob Abel <jacobabel@nullpo.dev> writes:

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.