Live data from Hacker News

New in Git: switch and restore

banterly.net

31–40 of 550 posts

Re: New in Git: switch and restore

#31
post #19

Another difference is that with git checkout you can create and switch to the new branch in one command using the -b flag: git checkout -b new_branch You can do the same with the new one, but the flag is -c: git switch -c new_branch A good example why developers should not try to be designers. Even of talking about "API/CLI design.

-b in checkout is short for "branch" while -c in switch is short for "create".

IMO the UI of git switch is much more intuitive, since the argument is always a branch and the default behavior is to switch to an existing branch. For slightly different behavior (like creating the branch first) there are flags.

So I think it's good that the flag for switch is a different one than for checkout, since the interface of git checkout was quite unintuitive IMO.

Re: New in Git: switch and restore

#32
post #25

Earlier quoted context omitted.

Not typing it with "checkout" gets in the way of good tab completion. At work we have at least tens of thousands of branches and if I hit tab after "git checkout file_path_prefix", my shell is going to freeze for a while, while tab completion is going over remote branches.

How do you end up with that many branches? It sounds like you keep every feature branch around forever. Keeping one around for a few months I get (although personally the sooner they're gone after rebasing or cherry-picking them the better), but this sounds like a full on history of every branch ever.

If someone pushed a branch to remote, then there is a chance that they made a CI build for a customer based on that branch. Later you may need that branch to look at the source code, when you get a coredump, or logs or something.

(Every non-official build is made from a separate branch.)

Re: New in Git: switch and restore

#34
post #19

Another difference is that with git checkout you can create and switch to the new branch in one command using the -b flag: git checkout -b new_branch You can do the same with the new one, but the flag is -c: git switch -c new_branch A good example why developers should not try to be designers. Even of talking about "API/CLI design.

The new command makes more sense to me, i.e. `switch` and `-c(reate)` new_branch.

With `checkout`, however, what does `-b` even mean? Branch?

That said, it'll sure take time before the majority of developers (including myself) get onboard with it.

Would a deprecation flag be a good idea for git?

Re: New in Git: switch and restore

#35
Funny!

I've been using the alias `gk='git checktout'` for years now.

Git has been my first terminal-oriented versioning control system. I've used TFS and other but never focused on the action name, just the icons.

Checkout branch/hash/file seems more potent than two different commands.

Re: New in Git: switch and restore

#36

I used to know lot of terminal commands but I'm seriously falling behind due to jetbrains integration which covers 99% of my daily use case. Together with local history, I've never "lost" work in years. Never heard of switch /restore and will probably forget about it the next time I'm on the terminal. Rebase and interactive Rebase is so well integrated for my use cases and I feel much more productive without having t…

> but I'm seriously falling behind due to jetbrains integration

This IntelliJ integration is the source of quite a lot of git problems in teams I worked with.

I'm quite flabbergasted by this - devs claim to know git on their CV, come in and know what "commit" is and how to use the IntelliJ UI, but don't even understand what its doing. And everyone is acting like it's OK and learning git is a "hard thing ill never need" and we should all use sourcetree or jetbrains. Or people just get so used to it and never understand what exists below it. They lose all sense of what they're doing and just think "the machine knows what I want". Then a vaguely questioned dialog appears - or something similar - and they cause clusterfuck upon their branch - or sometimes even other people's remote branches.

How do we allow our culture to be so lazy that people resist using one of the basic tools because "oh its hard I gotta remember 5 commands" and we find it OK? No wonder the plane is burning.

It's good that you still know that reflog exists, because a lot of "inteliij is my git client" users don't even know about it. Tho I'm still wondering, isn't it faster/easier to open intelliJ terminal and type a command or two than having to ope a whole new window and click around it? (also sorry if this sounds like an attack on you, it isn't! just really wondering!)

Also, re: OP: So basically 2 new commands were added that do what other commands already do, but people dont read the docs so we should add new commands so maybe people will read the docs for them?

Re: New in Git: switch and restore

#37
It is unfortunate that:

+ git switch is documented as "EXPERIMENTAL"

+ git --help lists git switch but not git checkout as an important command

This is a documentation inconsistency. It can't be both the canonical interface to use and experimental at the same time.

Re: New in Git: switch and restore

#38
post #18

I knew about `git switch` but this is the first time I hear about `git restore`. It also never occurred to me that the checkout command was overloaded in that particular way.

Doesn't seem overloaded, seems quite fitting. Checkout a hash or a file from a hash. Switch kinda seems "underloaded" in this way.

Re: New in Git: switch and restore

#39

What is a good resource to learn modern git properly? I have been using git for 10 years and get around with a really small set of old commands.

Ah yes, modern git for people using modern c++ If your plain old git works fine for you, there is no need to go looking for modern git IMHO.
Post reply on HN