From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: Elijah Newren <newren@gmail.com>,
Stefan Monnier <monnier@iro.umontreal.ca>,
Git Mailing List <git@vger.kernel.org>
Subject: Re: New orphan worktree?
Date: Mon, 22 Feb 2021 10:44:55 +0100 [thread overview]
Message-ID: <87ft1o8mi0.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <CAPig+cQ9oqMWjBkyRt-SQFuyfAGkMu1J-U6ZCCJqeL0a_3ynkw@mail.gmail.com>
On Sun, Feb 21 2021, Eric Sunshine wrote:
> 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.
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.
next prev parent reply other threads:[~2021-02-22 9:46 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 [this message]
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
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ft1o8mi0.fsf@evledraar.gmail.com \
--to=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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.