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

From: Eric Sunshine <sunshine@sunshineco.com>
Date: Jul 1, 2015, 17:13 UTC
Message-ID: <CAPig+cRLpJK-C7MApH1vigZS=gmHNeo6RL3S2wXv4B-TFfnq4g@mail.gmail.com>
In-Reply-To: <xmqqr3orakex.fsf@gitster.dls.corp.google.com>

On Wed, Jul 1, 2015 at 12:53 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 19 quoted lines

> From: Eric Sunshine <sunshine@sunshineco.com>
>
> 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 add".
>
> As a side-effect, linked worktree creation becomes much more
> discoverable with its own dedicated command, whereas `--to` was easily
> overlooked amid the plethora of options recognized by git-checkout.
>
> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>
>  * Duy seems to think "worktree add" is coming, too, so here is a
>    trivial tweak of your patch from the last month, with test
>    adjustments to 7410 I sent earlier squashed in.

Thanks. I was planning on re-rolling to use the new name ("add" rather than "new") and to squash in the t7410 fix. Plus, I think the changes I had to make to prepare_linked_checkout() in order to move it to worktree.c should become separate preparatory patches so that the actual relocation can become pure code movement (as much as possible).

Also, I was planning on including Duy's patch in the re-roll since it missed a s/prune --worktrees/worktree prune/ in Documentation/git-checkout.txt.

>    I noticed GIT_CHECKOUT_NEW_WORKTREE environment variabl that does
>    not seem to be documented.  Is this something we still need?
>    The log message of 529fef20 (checkout: support checking out into
>    a new working directory, 2014-11-30) does not tell us much.

Yes, it's still used for the same purpose as before the conversion: as a private signal to the sub git-checkout invocation that it's operating on a new worktree. When defined, it sets the 'new_worktree_mode' flag in checkout.c, and there are still a few bits of code which apparently need to know about it. It would be nice to eliminate this special knowledge from checkout.c, however, I'm not yet familiar enough with the checkout code to determine if doing so is viable.

For the re-roll, I was planning on renaming it to GIT_NEW_WORKTREE_MODE or something (or add a private command-line option to checkout, but that may be overkill).