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

From: Eric Sunshine <sunshine@sunshineco.com>
Date: Jun 30, 2015, 22:02 UTC
Message-ID: <CAPig+cT7X=LOtgYjXWx=EBJpMrytntQHgdSzdN=prqaysanaCw@mail.gmail.com>
In-Reply-To: <CACsJy8BYeYq-fQX=M1h2r4daQSsemXQT4Y+ww2Z3Y54brUS3QQ@mail.gmail.com>

On Tue, Jun 30, 2015 at 5:23 AM, Duy Nguyen <pclouds@gmail.com> wrote:

Show 11 quoted lines

> On Tue, Jun 30, 2015 at 11:56 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
>> The command "git checkout --to <path>" is something of an anachronism,
>> encompassing functionality somewhere between "checkout" and "clone".
>> The introduction of the git-worktree command, however, provides a proper
>> and intuitive place to house such functionality. Consequently,
>> re-implement "git checkout --to" as "git worktree new".
>
> 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 [...]
>  "--to" is another "-b" in this sense.

I too always use "git checkout -b", but, like Junio, I don't think this is an apt analogy. "git checkout -b" is shorthand for two commands "git branch" and "git checkout", whereas "git checkout --to" is not.

> "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 could do "git
> co -b foo --to bar" for example.

You can still do that with "git worktree new bar -b foo", which is effectively the same as "git checkout --to bar -b foo" (with s/checkout/worktree/ and s/--to/new/ applied), though perhaps you don't find it as obvious or natural.

> If we are not sure about "--to" (I'm not), I think we just remove it
> now because we can always add it back later.

I'm not excited about keeping "git checkout --to" as an alias for "git worktree new", however, removing it now should not harm us since, as you say, it can be added back later if needed.

Show 10 quoted lines

>>  SYNOPSIS
>>  --------
>> +'git worktree new' [-f] <path> [<checkout-options>] <branch>
>
> Should we follow clone syntax and put the <path> (as destination)
> after <branch> ("source")? Maybe not, because in the clone case,
> explicit destination is optional, not like this.. Or.. maybe <branch>
> could be optional in this case. 'git worktree new' without a branch
> will create a new branch, named closely after the destination.
> Existing branch can be specified via an option..

I'm not wedded to this particular argument order, though it does have the advantage that it's clear which options belong to "worktree new" and which to "checkout".

As for making <branch> optional and auto-vivifying a new branch named after <path>, that's something we can consider later (I think).