Duy Nguyen <pclo...@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". -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
