On Wed, Jul 1, 2015 at 12:53 PM, Junio C Hamano <[email protected]> wrote:
> From: Eric Sunshine <[email protected]>
>
> 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 <[email protected]>
> Signed-off-by: Junio C Hamano <[email protected]>
> ---
>
>  * 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).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to