Re: [PATCH 0/4] worktree: Support `--orphan` when creating new worktrees
- From
Jacob Abel <jacobabel@nullpo.dev>
- Date
- Nov 4, 2022, 04:47 UTC
- Message-ID
- <20221104044653.c4qa32ojwculq6bl@phi>
- In-Reply-To
- <CAPig+cQV7Udz4mn2V7P8ZsVoFiCRMJwNiG23GL6NAOxM4iuzmw@mail.gmail.com>
On 22/11/04 12:33AM, Eric Sunshine wrote:
Show 23 quoted lines
> > I'm pretty sure that we don't want to go the route of using > heavyweight and heavily-featured `git checkout` as a substitute for > lightweight `git reset --hard`. In fact, worktree functionality > started life as a special checkout mode invoked by `git checkout > --to`. A good deal of work[2][3][4] went into extracting that > functionality to a standalone `git worktree add` command, and > eventually ridding `git worktree add` of its unfortunate dependency > upon `git checkout` as a backend[5][6][7], and ridding `git checkout` > of its ugly intimate specialized knowledge of a newly-crafted > worktree. > > The key motivation for rejecting `git checkout` as backend and > migrating to `git reset --hard` came from Junio[8][9], and I trust > that his observations are still pertinent. > > So, rather than swapping out `git reset --hard` in favor of `git > checkout`, we probably want to stick with the already-established > approach of adding the necessary machinery to `git worktree add` > itself (or by refactoring `git checkout` machinery to be reusable), > just as we did for other `git worktree` options which have `git > checkout` counterparts, such as --track[10], --guess-remote[11], > --[no]-checkout[12], --quiet[13], etc.
I agree. I appreciate you sharing the history as it makes sense now why it is this way in particular.
I think I found an alternative which was mentioned over in another reply [1] (running `git symbolic-ref` after running `git reset`) and I'm going to try implementing that for v2 and hope it doesn't introduce any complications.