New orphan worktree?

>
> On Wed, Jan 6, 2021 at 8:18 AM Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> > create a new orphan branch with a new matching worktree
>
> There's a much shorter sequence
>
>     git worktree add -b new new $(git commit-tree `git mktree <&-` <&-)
>     rm .git/refs/heads/new

>
> I use worktrees extensively (and rarely use `git checkout`).
>
> When I need to create a new orphan branch with a new matching worktree
> (or submodule), I find it is quite cumbersome.  I basically have
> to do something like:
>
>     git worktree add -b dummy foo
>     cd foo

>     git branch -D dummy
>
> I wish I could just do something like:
>
>     git worktree add --orphan foo newbranch

> On Wed, Jan 6, 2021 at 8:21 AM Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> > I wish I could just do something like:
> >
> >     git worktree add --orphan foo newbranch
>
> Out of curiosity, why are you frequently creating orphan branches?
> Such an option would drop the number of commands you need to run from
> four down to two, but I'm surprised this would come up enough to
> matter enough to do much more than create a personal git alias for it.

> On Wed, Jan 6, 2021 at 2:41 PM Elijah Newren <newren@gmail.com> wrote:
>> On Wed, Jan 6, 2021 at 8:21 AM Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> > I wish I could just do something like:
>> >
>> >     git worktree add --orphan foo newbranch
>>
>> Out of curiosity, why are you frequently creating orphan branches?
>> Such an option would drop the number of commands you need to run from
>> four down to two, but I'm surprised this would come up enough to
>> matter enough to do much more than create a personal git alias for it.
>
> I'm also curious about a use-case in which orphaned branches are used
> so frequently.
>
> Nevertheless, I'm not at all opposed to seeing an --orphan option
> added to `git worktree add`. In fact, --orphan has been on the
> radar[1] from the very beginning. Although the original implementation
> of `git worktree add` mimicked a small set of options from
> git-checkout, the plan all along was to mimic additional options from
> git-checkout as demand for them arose, and several such options have
> already been added.
>
>> Yeah, checkout --orphan is broken.  You should use switch --orphan,
>> which doesn't require the extra 'git rm -rf .' step.  That bit is
>> definitely cumbersome.
>
> Yep, when/if --orphan is added to `git worktree add`, it should mimic
> the behavior of --orphan in git-switch rather than git-checkout.

> On Wed, Jan 06 2021, Eric Sunshine wrote:
> > Yep, when/if --orphan is added to `git worktree add`, it should mimic
> > the behavior of --orphan in git-switch rather than git-checkout.
>
> How would a mode for "worktree add --orphan" that mimics checkout rather
> than switch even look like? The "checkout --orphan" special-case is
> because we retain the index, so you need to "git rm -rf .".
>
> But with worktrees we always get a new index, so AFAICT the only way to
> make it work like "checkout" would be to have it be the only mode that
> copies over the current worktree's index.

> In any case I implemented a rough version of this today, and it uses the
> "switch" semantics. I only discovered this ML thread afterwards.
>
> It's surely full of bugs, and needs test work (see all the BUG(...)),
> but if someone's interested in taking it further all it should need is
> some more tests & dealing with the edge cases of incompatible options
> etc. It's Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>.

> On Wed, Feb 17, 2021 at 8:26 PM Ævar Arnfjörð Bjarmason
> <avarab@gmail.com> wrote:
>> On Wed, Jan 06 2021, Eric Sunshine wrote:
>> > Yep, when/if --orphan is added to `git worktree add`, it should mimic
>> > the behavior of --orphan in git-switch rather than git-checkout.
>>
>> How would a mode for "worktree add --orphan" that mimics checkout rather
>> than switch even look like? The "checkout --orphan" special-case is
>> because we retain the index, so you need to "git rm -rf .".
>>
>> But with worktrees we always get a new index, so AFAICT the only way to
>> make it work like "checkout" would be to have it be the only mode that
>> copies over the current worktree's index.
>
> I hadn't actually put any thought into it aside from (1) `--orphan`
> being a likely candidate for `git worktree add`, and (2) my uses of
> orphan branches always involved `git checkout --orphan && git rm -rf
> .`. I never got as far as thinking about the actual implementation.
>
>> In any case I implemented a rough version of this today, and it uses the
>> "switch" semantics. I only discovered this ML thread afterwards.
>>
>> It's surely full of bugs, and needs test work (see all the BUG(...)),
>> but if someone's interested in taking it further all it should need is
>> some more tests & dealing with the edge cases of incompatible options
>> etc. It's Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>.
>
> Thanks. This looks like a good start.
>
>> +test_expect_success '"add" worktree orphan branch' '
>> +       git worktree add --orphan -b orphan here-orphan &&
>
> 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.

> 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>

> 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.

> 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).

> Eric Sunshine <sunshine@sunshineco.com> writes:
> > 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).
>
> FWIW, as I personally view that branch -d/-D, checkout -b/-B, and
> switch -c/-C were all mistakes (they should have been -d, -b and -c
> with and without --force, respectively), I find the combination of
> "--force --orphan" a reasonable way forward.

> 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.

> 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.

> 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>".

> On Tue, Feb 23 2021, Eric Sunshine wrote:
> > 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.

> > 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?

> On Mon, Feb 22, 2021 at 7:17 PM Ævar Arnfjörð Bjarmason
> <avarab@gmail.com> wrote:
>> On Tue, Feb 23 2021, Eric Sunshine wrote:
>> > 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)
>
> I see where you're coming from in viewing --orphan as a modifier of
> branch creation rather than as a branch-creation option itself.
> However, as far as UI is concerned, that ship sailed a long time ago,
> I suppose.

>> > 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.
>
> I haven't dived into this stuff in a long time, but I'm having trouble
> convincing myself that it would work out as intended. If I'm reading
> PARSE_OPT_LASTARG_DEFAULT correctly, `git switch -b <branch> --orphan`
> would not be the same as `git switch --orphan -b <branch>`

> Anyhow, as I responded elsewhere to Junio, my present leaning is
> toward -b, -B, --orphan all being mutually-exclusive branch-creation
> options, each taking a <branch> argument -- just like they are in
> git-checkout and git-switch (-c/-C, in this case) -- and allowing
> --force to overwrite an existing branch (in which case, -B can be
> viewed as shorthand for `--force -b`).

>> > 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?
>
> Um, yes, I meant git-checkout everywhere I wrote git-branch. Sorry for
> the confusion.

>> 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.
>
> I'm having trouble wrapping my brain around this statement.

>> I see where you're coming from in viewing --orphan as a modifier of
>> branch creation rather than as a branch-creation option itself.
>> However, as far as UI is concerned, that ship sailed a long time ago,
>> I suppose.
>
> Not really, I think we can have a new-style of it and just say:
>
>     It is also possible to provide `--orphan <branch-name>`, but
>     supplying it as an option to `-[cC]` as `-[cC] <branch-name>
>     --orphan` is preferred these days.
>
> Whether we should is another matter, see below...

>>> 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.
>>
>> I'm having trouble wrapping my brain around this statement.
>
> I mean I'd rather not have an --orphan mode that works like -B (as
> opposed to -b) at all instead of having one that's "--orphan
> --force-ref-deletion" or whatever.

> Sidenote:
>
> Yeah, checkout --orphan is broken.  You should use switch --orphan,
> which doesn't require the extra 'git rm -rf .' step.  That bit is
> definitely cumbersome.

> On Wed, Jan 6, 2021 at 1:32 PM Junio C Hamano <gitster@pobox.com> wrote:
>> a need to have multiple unrelated line of histories in a single
>> repository may not be there, even though a desire to do so might
>> exist.  What is done with these unrelated histories that record
>> unrelated contents [*1*]?
>
> Git itself is an example of other reasons for carrying disjoint dags as a
> set of related histories.

>> not a good example to support the use of the "--orphan" option.
> I agree with that part, slathering infrastructure and abstractions on
> oneliners (okay, twoliners) is suspect in my book. worktree add,
> symoblic ref (really, no need to get lowlevel there, checkout --orphan
> does it) done. Tag an empty commit and the sequence gets closer
> to a legit oneliner
>
>     git worktree add foo empty; git -C foo checkout --orphan newbranch