Re: [RFC/PATCH] worktree: replace "checkout --to" with "worktree new"

[Junio C Hamano <gitster@pobox.com>]

Duy Nguyen <pclouds@gmail.com> writes:

> I think this is like "git checkout -b" vs "git branch". We pack so
> many things in 'checkout' that it's a source of both convenience and
> confusion. I never use "git branch" to create a new branch and if I
> had a way to tell checkout to "move away and delete previous branch",
> I would probably stop using "git branch -d/-D" too. "--to" is another
> "-b" in this sense.

I didn't know "checkout --to" included "create a worktree elsewhere
and chdir there"; if that "and chdir there" is not something you are
doing, then I do not think "checkout -b" vs "branch" analogy applies.

> "git worktree new" definitely makes sense (maybe stick with verbs like
> "create", I'm not sure if we have some convention in existing
> commands), but should we remove "git checkout --to"?

I'm in favor of removing "--to" before it escapes the lab.

I am ambivalent about "new", but that is only because I know about
the 'new-workdir' in contrib/.  If I pretend to be a naive end user,
I'd think a verb subcommand would be more in line with the rest of
the system than "new".

I however do not think "create" is a good verb.

Wouldn't "git worktree $the-command-in-question" be a management
command that adds a new worktree to the existing collection, like
"remote add", "notes add", etc. do?  Perhaps "git worktree list" and
"git worktree remove $that_one" would be in its future?

That suggests "add" may be a better choice for "worktree".

The only subcommand that I can think of offhand that says "create"
is "bundle"; after generates a new bundle, its presence is not known
to the repository the bundle was created out of, so not using "add"
but calling the operation "create" is fine for "bundle".