On 22/11/04 12:33AM, Eric Sunshine wrote: > > 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.
