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

[Mikael Magnusson <mikachu@gmail.com>]

On Wed, Jul 1, 2015 at 12:27 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Eric Sunshine <sunshine@sunshineco.com> writes:
>
>> On Tue, Jun 30, 2015 at 12:56 AM, Eric Sunshine <sunshine@sunshineco.com> wrote
>> 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.
>
> "git checkout -f" is to throw-away local changes, which is a very
> sensible thing to do and I can see why that would be useful, but
> does --ignore-other-worktrees have the same kind of common-ness?
>
> It primarily is a safety measure, and if the user wants to jump
> around freely to different commits in multiple worktrees, a more
> sensible thing to do so without getting the "nono, you have that
> branch checked out elsewhere" is to detach HEADs in the non-primary
> worktrees that may want to have the same commit checked out as the
> current branch of the primary worktree.
>
> I would mildly object to make --ignore-other-worktrees more
> discoverable and moderately object to make that feature more
> accessible by overloading it into "--force".  I personally would not
> mind if we removed "--ignore-other-worktrees", but that might be
> going too far ;-)

This probably falls under "not common", but one of my uses for git
new-workdir is to check out the current branch in another directory,
rebase it to upstream, delete that worktree, and then git reset --hard
in the original checkout. The result is a rebased branch that touches
a minimum of source files so the rebuild is faster. (In some projects
I have a lot of local commits that get rebased, but maybe upstream
only touched a single .c file).

-- 
Mikael Magnusson