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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jul 1, 2015 at 12:53 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> From: Eric Sunshine <sunshine@xxxxxxxxxxxxxx>
>
> 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@xxxxxxxxxxxxxx>
> Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx>
> ---
>
>  * 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]