git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Eric Sunshine <sunshine@sunshineco.com>,
	Elijah Newren <newren@gmail.com>,
	Stefan Monnier <monnier@iro.umontreal.ca>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: New orphan worktree?
Date: Tue, 23 Feb 2021 10:14:06 -0800	[thread overview]
Message-ID: <xmqq7dmy4pox.fsf@gitster.g> (raw)
In-Reply-To: <87a6rv82n3.fsf@evledraar.gmail.com> ("Ævar Arnfjörð Bjarmason"'s message of "Tue, 23 Feb 2021 12:06:08 +0100")

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

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

We cannot affored to give it a short-and-sweet "-[oO]", but if we
could, we probably would have, and that would have made the UI
consistent, at least (in other words, I'd see the act of creating an
"orphan" branch something distinct from creation of a normal
branch).

"You can treat --orphan as a standalone and distinct request to
create this specific kind of branch, or you can treat as if it is
just a modifier to specify which kind of branch, and -c/-C is still
used to ask for creation or forced update" does not sound like a
very end-user friendly explanation, at least to me.  Extra choices
that do not make a real difference invites "so, which should I
use?", a question they do not have to ask.

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

If you are saying that we should just have

    -c/-b/--orphan
    -c/-b/--orphan --force
    -C/-B (synonym for -c/-b --force)

then I fully agree.  I think the uppercase ones (and "git branch -d/-D")
were mistakes and should have used --force instead.

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

  reply	other threads:[~2021-02-23 18:16 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-06 16:17 New orphan worktree? Stefan Monnier
2021-01-06 17:00 ` Jim Hill
2021-01-06 19:48   ` Elijah Newren
2021-01-06 20:33     ` Jim Hill
2021-01-06 19:40 ` Elijah Newren
2021-01-06 20:01   ` Eric Sunshine
2021-02-18  1:26     ` Ævar Arnfjörð Bjarmason
2021-02-21 19:55       ` Eric Sunshine
2021-02-22  9:44         ` Ævar Arnfjörð Bjarmason
2021-02-22 23:06           ` Eric Sunshine
2021-02-22 23:59             ` Junio C Hamano
2021-02-23  0:33               ` Eric Sunshine
2021-02-23  0:17             ` Ævar Arnfjörð Bjarmason
2021-02-23  0:55               ` Eric Sunshine
2021-02-23 11:06                 ` Ævar Arnfjörð Bjarmason
2021-02-23 18:14                   ` Junio C Hamano [this message]
2021-01-06 21:29   ` Junio C Hamano
2021-01-06 22:01     ` Jim Hill
2021-01-06 22:15       ` Junio C Hamano
2021-01-06 22:25         ` Jim Hill
2021-01-06 22:56           ` Stefan Monnier
2021-01-06 22:01     ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqq7dmy4pox.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=newren@gmail.com \
    --cc=sunshine@sunshineco.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).