From: Stefan Monnier <hidden> Date: 2021-01-06 16:17:50
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 checkout --orphan newbranch
git rm -rf .
git branch -D dummy
I wish I could just do something like:
git worktree add --orphan foo newbranch
instead,
Stefan
On Wed, Jan 6, 2021 at 8:21 AM Stefan Monnier [off-list ref] wrote:
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 checkout --orphan newbranch
git rm -rf .
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.
git branch -D dummy
I wish I could just do something like:
git worktree add --orphan foo newbranch
I think you mean
git worktree add --orphan newbranch foo
cd foo
Because (a) the option to --orphan is the name of the new branch, and
(b) you need the cd to be equivalent to the first sequence of
commands.
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.
From: Eric Sunshine <hidden> Date: 2021-01-06 20:02:11
On Wed, Jan 6, 2021 at 2:41 PM Elijah Newren [off-list ref] wrote:
On Wed, Jan 6, 2021 at 8:21 AM Stefan Monnier [off-list ref] wrote:
quoted
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.
On Wed, Jan 6, 2021 at 2:41 PM Elijah Newren [off-list ref] wrote:
quoted
On Wed, Jan 6, 2021 at 8:21 AM Stefan Monnier [off-list ref] wrote:
quoted
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.
quoted
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.
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 [off-list ref].
I'd tried crafting as simple worktree manually, and discovered that I
could get worktree_add() to create it rather easily by jumping past some
of the "commit exists?" checks.
@@ -414,18 +419,28 @@ static int add_worktree(const char *path, const char *refname,staticvoidprint_preparing_worktree_line(intdetach,constchar*branch,constchar*new_branch,-intforce_new_branch)+intforce_new_branch,+intorphan){if(force_new_branch){structcommit*commit=lookup_commit_reference_by_name(new_branch);-if(!commit)-printf_ln(_("Preparing worktree (new branch '%s')"),new_branch);-else+if(!commit){+if(orphan)+printf_ln(_("Preparing worktree (new orphan branch '%s')"),new_branch);+else+printf_ln(_("Preparing worktree (new branch '%s')"),new_branch);+}else{+if(orphan)+BUG("TODO");printf_ln(_("Preparing worktree (resetting branch '%s'; was at %s)"),new_branch,find_unique_abbrev(&commit->object.oid,DEFAULT_ABBREV));+}}elseif(new_branch){-printf_ln(_("Preparing worktree (new branch '%s')"),new_branch);+if(orphan)+printf_ln(_("Preparing worktree (new orphan branch '%s')"),new_branch);+else+printf_ln(_("Preparing worktree (new branch '%s')"),new_branch);}else{structstrbufs=STRBUF_INIT;if(!detach&&!strbuf_check_branch_ref(&s,branch)&&
@@ -486,6 +501,7 @@ static int add(int ac, const char **av, const char *prefix)OPT_BOOL('d',"detach",&opts.detach,N_("detach HEAD at named commit")),OPT_BOOL(0,"checkout",&opts.checkout,N_("populate the new working tree")),OPT_BOOL(0,"lock",&opts.keep_locked,N_("keep the new working tree locked")),+OPT_BOOL(0,"orphan",&opts.orphan,N_("new unparented branch")),OPT__QUIET(&opts.quiet,N_("suppress progress reporting")),OPT_PASSTHRU(0,"track",&opt_track,NULL,N_("set up tracking mode (see git-branch(1))"),
@@ -560,6 +580,8 @@ static int add(int ac, const char **av, const char *prefix)return-1;branch=new_branch;}elseif(opt_track){+if(opts.orphan)+BUG("TODO");die(_("--[no-]track can only be used if a new branch is created"));}
From: Eric Sunshine <hidden> Date: 2021-02-21 19:56:52
On Wed, Feb 17, 2021 at 8:26 PM Ævar Arnfjörð Bjarmason
[off-list ref] wrote:
On Wed, Jan 06 2021, Eric Sunshine wrote:
quoted
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 [off-list ref].
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 Wed, Feb 17, 2021 at 8:26 PM Ævar Arnfjörð Bjarmason
[off-list ref] wrote:
quoted
On Wed, Jan 06 2021, Eric Sunshine wrote:
quoted
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.
quoted
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 [off-list ref].
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.
From: Eric Sunshine <hidden> Date: 2021-02-22 23:07:28
On Mon, Feb 22, 2021 at 4:45 AM Ævar Arnfjörð Bjarmason
[off-list ref] wrote:
On Sun, Feb 21 2021, Eric Sunshine wrote:
quoted
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.
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.
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>".
So, I don't have any great answers at this time.
On Mon, Feb 22, 2021 at 4:45 AM Ævar Arnfjörð Bjarmason
[off-list ref] wrote:
quoted
On Sun, Feb 21 2021, Eric Sunshine wrote:
quoted
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.
quoted
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.
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.
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.
From: Eric Sunshine <hidden> Date: 2021-02-23 00:56:38
On Mon, Feb 22, 2021 at 7:17 PM Ævar Arnfjörð Bjarmason
[off-list ref] wrote:
On Tue, Feb 23 2021, Eric Sunshine wrote:
quoted
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.
quoted
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>`, and I
don't think it would work at all for git-worktree-add which has
additional <path> and <commitish> arguments (i.e. `git worktree add -b
<branch> --orphan <path> [<commitish>]`).
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`).
quoted
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.
On Mon, Feb 22, 2021 at 7:17 PM Ævar Arnfjörð Bjarmason
[off-list ref] wrote:
quoted
On Tue, Feb 23 2021, Eric Sunshine wrote:
quoted
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.
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...
quoted
quoted
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>`
Yeah, I think so. But I think for an option like that it would be more
obvious. I.e. we could say:
If "-b" or "-B" is provided a subsequent "--orphan" is a boolean.
We don't support the combination of the two now, so we could just
mandate that the order matters.
Anyway...
, and I don't think it would work at all for git-worktree-add which
has additional <path> and <commitish> arguments (i.e. `git worktree
add -b <branch> --orphan <path> [<commitish>]`).
...we can parse these options, whether it's easy or trivial with
parse-options.c is something I'd like to leave aside for now.
Right now I'm not intending to re-roll this patch, but maybe someone
else (or even me) will get to it sometime. I think it's more useful
if/when that happens to get people's take on whether this makes sense as
UI, not whether it's trivial with the current parse_options() API.
I think it's fairly easy to tease this behavior out of
parse_options(). Worse case we can do a pre-loop over argv and see if
both "--orphan" and "-b"/"-B" occur. if so parse it with "--orphan" as a
BOOL, otherwise STRING.
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`).
See https://lore.kernel.org/git/7vpqzlrmo4.fsf@alter.siamese.dyndns.org/
for past Junio arguing with his future self :)
I.e. the reason we had -B in the first place is because --force means
something else. We'd need "--force-ref-deletion
--force-work-tree-clobbering" or whatever, or "--force --force".
I like this lower/upper case convention. It started with "branch -D" in
ba65af9c1f6 (git-branch -d <branch>: delete unused branch., 2005-09-14),
but in checkout the --orphan option pre-dates -B. See 9db5ebf4022 (git
checkout: create unparented branch by --orphan, 2010-03-21) and
02ac98374ee (builtin/checkout: learn -B, 2010-06-24).
I don't think we're going to change how "branch -D" and "switch -C" work
at this point, so making things consistent with it makes sense.
quoted
quoted
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.
*nod*
quoted
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.
It's an obscure enough thing that I don't think anyone *really* cares. I
just wanted to find out if it not being a boolean was intentional, or a
historical accident we would consider fixing if there was further work
on it.