Re: [PATCH v8 3/4] worktree add: add --orphan flag

[Jacob Abel <jacobabel@nullpo.dev>]

On 23/01/19 04:18PM, Phillip Wood wrote:
> On 18/01/2023 22:40, Jacob Abel wrote:
> > [...]
> > Understood.
> >
> > I'm not entirely opposed to making this change to OPT_BOOL but I have to wonder
> > how often `--orphan` will actually be used by a given user and whether the
> > slightly shorter invocation will be used regularly.
> >
> > With the base `git worktree add $path`, the shorthand/DWYM makes sense as it's
> > used regularly but I don't see users working with `--orphan` outside of trying
> > to create the first branch in a repository.
>
> Your example use in the commit message shows the user using the same
> name for the branch and worktree. If that really is the likely use than
> I think we should make --orphan OPT_BOOL. If it is not the likely use
> perhaps you could update the commit message to show how you think it
> will be used.

The example in the commit message is mostly a trivial example to show the
change. I think whether someone uses the same name for the branch and worktree
depends on how they use the feature. At least personally, generally I name my
worktree based on either the relevant project/"hat" or using an "a/, b/, c/" or
"alpha/, beta/, gamma/" style.

So in my personal use, it'd look something like:

    git worktree add --orphan main alpha/

---

Or to occassionally break out a scratchpad that I may want to keep around for a
while but not actually integrate into the feature branch in it's current form.
This isn't really for code but rather so I can scratch out and document my logic
prior to doing a formal write up at the end of a given feature. Of course since
it doesn't make it into the main tree, when everything is written up, I can just
toss the branch and let gc take care of it.

This ends up looking like so:

    git worktree add --orphan scratch-1234-foobar-feature scratchpad/

And since `worktree add` only needs to be done once, I only do this the first
time I set up my dev environment on a machine. After that I can just use
`git switch --orphan` to create new scratchpad branches and `git switch` to
swap between existing scratchpads.

---

The first example I see as being the main use case (which could hopefully be
DWYMed eventually) and the latter example is a quirk of my admittedly niche
personal usecase for worktrees.

> > And I'd like that operation of creating the first branch in a repo to eventually
> > "just work" with the base command, i.e. `git worktree add main/`. The reason I
> > hadn't yet added that is because I've yet to figure out how to get it to work
> > without accidentally introducing potentially confusing situations and I didn't
> > want to hold up introducing the core functionality itself.
> >
> > Once that main use-case "just works", I don't see users utilising `--orphan`
> > except in very rare circumstances. Doubly so since the average user likely
> > shouldn't be using `--orphan` in most cases.
>
> This brings us back to the question that we discussed earlier of whether
> we need --orphan at all. If we can get the main use-case working without
> it we'd perhaps be better doing that rather than adding an option no one
> ends up using.

At least personally, I'd rather expose the option for users who may potentially
want it. I think it'd be useful regardless but in the same way `--orphan` is
currently useful in `git switch`, which is for very specific niche cases and
really only for power users rather than as a common tool everyday users are
expected to know.

And for the main use case, my concerns were:

1. If we DWYM and create a branch when there are no existing branches, what
about the case where a user sets up the repo but forgot to fetch. i.e. if a user
does:

    # Or instead of init --template, use some language's project init tool to
    # setup git hooks.
    % git init --bare --template <tmpldir> .git
    % git remote add origin <remote>
    % git worktree add main/

Should we just warn the user that they haven't fetched their remote yet while we
prepare the worktree?

2. Suppose we also check whether the remote has been fetched and the remote has
a branch matching the current branch name.

Should we fail (as it currently does on main) with an advise to try the command
`git worktree add main main` instead? Or should that command also "just work"

3. If we want to do the above, should it do this for all commands trying to
create a worktree until at least one real branch (with commits) exists in the
repo or should we only do this when the branch name matches the one defined in
`init.defaultBranch`?

> Best Wishes
>
> Phillip
>
> > [...]