[cmgriffing]

I feel like the value of changing from `git checkout -b` to `git switch -c` is not worth the cognitive overhead of making the change.

[kedean]

Not to mention the official docs for "switch" still state "THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE."

https://git-scm.com/docs/git-switch

[ghewgill]

Yes. This warning in the documentation (and the same warning for "git restore") is doing nothing to help the situation. I've had to put a stake in the ground on this SO answer: https://stackoverflow.com/a/215731/893

[epistasis]

> [At the time of writing, the git restore command has been marked as "experimental" for at least four years.]

Honestly I have not bothered to even learn switch or restore because of these warnings. If they keep them in after five years, then the commands might be removed in the next version, because clearly there's no champion behind them pushing them forward.

And the few times I have tried to learn what they do, I have not seen any benefit over my current knowledge. So why learn something that may go away and is not trusted even five years and many many versions after deployment?

[Izkata]

This goes well with my experience from svn where "svn switch" had a high-enough chance to screw up your checkout that everyone I know just had multiple checkouts instead.

[BizarreByte]

I felt that way about the master to main debacle, but some angry people online won anyway.

[disgruntledphd2]

The irritating thing about that is that the software git defaults to master, while GitHub defaults to main. I had a lot of confusion a few months back about that.

[two_cents]

You can set default branch name for your repositories in settings. Much more straightforward than in GitLab in my opinion.

[disgruntledphd2]

Yeah, I know that now but this hit me under time pressure and caused me muh confusion for a while.

[joshka]

I made that exact thought many years ago and came to the direct opposite conclusion. It was worth the cognitive overhead to make the change and I haven't looked back. Most of the time I'm just hitting aliases (from OMZ's git plugin) https://github.com/ohmyzsh/ohmyzsh/tree/master/plugins/git e.g.

    gsw  git switch
    gswc  git switch -c
    gswd  git switch $(git_develop_branch)
    gswm  git switch $(git_main_branch)

[imoreno]

Do people really type these out, instead of just making a bash alias?

[camtarn]

Used to have bash aliases, but nowadays I work on so many different machine, without my dotfiles present, that aliases seem kinda pointless. I'm a fast typist.

[dwaltrip]

I would wager that 90% of people using git don’t have bash aliases.

[g-b-r]

I would wager that above 90% (of those using command-line git) do, after at most a few weeks of heavy git usage

It takes no time to add some, and it's not necessary to put them online and synchronize them; it would be a no-brainer for me to add some manually, if I had to work on a new machine for more than a few minutes (and couldn't access my usual ones from it)

[moregrist]

Aliases have always been a double-edged sword.

They're shorter and let you be more efficient at common tasks.

They also tend to be personal and hard to share. Which can make it harder to explain what you’re doing to a coworker for pairing/debugging/training purposes. And you have to remember both the aliases and the underlying commands/options, at least enough to remember when you don’t want to use the alias.

I don’t find that I use git subcommands with a frequency that makes me want to alias them. It’s likely that different workflows lead to different optimizations.

[remram]

I was always using 'co' for checkout. Made the change to switch ('git s') and revert ('git r') and it has been pretty seemless. I do wish 'git reset' defaulted to --keep.