On Thu, Nov 3, 2022 at 9:07 PM Jacob Abel <jacobabel@xxxxxxxxxx> wrote: > While working with the worktree based git workflow, I realised that setting > up a new git repository required switching between the traditional and > worktree based workflows. Searching online I found a SO answer [1] which > seemed to support this and which indicated that adding support for this should > not be technically difficult. I've also found myself using an orphaned worktree on occasion, so I can see the value in supporting this use-case directly. In fact, the idea all along was that `git worktree add` would start with a small set of options but gain additional options over time as the need arose. It was foreseen in [1], for instance, that --orphan might one day be added. > This patchset has three parts: > * adding `-B` to the usage docs (noticed during dev and it seemed too small > to justify a separate submission) > * switching from `git reset --hard` to `git checkout` for worktree checkout > * adding orphan branch functionality (as is present in `git-checkout`) > to `git-worktree-add` 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. [1]: https://lore.kernel.org/git/1436573146-3893-11-git-send-email-sunshine@xxxxxxxxxxxxxx/ [2]: https://lore.kernel.org/git/1435640202-95945-1-git-send-email-sunshine@xxxxxxxxxxxxxx/ [3]: https://lore.kernel.org/git/1435969052-540-1-git-send-email-sunshine@xxxxxxxxxxxxxx/ [4]: https://lore.kernel.org/git/1436203860-846-1-git-send-email-sunshine@xxxxxxxxxxxxxx/ [5]: https://lore.kernel.org/git/1436573146-3893-1-git-send-email-sunshine@xxxxxxxxxxxxxx/ [6]: https://lore.kernel.org/git/1437034825-32054-1-git-send-email-sunshine@xxxxxxxxxxxxxx/ [7]: https://lore.kernel.org/git/1437174017-81687-1-git-send-email-sunshine@xxxxxxxxxxxxxx/ [8]: https://lore.kernel.org/git/xmqqh9physyu.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx/ [9]: https://lore.kernel.org/git/CAPig+cSBp-U_jC3fcPXkZQ6kEPh7TRs2bAwKYQGGTtoGR3UYeg@xxxxxxxxxxxxxx/ [10]: https://lore.kernel.org/git/20171129200451.16856-4-t.gummerer@xxxxxxxxx/ [11]: https://lore.kernel.org/git/20171129200451.16856-6-t.gummerer@xxxxxxxxx/ [12]: https://lore.kernel.org/git/01020153bcda5e6c-2bae9b68-6669-4f29-a512-136c42722001-000000@xxxxxxxxxxxxxxxxxxxxxxx/ [13]: https://lore.kernel.org/git/20180815205630.32876-1-gitter.spiros@xxxxxxxxx/
