Can we communally deprecate git checkout?

I'd rephrase and simplify this article a bit.

`git switch` and `git restore` are better alternatives to the `git checkout` command, as they have a lower cognitive overhead and fewer footguns to avoid. Although these commands are marked in the documentation as experimental, they work extremely well in practice. Experimental in this sense means that these may gain or lose behavior over time, not that these commands are unstable for use. As a community, we should use `switch` and `restore` commands rather than `checkout` when documenting / teaching git so that newer users start with a greater ability to reason about how the commands affect their workflow.

For more about the introduction of these commands and the details of the above see https://github.blog/open-source/git/highlights-from-git-2-23...

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.

Checkout is fine; it makes sense when you realize that the entire point of checkout is that it updates your current working tree to whatever you instruct it to. What "whatever" is: it's anything that git can understand as a reference; branch names (including those on remotes), commit IDs, HEAD and offsets (carets) on top of any of them.

ie. If you do "checkout master" it will checkout your working tree to the master branch. If you do "checkout HEAD", you get whatever's the current HEAD of your repository (in practice, this discards your changes).

Checkout can also do a partial checkout on a specific part of your working tree; "checkout [filename]" makes it so that you update that specific file to how it is on whatever you point it at.

The only weirdness is "checkout -b [branch]" making a new branch and switching you to it. It's a bit syntactically off/breaks the previous thing, but makes a lot of sense when you realize that your average workflow will combine git branch and git checkout anyway (since you're pretty much always making a branch to them work on it.)

Git switch and restore both feel like syntactic sugar that doesn't really help enough to warrant the mental switch of going from checkout to switch/restore. (Not to mention that checkout and restore do different things; restore also merged some functionality from git reset, a command whose main purpose is to update the index.)

Some things bug me in checkout; it should never have had a -b option so that it does "git branch" things along with checking out. It was probably done that way because early in Git's development, there was a lot of fuss about it having light weight branching, and what looks even more light weight is when you can instantly create a branch and switch to it with one command.

There is a consistency in checkout and reset.

Both checkout and reset can be whole or partial (terms I made up). Partial checkouts and resets specify paths. Whole specify at most a revision.

The checkout operation updates the indexed and working copies of files to be like what is specified in a given revision.

- A whole checkout to another revision, if it succeeds, will update the working files and index to what is in that revision, and move HEAD to it.

- A partial checkout updates the specified files, working and index, to what they look like in the given revision, without moving HEAD.

- A whole reset to to another revision updates just the index to that revision, and moves the current branch and HEAD to it. Working files stay the same.

- A partial reset updates the index entries for the specified files, to the given revision, without moving HEAD or branch. Working files stay the same.

There are obviously more details, due to various options like reset --hard and so on, plus considerations of what happens with a dirty index. But that's the basic paradigm:

   (starting with clean tree)

             checkout                          reset

   whole     moves:   HEAD                     moves:   HEAD and branch
             updates: working + index          updates: index
             result:  clean                    result:  working diff, nothing staged

   partial   moves:   nothing                  moves:   nothing
             updates: working + index          updates: index
             result:  working diff, staged     result:  working diff, opposite change staged

- the partial operations don't move the HEAD or current branch in both cases; the whole operations do move HEAD or HEAD + branch.

- whole or partial checkout updates working + index.

- whole or partial reset updates index.

Wholeheartedly agree with this suggestion.

I don't think I have used the incomprehensible `checkout` command once since I learned that `switch` and `restore` exist, and the previous years-long state of perpetual low-grade irritation I had felt toward git has diminished accordingly.

> … the only way to really understand deeply how git checkout works, you have to fundamentally understand the internal workings of git.

This is, and always has been, the primary UX problem with git. You use commands to manipulate the program’s model of the data, rather than to demonstrate your intent. It works only as long as your mental model of git matches git itself, but it doesn’t easily afford abstraction, and abstraction is the essence of efficient manipulation.

Put another way, a good tool allows you to use it well even if you don’t understand how it works. Git OTOH will quickly punish you for not understanding its model of the world.

A good UX for git would maintain the complexity for experts and provide a clear and simple surface area for most people who just want to perform familiar tasks. The fact that each person and team seems to have a unique incantation just for everyday tasks is an awful smell, and a sign of git’s immaturity.

The article writes:

> they had not asked me to explain git, they had asked me to explain GitHub

This is often the case for me as well.

Hey, at least git owns it by calling the shell commands "porcelain" (with git itself being the plumbing -- https://stackoverflow.com/questions/6976473/what-does-the-te... ).

The core value proposition of GitHub, GitLab, etc is to provide a nice GUI atop git. That's huge. I think that user-studies to improve one of the many existing foss git GUIs would be much better use of brain than deprecating git checkout.

checkout is one of the few git commands that makes sense to me. I use it a lot, to get back to a known state, after I screw up my working files with other git commands. E.g.

Copy my changed files to a temporary directory.

Delete my working directory.

Checkout the latest version from the repo.

Copy my changed files back.

I am so deeply pissed off at people who look at some completely useful, universal, widely-used-for-decades canonical command that's at the center of tens of millions of manual and automated deployments, picks out some esoteric details they decide are important and then proclaim, "OK when can we deprecate this debacle?" People who think you can just point "DEPRECATE" around at anything that they've decided is distasteful like a magic wand show their deep inexperience in tech as well as life overall and have no business making such proclamations.

I'm surprised no one has mentioned what is in my mind the cardinal sin of checkout: the parameter can be either a path or a ref and it automatically infers which one you mean. That's magic and relies on your ref namespace and your file namespace not conflicting (of course you can be explicit but no one is)

I think if the "only operate on certain files" mode of checkout was a flag, it would be much less confusing and easier to explain and we never would have gotten into this mess to begin with.

Hm. It doesn't look like git checkout does "too many things" or is overly complicated. It does one thing basically, which is changing the files in your working directory. It can work on single files or on the whole working directory, and it can optionally shortcut the creation of a new branch.

Then again, until today I never knew about "git switch" so I, too, learned something today :)