public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox•com>
To: Eric Sunshine <sunshine@sunshineco•com>
Cc: git@vger•kernel.org, Duy Nguyen <pclouds@gmail•com>,
	Mark Levedahl <mlevedahl@gmail•com>,
	Mikael Magnusson <mikachu@gmail•com>
Subject: Re: [PATCH v3 18/23] checkout: retire --to option
Date: Mon, 06 Jul 2015 12:41:13 -0700	[thread overview]
Message-ID: <xmqqh9physyu.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <1436203860-846-19-git-send-email-sunshine@sunshineco.com> (Eric Sunshine's message of "Mon, 6 Jul 2015 13:30:55 -0400")

Eric Sunshine <sunshine@sunshineco•com> writes:

> Now that "git worktree add" has achieved user-facing feature-parity with
> "git checkout --to", retire the latter.
>
> Move the actual linked worktree creation functionality,
> prepare_linked_checkout() and its helpers, verbatim from checkout.c to
> worktree.c.
>
> This effectively reverts changes to checkout.c by 529fef2 (checkout:
> support checking out into a new working directory, 2014-11-30) with the
> exception of merge_working_tree() and switch_branches() which still
> require specialized knowledge that a the checkout is occurring in a
> newly-created linked worktree (signaled to them by the private
> GIT_CHECKOUT_NEW_WORKTREE environment variable).


I do not quite understand why we still need the hidden environment
variable.  Is this a sign that the implementation is shared too much
between unrelated codepaths (or to put it another way, perhaps API
functions that are not best fit are being used)?

Stepping back a bit, with or without the new "linked worktree"
feature, when you came across a repository whose working tree does
not have any file (i.e. somebody ran "git ls-files | xargs rm"), you
do not know and care what is in .git/index right now, you do not
know and care what branch its .git/HEAD points at, but you *do* know
what branch you want to be on (or where you want its HEAD detached
at), what would be the command you would use?

The state immediately after a new worktree is constructed by
populating /path/main/.git/worktrees/test-next/ and pointing it from
/path/other/test-next/.git but before the index or the files under
/path/other/test-next/ are populated is exactly that situation, no?
Wouldn't "symbolic-ref HEAD the-branch-i-want" (or "update-ref HEAD
the-commit-i-want" in the detached case) followed by "reset --hard"
the more natural thing to use, instead of merge-working-tree and
switch-branches that are implementation details of "checkout"?

  reply	other threads:[~2015-07-06 19:41 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-06 17:30 [PATCH v3 00/23] replace "checkout --to" with "worktree add" Eric Sunshine
2015-07-06 17:30 ` [PATCH v3 01/23] Documentation/git-checkout: fix incorrect worktree prune command Eric Sunshine
2015-07-06 17:30 ` [PATCH v3 02/23] Documentation/git-worktree: associate options with commands Eric Sunshine
2015-07-06 17:30 ` [PATCH v3 03/23] Documentation: move linked worktree description from checkout to worktree Eric Sunshine
2015-07-06 17:30 ` [PATCH v3 04/23] Documentation/git-worktree: add BUGS section Eric Sunshine
2015-07-06 17:30 ` [PATCH v3 05/23] Documentation/git-worktree: split technical info from general description Eric Sunshine
2015-07-06 17:30 ` [PATCH v3 06/23] Documentation/git-worktree: add high-level 'lock' overview Eric Sunshine
2015-07-06 17:30 ` [PATCH v3 07/23] Documentation/git-worktree: add EXAMPLES section Eric Sunshine
2015-07-06 17:30 ` [PATCH v3 08/23] checkout: fix bug with --to and relative HEAD Eric Sunshine
2015-07-06 17:30 ` [PATCH v3 09/23] checkout: relocate --to's "no branch specified" check Eric Sunshine
2015-07-06 17:30 ` [PATCH v3 10/23] checkout: prepare_linked_checkout: drop now-unused 'new' argument Eric Sunshine
2015-07-06 17:30 ` [PATCH v3 11/23] checkout: make --to unconditionally verbose Eric Sunshine
2015-07-06 17:30 ` [PATCH v3 12/23] checkout: drop 'checkout_opts' dependency from prepare_linked_checkout Eric Sunshine
2015-07-06 17:30 ` [PATCH v3 13/23] worktree: introduce "add" command Eric Sunshine
2015-07-06 17:30 ` [PATCH v3 14/23] worktree: add --force option Eric Sunshine
2015-07-06 17:30 ` [PATCH v3 15/23] worktree: add --detach option Eric Sunshine
2015-07-06 17:30 ` [PATCH v3 16/23] worktree: add -b/-B options Eric Sunshine
2015-07-06 17:30 ` [PATCH v3 17/23] tests: worktree: retrofit "checkout --to" tests for "worktree add" Eric Sunshine
2015-07-06 17:30 ` [PATCH v3 18/23] checkout: retire --to option Eric Sunshine
2015-07-06 19:41   ` Junio C Hamano [this message]
2015-07-07  7:08     ` Eric Sunshine
2015-07-08 16:58       ` Junio C Hamano
2015-07-06 17:30 ` [PATCH v3 19/23] checkout: require worktree unconditionally Eric Sunshine
2015-07-06 17:30 ` [PATCH v3 20/23] worktree: extract basename computation to new function Eric Sunshine
2015-07-06 17:30 ` [PATCH v3 21/23] worktree: add: make -b/-B default to HEAD when <branch> is omitted Eric Sunshine
2015-07-06 17:30 ` [PATCH v3 22/23] worktree: add: auto-vivify new branch " Eric Sunshine
2015-07-06 19:19   ` Junio C Hamano
2015-07-07  1:33     ` Eric Sunshine
2015-07-07 16:10       ` Junio C Hamano
2015-07-06 17:31 ` [PATCH v3 23/23] checkout: retire --ignore-other-worktrees in favor of --force Eric Sunshine
2015-07-06 19:40   ` Junio C Hamano
2015-07-07  8:24     ` Eric Sunshine
2015-07-07  9:41       ` Eric Sunshine
2015-07-07 16:20         ` Junio C Hamano
2015-07-07 23:10           ` Eric Sunshine
2015-07-08  0:43     ` Mark Levedahl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqh9physyu.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox$(echo .)com \
    --cc=git@vger$(echo .)kernel.org \
    --cc=mikachu@gmail$(echo .)com \
    --cc=mlevedahl@gmail$(echo .)com \
    --cc=pclouds@gmail$(echo .)com \
    --cc=sunshine@sunshineco$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox