From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Elijah Newren <newren@gmail.com>
Cc: "Gábor Farkas" <gabor.farkas@gmail.com>,
"Git Mailing List" <git@vger.kernel.org>
Subject: Re: git switch/restore, still experimental?
Date: Wed, 05 May 2021 13:09:47 +0200 [thread overview]
Message-ID: <877dkdwgfe.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <CABPp-BHBcjSQbkotrzwDtVRSC-qqjEyP4m=biY-0+=Jdg9ETQw@mail.gmail.com>
On Tue, May 04 2021, Elijah Newren wrote:
> On Tue, May 4, 2021 at 3:36 AM Gábor Farkas <gabor.farkas@gmail.com> wrote:
>>
>> hi,
>>
>> the "git switch" and "git restore" commands were released two years
>> ago, but the manpage still says "THIS COMMAND IS EXPERIMENTAL. THE
>> BEHAVIOR MAY CHANGE.".
>>
>> i'd love to use them, but this warning gives me pause, perhaps i
>> should wait until it stops being experimental, i worry that it might
>> change in behavior unexpectedly and cause problems for me.
>>
>> considering that they were released two years ago, could the
>> experimental-warning be removed now?
>>
>> thanks,
>> gabor
>
> This probably makes sense. The author of switch and restore isn't
> involved in the git project anymore. He decided to work on other
> things, which was and is a big loss for us. I think others (myself
> included) didn't know all the things that might have been in Duy's
> head that he wanted to verify were working well before marking this as
> good, but these two commands have generally been very well received
> and it has been a few years. Personally, I'm not aware of anything
> that we'd need or want to change with these commands.
I am.
I think it's quite confusing that "git switch" doesn't switch to a new
"doesnotexist" branch on something like:
git switch doesnotexist
But requires:
git switch -c doesnotexist
I mean, I see why. You don't want a typo of "master" as "maaster" to
create a new "maaster" branch, so really that's out. But it really
should be:
# -n or -N for --new / --new --force (the latter just in case of a
# race, and just for consistency)
git switch -n doesnotexist
The design choice of squatting on "-c" for "create" as opposed to "copy"
as implemented in 52d59cc6452 (branch: add a --copy (-c) option to go
with --move (-m), 2017-06-18) has the knock-on effect that we can't
mirror the "git branch" UI. I.e. to make "switch" be "branch with
checkout" for these common cases.
I.e.:
# copies a branch and config from old->new (or -C for --force)
git branch -c old new
# just creates a "new" starting at "old", but no copying!
git switch -c new old
And:
# Moves a branch (or -M for --force)
git branch -m old new
That last one we can't have either because "switch" squats on "-m" for
"--merge", which I daresay is a much more obscure use-case not deserving
of a short option than "rename and switch to".
In summary, I think it should be changed to act like this:
|---------------------------+------------------------+---------------------------|
| What | Now | New |
|---------------------------+------------------------+---------------------------|
| Switch | git switch existing | git switch existing |
| Error | git switch nonexisting | <no change (errors)> |
| Switch with --merge | git switch -m branch | git switch --merge branch |
| Create | git switch -c new | git switch -n new |
| Create from existing | N/A | git switch -c new [<old>] |
| Move & switch to existing | N/A | git switch -m new [<old>] |
|---------------------------+------------------------+---------------------------|
One thing that sucks about my proposal is that it would be squatting on
"-n" for "new" as opposed to "--dry-run".
It would be nice if switch/checkout learned a --dry-run mode, I don't
like e.g. "fetch" having a "-n" that isn't "--dry-run", but can't think
of a better option in the switch case.
In its current state I find "git switch" to be unusable. That sounds
like dramatic hyperbole, but I'm serious.
As much as I applaud the effort to move git's UI forward in this
particular case it's doomed to be only skin-deep because of that
unfortunate initial design choice of sort-of acting like "git branch
with checkout", but squatting on "-c/-C/-m".
I.e. to me the ideal end state would be to deprecate (or at least
warn/discourage) the "git branch -m" case where it does its own checkout
(but for nothing else), and to make "git switch" a "branch with
checkout" with the same -c/-C/-m/-M semantics, just also with a -n/-N
for "create first".
So at the end of the day you still have to use "git branch" for these
common (at least for me) operations of copy/move, *and* maintain a
mental model that "-c" means "xyz" here, but "abc" there.
The "switch" command also solves the very real problem (and I believe
this was the main motivation) of not knowing beforehand if "checkout"
will interpret your "foo" as a file, a branch or whatever. I find it
easier to solve that (I'm aware that it's not a 100% solution) by
consistently using "--" to escape path names, rather than needing to
mentally model the difference in "-c/-C/-m" behavior.
next prev parent reply other threads:[~2021-05-05 11:47 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-04 10:32 git switch/restore, still experimental? Gábor Farkas
2021-05-04 19:54 ` Felipe Contreras
2021-05-05 3:46 ` Elijah Newren
2021-05-05 4:01 ` Eric Sunshine
2021-05-05 11:09 ` Ævar Arnfjörð Bjarmason [this message]
2021-05-05 17:46 ` Felipe Contreras
2021-05-05 19:26 ` Sergey Organov
2021-05-05 19:48 ` Sergey Organov
2021-05-06 1:39 ` Junio C Hamano
2021-05-06 15:19 ` Sergey Organov
2021-05-06 10:05 ` Ævar Arnfjörð Bjarmason
2021-05-06 14:29 ` Sergey Organov
2021-05-06 2:16 ` Junio C Hamano
2021-05-06 10:02 ` Ævar Arnfjörð Bjarmason
2021-05-10 11:04 ` Ævar Arnfjörð Bjarmason
2021-05-10 18:27 ` Junio C Hamano
2021-05-06 11:00 ` Felipe Contreras
2021-05-06 15:26 ` Ævar Arnfjörð Bjarmason
2021-05-06 21:55 ` Felipe Contreras
2021-05-10 10:58 ` Ævar Arnfjörð Bjarmason
2021-05-11 7:15 ` Felipe Contreras
2021-05-05 14:18 ` Johannes Schindelin
2021-05-05 14:26 ` Randall S. Becker
2021-05-06 1:15 ` Junio C Hamano
2021-05-05 17:52 ` Felipe Contreras
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=877dkdwgfe.fsf@evledraar.gmail.com \
--to=avarab@gmail.com \
--cc=gabor.farkas@gmail.com \
--cc=git@vger.kernel.org \
--cc=newren@gmail.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 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 NNTP newsgroup(s).