git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: New orphan worktree?

From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date
Feb 23, 2021, 00:17 UTC
Message-ID
<87czwr8wou.fsf@evledraar.gmail.com>
In-Reply-To
<CAPig+cSkL+5otKUWwm=CLaRR+j71wW61U7LWtmuUHO+7bZaY_g@mail.gmail.com>
On Tue, Feb 23 2021, Eric Sunshine wrote:
Show 46 quoted lines
> On Mon, Feb 22, 2021 at 4:45 AM Ævar Arnfjörð Bjarmason
> <avarab@gmail.com> wrote:
>> On Sun, Feb 21 2021, Eric Sunshine wrote:
>> > Rather than making --orphan a boolean flag, we'd probably want to
>> > mirror the behavior of the other commands and have <branch> be an
>> > argument consumed by --orphan:
>> >
>> >     git worktree add --orphan <branch> <path>
>> >
>> > That would make --orphan, -b, and -B mutually exclusive, much like
>> > they are for git-checkout, and much like -c, -C, and --orphan are
>> > mutually exclusive for git-switch.
>>
>> I see now (but didn't before, I haven't really used "switch" before)
>> that that's how it works.
>>
>> But that doesn't seem to make much sense as a UI, maybe I'm missing
>> something but how do you:
>>
>>     git switch --orphan existing-branch
>>
>> Just like you can:
>>
>>     git switch -C existing-branch <start-point>
>
> When responding to your initial email, I noticed this same shortcoming
> of --orphan in both git-branch and git-switch, and assumed that's why
> you made it a boolean in combination with -b/-B in "git worktree add".
> Before writing that email, I did put a bit of thought into how one
> might support a "force" mode but didn't include my thoughts in the
> message.
>
>> It's actually this exact use-case that prompted me to write the --orphan
>> patch. I wanted to create a "meta" orphan branch in my git.git, but had
>> an existing local "meta" (from Jeff King) that I'd happened to have
>> checked out long ago which I first needed to "git branch -D".
>>
>> Wouldn't it make more sense for a feature like this & back-compat to
>> start with switch's "--orphan" implying "-c", but you could also supply
>> "--orphan -C" instead? And in worktree have -b and -B work like they do
>> for other branches.
>
> I'm not sure I follow. In git-switch, --orphan does not imply -c even
> though --orphan also creates a new branch (thus seems to work similar
> to -c); it is nevertheless mutually-exclusive with -c and -C. The same
> goes for --orphan in git-branch.

I think we're on the same page with regards to what I meant. I.e. I don't see how it makes sense to conflate the type of branch we want (orphan or not orphan) with whether we want to clobber that branch or not (switch -c or -C, or worktree -b or -B)

> As far as combining --orphan and -C (or -c), I'm not sure how we would
> arrange that using the existing parse_options() mechanism. It seems
> too magical and has potential for weird corner cases.

Isn't it just having --orphan be an OPTION_STRING with PARSE_OPT_LASTARG_DEFAULT. I.e. to support:

    git switch -b branch --orphan
    git switch -B branch --orphan
    git switch --orphan branch
And:
    git worktree add -b branch --orphan
    git worktree add -B branch --orphan
I didn't test it, just skimmed the code.
Show 7 quoted lines
> Since git-worktree doesn't yet support --orphan, we certainly have
> more leeway and could go with your proposal of having --orphan be
> boolean and always requiring it to be used in conjunction with -b/-B.
> However, I'm quite hesitant to take that approach since it breaks with
> existing precedent in git-branch and git-switch, in which case
> --orphan takes its own argument (<branch>) and is mutually-exclusive
> with -b/-B/-c/-C.
In git-branch? Isn't it only git [checkout|switch] that takes --orphan?

But yeah, I agree that it makes sense for "worktree add" to be consistent with "switch". I was just wondering if we couldn't fix what seems to me to be a small options UI issue while we're at it.

Show 11 quoted lines
> When I was pondering the issue before writing my original response,
> two thoughts came to mind. (1) "git worktree add --force --orphan
> <branch>" would be one way to make your case work; (2) given how
> infrequently --orphan is used, we just punt and require people to
> first use "git branch -D <branch>" if necessary (which has been the
> status-quo for git-branch and git-switch). The latter thought is
> superficially tempting, though it doesn't help in automation
> situations since "git branch -D <branch>" errors out if <branch>
> doesn't exist, so a script would first have to check for existence of
> <branch> before attempting to delete it prior to using "git worktree
> add --orphan <branch>".

I think not having a -B or -C equivalent at all would be preferrable to having a --force special-case just to work around the lack of it for --orphan.

Previous: Eric SunshineNext: Eric Sunshine
Message 13 of 22 in “New orphan worktree?”
  1. Stefan MonnierJan 6, 2021
  2. Jim HillJan 6, 2021
  3. Elijah NewrenJan 6, 2021
  4. Jim HillJan 6, 2021
  5. Elijah NewrenJan 6, 2021
  6. Eric SunshineJan 6, 2021
  7. Ævar Arnfjörð BjarmasonFeb 18, 2021
  8. Eric SunshineFeb 21, 2021
  9. Ævar Arnfjörð BjarmasonFeb 22, 2021
  10. Eric SunshineFeb 22, 2021
  11. Junio C HamanoFeb 22, 2021
  12. Eric SunshineFeb 23, 2021
  13. Ævar Arnfjörð BjarmasonFeb 23, 2021
  14. Eric SunshineFeb 23, 2021
  15. Ævar Arnfjörð BjarmasonFeb 23, 2021
  16. Junio C HamanoFeb 23, 2021
  17. Junio C HamanoJan 6, 2021
  18. Jim HillJan 6, 2021
  19. Junio C HamanoJan 6, 2021
  20. Jim HillJan 6, 2021
  21. Stefan MonnierJan 6, 2021
  22. Stefan MonnierJan 6, 2021

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.