list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: "Ævar Arnfjörð Bjarmason" <>
To: Elijah Newren <>
Cc: "Gábor Farkas" <>,
	"Git Mailing List" <>
Subject: Re: git switch/restore, still experimental?
Date: Wed, 05 May 2021 13:09:47 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Tue, May 04 2021, Elijah Newren wrote:

> On Tue, May 4, 2021 at 3:36 AM Gábor Farkas <> wrote:
>> hi,
>> the "git switch" and "git restore" commands were released two years
>> ago, but the manpage still says "THIS COMMAND IS EXPERIMENTAL. THE
>> 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.


    # 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


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

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

  List information:

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

  git send-email \ \ \ \ \ \
    --subject='Re: git switch/restore, still experimental?' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this inbox:

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