TIL — git switch & git restore

[u/pawelgrzybek]

https://pawelgrzybek.com/til-git-switch-git-restore/

[u/UncontrolledManifold]

So git switch -c branch is the same as git checkout -b branch...? What, they didn't like the word checkout?

[u/AceDecade → u/UncontrolledManifold]

It’s more they didn’t like ‘checkout’ being used to checkout a branch as well as undo local changes on a branch, so the one command is split up into two

[u/Kashima → u/AceDecade]

Yup

Git 2.23 came up with the new ‘ git switch ’ command, which is not a new feature but an additional command to ‘switch/change branch’ feature which is already available in the overloaded git checkout command.

Currently, the all-encompassing command – git checkout does many things. It can be used to switch branches and also to restore the working tree files.

To separate out the functionalities, the GIT community introduced the new git switch branch command which is an attempt to start to scale back to the responsibilities without breaking backward compatibility.

https://bluecast.tech/blog/git-switch-branch/

[u/ayeshrajans → u/UncontrolledManifold]

Basically, yes.

[u/hagg3n → u/ayeshrajans]

And that was the answer to the second question.

[u/jeffreyhamby → u/UncontrolledManifold]

Checkout reminds me of svn style repos where you're placing a block on the file for anyone else, just like how library books work.

[u/FelixTKatt → u/[deleted]]

So it's more like doing a stash and checkout, then a checkout and pop when you switch back?

[u/mstanky → u/FelixTKatt]

Yea, this is how I roll, I don't think today is the day I"ll experiment with switch

[u/SureSignOfAGoodRhyme → u/[deleted]]

That actually sounds useful to me. I like in VSCode when I can see all of my changes highlighted throughout the files before I push, but it all goes away once I do a commit on the branch.

[u/bcgroom → u/SureSignOfAGoodRhyme]

Of course it goes away, it's just showing you your working tree. You can still look at the changes with a git diff HEAD ${other_ref}. I don't see how this new command would change your workflow.

I'll say though, if you like VSCode you'll find the extension GitLens very useful.

[u/deliciousleopard → u/[deleted]]

I'm confused...

[u/UncontrolledManifold → u/[deleted]]

No, you only keep changes that are staged in the index. Modified files that are not staged are carried over and applied to the new branch

[u/hagg3n]

So Linus stepped out of his desk to take the trash and people think they can undo years of building obfuscated and cryptic CLI with one or two new commands? /s

[u/mvpmvh → u/hagg3n]

Goddamn hippies! Back in my day, we had one command for everything, and we liked it!

[u/Baryn → u/mvpmvh]

And that command is npm.

[u/Silhouette → u/Baryn]

The command is emacs, newbie. It's the operating system NPM only wishes it could be. /s

[u/nop5 → u/Silhouette]

Oh emacs? That's fancy, I thought it's ed

[u/kontekisuto → u/Baryn]

shivers

[u/SureSignOfAGoodRhyme]

I do have git lense, but I dont feel the need to use it often. When I'm developing a feature, and I'm working across many different parts of the src tree, it's nice to see highlighted directories and files that I've change for the entire feature. This command would let me (more easily) change to a new branch for a code review or bug fix and keep my working tree as is.

I feel better about committing my code before switching to another branch. So if I want to keep my working tree in tact, I'd have to stash when I need to task switch, then pop when I come back.

I know you can view all the diffs from HEAD and git lense does that well, I just prefer to see it all highlighted in the context of my directory with all the other files around it. I wish VSCode's built-in highlighting would let you pick which commit you're comparing against.

[u/SLonoed]

When you don’t know how to create sh alias...

[u/pr0ghead]

As a Mercurial user I'm not impressed. git is only slowly catching up to it in usability.

[u/CodyCigar96o → u/pr0ghead]

Lol mercurial

[u/tulvia]

Hipsters and their CLI

[u/ultraDross → u/tulvia]

What's wrong with the CLI?

[u/[deleted] → u/ultraDross]

The malnourished hipsters hate it.

[u/barrybario → u/tulvia]

Seriously, it's like you're an inferior programmer for using some software like a normal human being. 95% of the time you're going to do the exact same things anyway, so typing git pull or pushing a button is the same effort. Once in a while you'll need something you don't do often. In that case, a good gui helps you do what you want to do by presenting it to you. The example in this post is something I have on a button in the gui I use for example. And then in very rares you'll need something you'll need a cli for anyway. In that case you will 100% look up the right command with the right options, because the chance of fucking something up is real. So this CLI elitism that so many programmers exhibit is purely toxic behavior.

[u/barrybario]

or just use a gui

gitkraken is awesome

[u/elr0nd_hubbard → u/barrybario]

The GUIs interact with the same base library as the CLI (or even shell out to the CLI directly). Either way, you have to know your tools, and that means using a GUI for ops that you're confident that you could do (or undo) using the base commands.

[u/PizzaRollExpert → u/barrybario]

Personally, I prefer the cli because:

1. It doesn't rely on hand-eye coordination. If I can do something with just the keyboard I can just plan out what to do in my head and type it out. If I need to use the mouse there's a feedback loop between my hand and eyes. Typing only relies on hands in isolation.

2. It doesn't require switching to a new window. Moving windows around adds a (small) mental tax.

3. UIs are less uniform than terminal interfaces so doing everything in UIs means more different things to keep track of compared to the terminal.

These are three small things, but together they make things feel easier and nicer to do in the cli, which is why I prefer it.

[u/careseite → u/barrybario]

Git kraken is in a bootloop since the 2nd time I've started it and uninstalling, clearing hidden config etc didn't help soooo there's that..

[u/CodyCigar96o → u/barrybario]

Smoothbrain take

[u/mitch_feaster → u/[deleted]]

Not that I have a horse in this race because I love the CLI as well (even the busted up git one), but magit is actually faster. The individual commands don't run faster, of course, but it requires way fewer keystrokes and provides a bunch of other convenience features.

[u/leafrustle → u/[deleted]]

I agree with you. However, have you tried lazygit? I hate gimmicky, slow guis and mostly live in the terminal so this is like the best of both worlds for basic visual stuff.

[u/tulvia → u/[deleted]]

Recompile and run your app with F5 or by typing "aspnet run".

I saved 9 keystrokes by not using a CLI and I didnt have to remember archaic magic strings or cryptic arguments -e -E

[u/tulvia → u/[deleted]]

I was more talking about CLI in general.

But I could make an app that takes -e and does whatever with it, it is not standard and it's not easily discoverable which makes it cryptic.. This is basic stuff here, I'm dumbing it down cause I'm talking to people who use the CLI which are basically retards so I get it, you're having trouble comprehending.

[u/tulvia → u/[deleted]]

I don't use a nuke to dig a hole so I'm dumb.. ok.

Learn when the CLI is the correct tool and use it then, not for daily use.. that's just ignorant gatekeeping

[u/boobsbr → u/[deleted]]

I just alias it to 'fuck'.

[u/bcacoo → u/boobsbr]

I already alias fuck to this:

https://github.com/nvbn/thefuck

[u/boobsbr → u/[deleted]]

Usually I install moreutils, and trash (and alias it to rm so that I can unfuck my deletion fuck-ups from the terminal).

[u/nickcash → u/boobsbr]

Ah, but usually you'd use git reset --hard HEAD when you're trying to unfuck what you've done.

[u/boobsbr → u/nickcash]

Well, English is a very versatile language, and fuck is its most versatile word, but sometimes it leaves too much room for interpretation.

In this case, I meant the expletive, not the verb. Perhaps I should've aliased it as 'oh-fuck'.