Re: [PATCH 0/4] worktree: Support `--orphan` when creating new worktrees

[Eric Sunshine <sunshine@sunshineco.com>]

On Thu, Nov 3, 2022 at 9:07 PM Jacob Abel <jacobabel@nullpo.dev> 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@sunshineco.com/
[2]: https://lore.kernel.org/git/1435640202-95945-1-git-send-email-sunshine@sunshineco.com/
[3]: https://lore.kernel.org/git/1435969052-540-1-git-send-email-sunshine@sunshineco.com/
[4]: https://lore.kernel.org/git/1436203860-846-1-git-send-email-sunshine@sunshineco.com/
[5]: https://lore.kernel.org/git/1436573146-3893-1-git-send-email-sunshine@sunshineco.com/
[6]: https://lore.kernel.org/git/1437034825-32054-1-git-send-email-sunshine@sunshineco.com/
[7]: https://lore.kernel.org/git/1437174017-81687-1-git-send-email-sunshine@sunshineco.com/
[8]: https://lore.kernel.org/git/xmqqh9physyu.fsf@gitster.dls.corp.google.com/
[9]: https://lore.kernel.org/git/CAPig+cSBp-U_jC3fcPXkZQ6kEPh7TRs2bAwKYQGGTtoGR3UYeg@mail.gmail.com/
[10]: https://lore.kernel.org/git/20171129200451.16856-4-t.gummerer@gmail.com/
[11]: https://lore.kernel.org/git/20171129200451.16856-6-t.gummerer@gmail.com/
[12]: https://lore.kernel.org/git/01020153bcda5e6c-2bae9b68-6669-4f29-a512-136c42722001-000000@eu-west-1.amazonses.com/
[13]: https://lore.kernel.org/git/20180815205630.32876-1-gitter.spiros@gmail.com/