Hacker News Reader

Comment by clon | Hacker News Reader

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.

View on HN

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

Developers/designers are always torn between the competing priorities of preserving consistency and making a new interface the best it can be.

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?

Apple and GNOME are even better examples of why designers should not try to be designers. Now what options do we have left?

> Now what options do we have left?

KDE, git, and FreePascal / Lazarus.

The complaint has been, for ages, that checkout got that wrong. As designers, these developers are improving: They got it more right on the second try.

Reply on news.ycombinator.com