On 22/11/04 12:47AM, Jacob Abel wrote: > 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. Oops. I forgot to link the other thread. 1. https://lore.kernel.org/git/20221104035751.nnrfpvbqlqheb57k@phi/
