On 23/01/14 07:09PM, Junio C Hamano wrote: > Jacob Abel <jacobabel@xxxxxxxxxx> 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. Yes. I think it's a fairly minor degree of confusion but I agree that it adds potentially unneeded confusion. > > 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. Can you elaborate on what you mean by "rename an existing branch" here? Do you mean like `git checkout --orphan $branchname` being able to convert an existing branch into an orphan/unborn branch? Also a small point but in an earlier thread [1], we made the decision to model functionality on `git switch --orphan $branch` instead of `git checkout --orphan $branch [$commit]`. > > 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 [*]. Understood. > > 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. > I'd personally argue that option 2 (the current behavior) is probably the cleanest path forward as option 3 requires a bit of awkward code [2] and `--orphan` is such an esoteric option that the user may only use it once or twice in the life of a given repository, if that. And eventually I'd like `git worktree add $path` to "just work" on a new/empty repository. However as things stand, there wasn't an easy way to do this without leading to potentially confusing behavior. It can be done, I just haven't taken the time to figure it out yet. Once `git worktree add $path` "just works" (when creating the first branch in a repo), I highly doubt anyone would use `--orphan` often enough to justify the use of shorthand options 1 or 3. > > [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. Definitely agreed that `--orphan` is esoteric and probably should be avoided by most users where possible. 1. https://lore.kernel.org/git/CAPig+cSVzewXpk+eDSC-W-+Q8X_7ikZXXeSQbmpHBcdLCU5svw@xxxxxxxxxxxxxx/ 2. https://lore.kernel.org/git/20230114224956.24801-1-jacobabel@xxxxxxxxxx/
