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

[Mark Levedahl <mlevedahl@gmail.com>]

On 06/30/2015 06:11 PM, Eric Sunshine wrote:
> On Tue, Jun 30, 2015 at 12: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".
>> [...]
>> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
>> ---
>> This is primarily a code and documentation relocation patch, with minor
>> new code added to builtin/worktree.c. Specifically:
>>
>> * builtin/worktree.c:new() is new. It recognizes a --force option ("git
>>    worktree new --force <path> <branch>") which allows a branch to be
>>    checked out in a new worktree even if already checked out in some
>>    other worktree (thus, mirroring the functionality of "git checkout
>>    --ignore-other-worktrees").
>
> Speaking of "git worktree new --force", should we revisit "git
> checkout --ignore-other-worktrees" before it gets set in stone? In
> particular, I'm wondering if it makes sense to overload git-checkout's
> existing --force option to encompass the functionality of
> --ignore-other-worktrees as well. I don't think there would be any
> semantic conflict by overloading --force, and I do think that --force
> is more discoverable and more intuitive.
>

I agree with -f subsuming --ignore...:  -f/--force should really mean 
"do this if at all possible", not just "ignore some checks". Similar to 
rm -f, etc.

Maintaining --ignore-other-worktrees, and making that a configurable 
option (worktree.ignoreothers??) would allow selectively ignoring just 
this one issue, perhaps permanently, but not the others -f already 
overrides. This would make sense if other options were added to ignore 
other subsets of checks that can block a checkout, probably not otherwise.


Mark