Eric Sunshine <sunsh...@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"? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
