Re: [RFC/PATCH] worktree: replace "checkout --to" with "worktree new"
- From
Eric Sunshine <sunshine@sunshineco.com>
- Date
- Jun 30, 2015, 22:11 UTC
- Message-ID
- <CAPig+cT0a201MVTsvvLrndr40GsMkyvtao33Gt=AFhvShtr=Kg@mail.gmail.com>
- In-Reply-To
- <1435640202-95945-1-git-send-email-sunshine@sunshineco.com>
On Tue, Jun 30, 2015 at 12:56 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
Show 16 quoted lines
> 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.