9 ms·

Can we communally deprecate git checkout?

57 points by mirawelner 2y ago

marssaxman 2y ago
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.
- kazinator 2y ago
  What do you use for navigating in the branch history when doing a git bisect? Can you use switch for that?
  - marssaxman 2y ago
    I'm afraid I have no idea - I've never needed to use `git bisect`.
  - afdbcreid 2y ago
    git switch --detach
    - frizlab 2y ago
      or the shorter `git switch -d`
      - lostmsu 2y ago
        Not to be confused with `git switch -D`, a shorthand for `git switch --delete`
        frizlab 2y ago
        Are you being sarcastic? I can’t find the --delete option in git-switch man page.
        lostmsu 2y ago
        I am. The fact that you had to look is the point.
        frizlab 2y ago
        I don’t see the point though. That it’s impossible to know all of git’s options by heart? I mean that’s obvious and true of most software (https://xkcd.com/1168/ https://xkcd.com/1168/ though this one is not actually hard).
        kazinator 2y ago
        I do see a point though. Ostensibly, sure, it's hard to be so confident that a program does not have a certain feature that you can deny it without looking. But think about this case. Would it make sense for git switch to have a delete option? Of course not. But you can't be sure, because, git. The feeling is that they would merge something like that.
        deleted 2y ago
        [deleted]
    - kazinator 2y ago
      But "git switch --detach master" leaves you detached. So switch is just a dumber checkout that has to be told when to detach or not instead of inferring it from the kind of revision.
      - remram 2y ago
        That's usually a good thing, setting your HEAD to a symbolic ref or a commit are very different operations. Having a switch makes sense and probably catches beginner errors rather than letting them know afterwards. I don't feel like typing 'git s -d <branch>' has slowed me down in practice but you're technically right of course (or I would add a 'd="switch -d'"' alias).
  - remram 2y ago
    I think you're asking for 'git switch -d' (for detached). In practice you will still need 'git reset' but only with a branch parameter (all 'git reset -- paths' can be replaced with 'git restore'), usually with --keep, --soft, or --mixed.
SoftTalker 2y ago
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.
- hmcdona1 2y ago
  Use `git stash` instead of copying files around manually to save yourself some time.
  - bluedevilzn 2y ago
    Parent comment is the quintessential example from the article that most people who know git didn't learn git properly.
    - SoftTalker 2y ago
      Yeah git rubbed me the wrong way from the beginning and I never learned it properly. My way makes the most sense to me. Stash? where? How do I get my files back? None of that is intuitive. I understand my way.
      - camtarn 2y ago
        I love git stash, but to be fair, if you've just had Git do something unexpected to your files, I can completely understand why you would not then trust Git to keep your changes safe while you use more Git commands to get back into a sane state! Sometimes simple and well understood is the best way.
        seba_dos1 2y ago
        Anything can do something unexpected to your files if you don't put effort to understand it. Sure, some things require less and some more effort, but using tools without understanding them, while isn't impossible, isn't exactly a recipe for good outcomes.
JohnMakin 2y ago
Maybe I am a rube, but people bemoaning "complexity" of git just never strikes home with me. I started using it when I was 14, so maybe that is it (it was still fairly new, but it's all I've ever known) - I still only use a handful of commands. git checkout, git checkout -b git pull git merge (mostly to merge master back into a development branch, or something like that) git push git restore (much more rarely) git reset (even much more rarely) Barely ever have I had to do anything but these for 99.999% of my workflow, and none of them seem particularly complicated unless you run into merge conflicts, but on every team there seems to be at least one pro "merge conflict" guy. Idk. Checkout is occasionally annoying when it forces you to stash unrelated changes to what you're doing, that's about all I can come up with.
- vrosas 2y ago
  I’ve found that people are either die hard rebase fans or die hard merge fans. Neither side can understand the other and I’ve never had it properly explained to me what the difference is or why I should care.
  - samschooler 2y ago
    Merge = Smooshes two branches together into one. It keeps all the commits from both branches and creates a new "merge commit" to combine them. Doesn't mess with the commit history. Rebase = Takes all the commits from one branch and sticks them on top of another branch, like stacking them in front. It rewrites the commit history to make everything look like one straight line. I'm a rebase stan, but that's just my opinion.
  - mschuster91 2y ago
    `git merge` is for regular people who are measured by how much they can accomplish in a given timeframe. `git rebase` is for academics and startups where no one gives a fuck about anything and no one bats an eye if you waste a day or two on a rebase gone wrong. It's easy to undo a merge and a bit nasty if you already pushed the merge commit. But undoing a rebase? Oh god you're in for a lot of pain.
jdnejdjd 2y ago
[dead]
makeitdouble 2y ago
The crux of it, and the reason why I see it as a lost cause: > the only way to really understand deeply how git checkout works, you have to fundamentally understand the internal workings of git. Thing is, there's no way around fundamentally understanding the internal workings if you're going to use git on the command line. Checkout and reset can be tough, but for instance reflog also makes no sense if you don't understand the commit model. Newer user and occasional git users will be better served with a nice GUI. VSCode has extensions that will help deal with the basic operations etc. The issue to me has never been that commands are cryptic, and more that git isn't made for people enjoying simplicity. For those, an extra layer above git is the best choice IMHO.
- mschuster91 2y ago
  I think it's the other way around. GUIs that expose everything of Git to the end developer also expose a lot of ways to shoot yourself in the foot if you don't know what the fuck you are doing. The times I had to assist people shooting themselves with whatever favorite GUI they use... man I was happy I'm firmly in the Git CLI camp.
  - makeitdouble 2y ago
    I'm in agreement. GUIs when it comes to git should offer a more limited, but consistent and understandable set of actions for users. I'd imagine something very close to what SVN or CVS offered, and mainly targeted at users who won't be professionally working with a full team on a shared code base.
zzzeek 2y ago
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.
- abuani 2y ago
  Conversely, it's an exceptional way of getting a highly engaging discussion. It's meant to elicit an emotional reaction and get people to read their article. I don't think they made any convincing arguments to actually deprecate the command, but highlights the complexity of a command that thousands of people issue on a daily basis without thinking about it.
  - zzzeek 2y ago
    > It's meant to elicit an emotional reaction and get people to read their article I'll grant it for an article for wide readership but as a general tool of technical discourse used in places like github issues etc., highly inappropriate.
- deleted 2y ago
  [deleted]
cmgriffing 2y ago
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 2y ago
  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 https://git-scm.com/docs/git-switch
  - Izkata 2y ago
    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.
  - ghewgill 2y ago
    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 https://stackoverflow.com/a/215731/893
    - epistasis 2y ago
      > [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?
- BizarreByte 2y ago
  I felt that way about the master to main debacle, but some angry people online won anyway.
Zambyte 2y ago
I haven't used it in a year. That's how long ago I switched from git to jujutsu. jj new is all you need.
- bsder 2y ago
  Ayup. The only downside of jujutsu is that it exposes how many places have become welded to the specifics of Git and Github.
- ykonstant 2y ago
  I've had this question for some time: how do jj users perform bisect? I know it doesn't have a dedicated bisect command (yet?), but surely there must be a way to do that, right? Bisecting commits/changes is crucial for debugging.
  - Zambyte 2y ago
    I personally linearize my history via rebasing, so manually bisecting is easy. That's probably pretty common among jj users.
dark-star 2y ago
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 :)
- ameliaquining 2y ago
  The problem is that it doesn't just change your working tree, it also (sometimes) changes HEAD. So the two behaviors both work very differently and are intended for very different use cases.
greenthrow 2y ago
Git is not that complicated. If you can't grok git I am seriously concerned about your ability to be an effective software engineer. Edit: I had assumed the OP was one of the many people I have met who have a Tech Lead title but are not really very technical due to the grandiose request to deprecate checkout. But looking into the blog more I realize that instead the author is more new in their career and I don't mean to be as harsh to someone in that position. Instead to them I would say; when you encoutner something established you don't understand, take it as an opportunity to learn. Git isn't beyond you, it won't take as long to fully understand as you think.
- ameliaquining 2y ago
  As the article explains, the problem with this attitude is that Git is increasingly used by people who aren't software engineers and don't want to be. (Also, tools for software engineers still benefit from clarity and focus of purpose for simple use cases.)
  - greenthrow 2y ago
    If your non-engineers have to deal with git you have an org or process problem. Git is pretty clear and easy to use to a competent software engineer. I'm tired of this meme that Git is hard. It doesn't get enough pushback.
    - ameliaquining 2y ago
      What do you think the people from the biomedical engineering lab and the physics lab from the article should be doing differently?
    - zihotki 2y ago
      While I strongly disagree with the conclusion of an org or process problem, I agree that basic concepts are simple and straightwordard. Plus majority (an assumption based on what I've seen) of those users use a GUI tool. GUI makes it simple to work with. A few clicks here and there and you're done. If something goes very wrong, there is usually a collegue who can help using CLI magic
sonofhans 2y ago
> … 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.
- makemyworkforme 2y ago
  I must admit that when I first learnt git, I thought that the only way to correctly use git was to know the object model of git. I thought this was important because git is at the end a data manager and I then though that one should know the data model you are manipulating in order to manipulate it in correct way. In that respect, I always found git commands mostly intuitive. Much later in my career I learnt that people were using git without even knowing anything about what a Merkle tree is and I must say I was extremely surprised. I'm not saying its good or bad, just describing my younger days.
whalesalad 2y ago
can we communally deprecate using monospaced fonts with full browser width content blocks for free form text?
- mirawelner 2y ago
  I am very new to web design - I appreciate the feedback! I changed it to a serif font (Merriweather) and increased the margins for the browser version. Is this more readable?
  - hooli_gan 2y ago
    Not really on mobile. The margins are too large. Screenshot from mobile Chrome: https://imgur.com/a/q4oa7aO https://imgur.com/a/q4oa7aO
  - politelemon 2y ago
    It's very difficult to read right now in Firefox mobile. Screenshot here https://ibb.co/x5xsXpB https://ibb.co/x5xsXpB
  - Izkata 2y ago
    Per the sibling commits, you don't want to use "margin" to control width. Use margin to control spacing between elements / the edge of the screen. What you want here is to put "max-width" on the content. Specifically I'd suggest: * Change "margin" on the <p> tags to "1.5rem 0" * Change "margin" on .blog-page to "1.5rem auto" to keep the grey background centered based on width * Add "max-width: 800px" (or whatever) to .blog-page
outworlder 2y ago
Well, since the author is sharing their pet peeve, I'll share mine and it's unrelated to Git: People that post XKCD without the title text!
- mirawelner 2y ago
  title text added :)
lelandbatey 2y ago
I wanted to stop using git checkout, so I set up a little .bashrc magic to prevent me from calling 'git checkout' and to suggest which command I should be using instead. Here's the script: # Paste this snippet into your .bashrc to help you learn `git switch`. # # Turn on the extdebug mode so that our `scold_git_checkout` can prevent # us from running git-checkout by exiting 1; forcing us to re-learn our # muscle memory. # If we *really* need to use git checkout for something, we can do that # by using the full path to the git executable e.g.: # /usr/bin/git checkout # isn't caught by our scolding shopt -s extdebug scold_git_checkout() { if [ "$1" != "git" ]; then return 0 fi if [ "$2" != "checkout" ]; then return 0 fi cat >&2 <<EOF ////// DON'T use git checkout! ////// The 'git checkout' command of git has been replaced with two other commands: 'git switch' and 'git restore'. You used: $@ EOF if [ "$3" == "-b" ]; then PASTESAFE="$(printf "%q " "${@:4}")" cat >&2 <<EOF You should use the following: git switch -c $PASTESAFE EOF elif [ "$3" == "--" ]; then PASTESAFE="$(printf "%q " "${@:4}")" cat >&2 <<EOF You should use the following: git restore $PASTESAFE EOF else PASTESAFE="$(printf "%q " "${@:3}")" cat >&2 <<EOF You can try the following: git switch $PASTESAFE EOF fi return 1 } trap 'scold_git_checkout $BASH_COMMAND' DEBUG Gist with this special scold commit hook, should I ever change it more: https://gist.github.com/lelandbatey/b42b527bfa41b761d0aec2871d32748a https://gist.github.com/lelandbatey/b42b527bfa41b761d0aec287...
tecoholic 2y ago
Never have I read Git Pro or have the deep understanding of git’s internals. But I use checkout almost every day, as a shortcut to create a new branch and switch to it, throw away changes that I don’t need and…well, that’s pretty much it. Now that I have read this article half way, I decided to stop. Because I am learning a few extra things that’s kind of messing up my mental model of what that command does. I think a fair % of git users might be in my boat. Our knowledge, hence our burden is limited. So community might not be as confused with checkout as the author or those who grok git.
imoreno 2y ago
The title and first 2/3s of the article are excessively hyperbolic and it detracts from the message. The title would be improved by adding "in favor of git switch/restore". The body would be improved by leading with the last 3 paragraphs, and tucking the rest under a "why not just use `git checkout`?" section. I appreciated finding out about `switch` and `restore` as alternatives to `checkout`. But they are minor, incremental improvements. Framing it like `checkout` is the devil doesn't help, because it really isn't that bad, especially to people who consider git as a means to an end.
- ameliaquining 2y ago
  The author explicitly says "I'm not calling for Git to remove git checkout" and "I am not asking for an official deprecation". They are trying, rather, to build a community consensus that it should not be taught to new users going forward. The command itself isn't going anywhere.
  - imoreno 2y ago
    You're right, that was me reading carelessly. I've removed that last part of my post (couldn't figure out how to do strikethrough on HN).
cheshire137 2y ago
Huh. I use checkout multiple times a day every day. It's how I switch branches, including creating new branches. I guess I could use other commands, but why change what's working fine?
- joshka 2y ago
  https://github.blog/open-source/git/highlights-from-git-2-23/#experimental-alternatives-for-git-checkout https://github.blog/open-source/git/highlights-from-git-2-23... gives a good overview of the reason for the two new commands.
  - mac-attack 2y ago
    "The new commands, by contrast, aim to clearly separate the responsibilities of git checkout into two narrower categories: operations which change branches and operations which change files." Simple, concise breakdown
joshka 2y ago
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/#experimental-alternatives-for-git-checkout https://github.blog/open-source/git/highlights-from-git-2-23...
- ericyd 2y ago
  Less sensational, but also more concise and more direct.
deleted 2y ago
[deleted]
cyrnel 2y ago
It's not hard to change to git switch. I used to have a "co" alias for "checkout" which I removed. I'd say I lost maybe 60 seconds of typing time over the few weeks it took to unlearn the muscle memory. 60 seconds of time investment to be better at mentoring the next generation of technologists is worth it.
encoderer 2y ago
What is wrong with me that I dont have any problems with this? Maybe it’s how we name branches? I think I’ve only seen a few cases where I use checkout and it complains about being ambiguous.
- baobun 2y ago
  If you manage to get identically named branch and tag you're probably up for a lot of confusion if you're not familiar enough with checkout...
deleted 2y ago
[deleted]
kazinator 2y ago
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 basic consistencies are: - 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.
DriftRegion 2y ago
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-term-porcelain-mean-in-git 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.
- xeonmc 2y ago
  What should the ui layer atop porcelain be called? Gilding?
  - divbzero 2y ago
    I believe the layer you’re thinking of is ‘glaze’: https://en.wikipedia.org/wiki/Ceramic_glaze https://en.wikipedia.org/wiki/Ceramic_glaze
wink 2y ago
I regularly learn and promptly forget about git switch. I guess that's what 15 years of (near) daily git usage does to you.
noirscape 2y ago
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.)
- nayuki 2y ago
  git checkout is not fine. git checkout <commit> requires a clean working tree, and will change HEAD to the specified <commit>. git checkout [<commit>] <paths> does not require a clean working tree, will replace the specified paths (i.e. files or directories), and does not change HEAD. These are extremely different behaviors. I agree with the article that git switch vs. git restore are better replacements. Since you bring up the topic of git reset, I also disagree with what you said; I don't think its main purpose is to update the index; rather, it is to update the current branch's pointer to an arbitrary commit with the possibility of orphaning children (unlike git commit or git merge, which never lose children). Factually speaking, git reset can update just the branch (--soft), the branch and then index (--mixed), or the branch then index then working tree (--hard). Of course, if you perform git reset and stay at the current HEAD commit, then you have the choice of updating just the index, or the index and the working tree.
- fargle 2y ago
EE84M3i 2y ago
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.
g-b-r 2y ago
I am horrified by the article's last paragraph. Teach RESET instead of checkout??? The command with the most likelihood to make you lose work, and leave you with permanent errors?? And with the most convoluted usage and documentation?
dvektor 2y ago
As much as I conceptually agree with everything in this article... git checkout -b {branch} is not leaving my muscle memory any time soon

57 points by mirawelner 2y ago

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.

kazinator 2y ago
What do you use for navigating in the branch history when doing a git bisect? Can you use switch for that?
- marssaxman 2y ago
  I'm afraid I have no idea - I've never needed to use `git bisect`.
- afdbcreid 2y ago
  git switch --detach
  - frizlab 2y ago
    or the shorter `git switch -d`
    - lostmsu 2y ago
      Not to be confused with `git switch -D`, a shorthand for `git switch --delete`
      - frizlab 2y ago
        Are you being sarcastic? I can’t find the --delete option in git-switch man page.
        lostmsu 2y ago
        I am. The fact that you had to look is the point.
        frizlab 2y ago
        I don’t see the point though. That it’s impossible to know all of git’s options by heart? I mean that’s obvious and true of most software (https://xkcd.com/1168/ https://xkcd.com/1168/ though this one is not actually hard).
        kazinator 2y ago
        I do see a point though. Ostensibly, sure, it's hard to be so confident that a program does not have a certain feature that you can deny it without looking. But think about this case. Would it make sense for git switch to have a delete option? Of course not. But you can't be sure, because, git. The feeling is that they would merge something like that.
        deleted 2y ago
        [deleted]
  - kazinator 2y ago
    But "git switch --detach master" leaves you detached. So switch is just a dumber checkout that has to be told when to detach or not instead of inferring it from the kind of revision.
    - remram 2y ago
      That's usually a good thing, setting your HEAD to a symbolic ref or a commit are very different operations. Having a switch makes sense and probably catches beginner errors rather than letting them know afterwards. I don't feel like typing 'git s -d <branch>' has slowed me down in practice but you're technically right of course (or I would add a 'd="switch -d'"' alias).
- remram 2y ago
  I think you're asking for 'git switch -d' (for detached). In practice you will still need 'git reset' but only with a branch parameter (all 'git reset -- paths' can be replaced with 'git restore'), usually with --keep, --soft, or --mixed.

SoftTalker 2y ago

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.

hmcdona1 2y ago
Use `git stash` instead of copying files around manually to save yourself some time.
- bluedevilzn 2y ago
  Parent comment is the quintessential example from the article that most people who know git didn't learn git properly.
  - SoftTalker 2y ago
    Yeah git rubbed me the wrong way from the beginning and I never learned it properly. My way makes the most sense to me. Stash? where? How do I get my files back? None of that is intuitive. I understand my way.
    - camtarn 2y ago
      I love git stash, but to be fair, if you've just had Git do something unexpected to your files, I can completely understand why you would not then trust Git to keep your changes safe while you use more Git commands to get back into a sane state! Sometimes simple and well understood is the best way.
      - seba_dos1 2y ago
        Anything can do something unexpected to your files if you don't put effort to understand it. Sure, some things require less and some more effort, but using tools without understanding them, while isn't impossible, isn't exactly a recipe for good outcomes.

JohnMakin 2y ago

Maybe I am a rube, but people bemoaning "complexity" of git just never strikes home with me. I started using it when I was 14, so maybe that is it (it was still fairly new, but it's all I've ever known) - I still only use a handful of commands. git checkout, git checkout -b git pull git merge (mostly to merge master back into a development branch, or something like that) git push git restore (much more rarely) git reset (even much more rarely) Barely ever have I had to do anything but these for 99.999% of my workflow, and none of them seem particularly complicated unless you run into merge conflicts, but on every team there seems to be at least one pro "merge conflict" guy. Idk. Checkout is occasionally annoying when it forces you to stash unrelated changes to what you're doing, that's about all I can come up with.

vrosas 2y ago
I’ve found that people are either die hard rebase fans or die hard merge fans. Neither side can understand the other and I’ve never had it properly explained to me what the difference is or why I should care.
- samschooler 2y ago
  Merge = Smooshes two branches together into one. It keeps all the commits from both branches and creates a new "merge commit" to combine them. Doesn't mess with the commit history. Rebase = Takes all the commits from one branch and sticks them on top of another branch, like stacking them in front. It rewrites the commit history to make everything look like one straight line. I'm a rebase stan, but that's just my opinion.
- mschuster91 2y ago
  `git merge` is for regular people who are measured by how much they can accomplish in a given timeframe. `git rebase` is for academics and startups where no one gives a fuck about anything and no one bats an eye if you waste a day or two on a rebase gone wrong. It's easy to undo a merge and a bit nasty if you already pushed the merge commit. But undoing a rebase? Oh god you're in for a lot of pain.

jdnejdjd 2y ago

[dead]

makeitdouble 2y ago

The crux of it, and the reason why I see it as a lost cause: > the only way to really understand deeply how git checkout works, you have to fundamentally understand the internal workings of git. Thing is, there's no way around fundamentally understanding the internal workings if you're going to use git on the command line. Checkout and reset can be tough, but for instance reflog also makes no sense if you don't understand the commit model. Newer user and occasional git users will be better served with a nice GUI. VSCode has extensions that will help deal with the basic operations etc. The issue to me has never been that commands are cryptic, and more that git isn't made for people enjoying simplicity. For those, an extra layer above git is the best choice IMHO.

mschuster91 2y ago
I think it's the other way around. GUIs that expose everything of Git to the end developer also expose a lot of ways to shoot yourself in the foot if you don't know what the fuck you are doing. The times I had to assist people shooting themselves with whatever favorite GUI they use... man I was happy I'm firmly in the Git CLI camp.
- makeitdouble 2y ago
  I'm in agreement. GUIs when it comes to git should offer a more limited, but consistent and understandable set of actions for users. I'd imagine something very close to what SVN or CVS offered, and mainly targeted at users who won't be professionally working with a full team on a shared code base.

zzzeek 2y ago

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.

abuani 2y ago
Conversely, it's an exceptional way of getting a highly engaging discussion. It's meant to elicit an emotional reaction and get people to read their article. I don't think they made any convincing arguments to actually deprecate the command, but highlights the complexity of a command that thousands of people issue on a daily basis without thinking about it.
- zzzeek 2y ago
  > It's meant to elicit an emotional reaction and get people to read their article I'll grant it for an article for wide readership but as a general tool of technical discourse used in places like github issues etc., highly inappropriate.
deleted 2y ago
[deleted]

cmgriffing 2y ago

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 2y ago
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 https://git-scm.com/docs/git-switch
- Izkata 2y ago
  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.
- ghewgill 2y ago
  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 https://stackoverflow.com/a/215731/893
  - epistasis 2y ago
    > [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?
BizarreByte 2y ago
I felt that way about the master to main debacle, but some angry people online won anyway.

Zambyte 2y ago

I haven't used it in a year. That's how long ago I switched from git to jujutsu. jj new is all you need.

bsder 2y ago
Ayup. The only downside of jujutsu is that it exposes how many places have become welded to the specifics of Git and Github.
ykonstant 2y ago
I've had this question for some time: how do jj users perform bisect? I know it doesn't have a dedicated bisect command (yet?), but surely there must be a way to do that, right? Bisecting commits/changes is crucial for debugging.
- Zambyte 2y ago
  I personally linearize my history via rebasing, so manually bisecting is easy. That's probably pretty common among jj users.

dark-star 2y ago

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 :)

ameliaquining 2y ago
The problem is that it doesn't just change your working tree, it also (sometimes) changes HEAD. So the two behaviors both work very differently and are intended for very different use cases.

greenthrow 2y ago

Git is not that complicated. If you can't grok git I am seriously concerned about your ability to be an effective software engineer. Edit: I had assumed the OP was one of the many people I have met who have a Tech Lead title but are not really very technical due to the grandiose request to deprecate checkout. But looking into the blog more I realize that instead the author is more new in their career and I don't mean to be as harsh to someone in that position. Instead to them I would say; when you encoutner something established you don't understand, take it as an opportunity to learn. Git isn't beyond you, it won't take as long to fully understand as you think.

ameliaquining 2y ago
As the article explains, the problem with this attitude is that Git is increasingly used by people who aren't software engineers and don't want to be. (Also, tools for software engineers still benefit from clarity and focus of purpose for simple use cases.)
- greenthrow 2y ago
  If your non-engineers have to deal with git you have an org or process problem. Git is pretty clear and easy to use to a competent software engineer. I'm tired of this meme that Git is hard. It doesn't get enough pushback.
  - ameliaquining 2y ago
    What do you think the people from the biomedical engineering lab and the physics lab from the article should be doing differently?
  - zihotki 2y ago
    While I strongly disagree with the conclusion of an org or process problem, I agree that basic concepts are simple and straightwordard. Plus majority (an assumption based on what I've seen) of those users use a GUI tool. GUI makes it simple to work with. A few clicks here and there and you're done. If something goes very wrong, there is usually a collegue who can help using CLI magic

sonofhans 2y ago

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

makemyworkforme 2y ago
I must admit that when I first learnt git, I thought that the only way to correctly use git was to know the object model of git. I thought this was important because git is at the end a data manager and I then though that one should know the data model you are manipulating in order to manipulate it in correct way. In that respect, I always found git commands mostly intuitive. Much later in my career I learnt that people were using git without even knowing anything about what a Merkle tree is and I must say I was extremely surprised. I'm not saying its good or bad, just describing my younger days.

whalesalad 2y ago

can we communally deprecate using monospaced fonts with full browser width content blocks for free form text?

mirawelner 2y ago
I am very new to web design - I appreciate the feedback! I changed it to a serif font (Merriweather) and increased the margins for the browser version. Is this more readable?
- hooli_gan 2y ago
  Not really on mobile. The margins are too large. Screenshot from mobile Chrome: https://imgur.com/a/q4oa7aO https://imgur.com/a/q4oa7aO
- politelemon 2y ago
  It's very difficult to read right now in Firefox mobile. Screenshot here https://ibb.co/x5xsXpB https://ibb.co/x5xsXpB
- Izkata 2y ago
  Per the sibling commits, you don't want to use "margin" to control width. Use margin to control spacing between elements / the edge of the screen. What you want here is to put "max-width" on the content. Specifically I'd suggest: * Change "margin" on the <p> tags to "1.5rem 0" * Change "margin" on .blog-page to "1.5rem auto" to keep the grey background centered based on width * Add "max-width: 800px" (or whatever) to .blog-page

outworlder 2y ago

Well, since the author is sharing their pet peeve, I'll share mine and it's unrelated to Git: People that post XKCD without the title text!

mirawelner 2y ago
title text added :)

lelandbatey 2y ago

I wanted to stop using git checkout, so I set up a little .bashrc magic to prevent me from calling 'git checkout' and to suggest which command I should be using instead. Here's the script: # Paste this snippet into your .bashrc to help you learn `git switch`. # # Turn on the extdebug mode so that our `scold_git_checkout` can prevent # us from running git-checkout by exiting 1; forcing us to re-learn our # muscle memory. # If we *really* need to use git checkout for something, we can do that # by using the full path to the git executable e.g.: # /usr/bin/git checkout # isn't caught by our scolding shopt -s extdebug scold_git_checkout() { if [ "$1" != "git" ]; then return 0 fi if [ "$2" != "checkout" ]; then return 0 fi cat >&2 <<EOF ////// DON'T use git checkout! ////// The 'git checkout' command of git has been replaced with two other commands: 'git switch' and 'git restore'. You used: $@ EOF if [ "$3" == "-b" ]; then PASTESAFE="$(printf "%q " "${@:4}")" cat >&2 <<EOF You should use the following: git switch -c $PASTESAFE EOF elif [ "$3" == "--" ]; then PASTESAFE="$(printf "%q " "${@:4}")" cat >&2 <<EOF You should use the following: git restore $PASTESAFE EOF else PASTESAFE="$(printf "%q " "${@:3}")" cat >&2 <<EOF You can try the following: git switch $PASTESAFE EOF fi return 1 } trap 'scold_git_checkout $BASH_COMMAND' DEBUG Gist with this special scold commit hook, should I ever change it more: https://gist.github.com/lelandbatey/b42b527bfa41b761d0aec2871d32748a https://gist.github.com/lelandbatey/b42b527bfa41b761d0aec287...

tecoholic 2y ago

Never have I read Git Pro or have the deep understanding of git’s internals. But I use checkout almost every day, as a shortcut to create a new branch and switch to it, throw away changes that I don’t need and…well, that’s pretty much it. Now that I have read this article half way, I decided to stop. Because I am learning a few extra things that’s kind of messing up my mental model of what that command does. I think a fair % of git users might be in my boat. Our knowledge, hence our burden is limited. So community might not be as confused with checkout as the author or those who grok git.

imoreno 2y ago

The title and first 2/3s of the article are excessively hyperbolic and it detracts from the message. The title would be improved by adding "in favor of git switch/restore". The body would be improved by leading with the last 3 paragraphs, and tucking the rest under a "why not just use `git checkout`?" section. I appreciated finding out about `switch` and `restore` as alternatives to `checkout`. But they are minor, incremental improvements. Framing it like `checkout` is the devil doesn't help, because it really isn't that bad, especially to people who consider git as a means to an end.

ameliaquining 2y ago
The author explicitly says "I'm not calling for Git to remove git checkout" and "I am not asking for an official deprecation". They are trying, rather, to build a community consensus that it should not be taught to new users going forward. The command itself isn't going anywhere.
- imoreno 2y ago
  You're right, that was me reading carelessly. I've removed that last part of my post (couldn't figure out how to do strikethrough on HN).

cheshire137 2y ago

Huh. I use checkout multiple times a day every day. It's how I switch branches, including creating new branches. I guess I could use other commands, but why change what's working fine?

joshka 2y ago
https://github.blog/open-source/git/highlights-from-git-2-23/#experimental-alternatives-for-git-checkout https://github.blog/open-source/git/highlights-from-git-2-23... gives a good overview of the reason for the two new commands.
- mac-attack 2y ago
  "The new commands, by contrast, aim to clearly separate the responsibilities of git checkout into two narrower categories: operations which change branches and operations which change files." Simple, concise breakdown

joshka 2y ago

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/#experimental-alternatives-for-git-checkout https://github.blog/open-source/git/highlights-from-git-2-23...

ericyd 2y ago
Less sensational, but also more concise and more direct.

deleted 2y ago

[deleted]

cyrnel 2y ago

It's not hard to change to git switch. I used to have a "co" alias for "checkout" which I removed. I'd say I lost maybe 60 seconds of typing time over the few weeks it took to unlearn the muscle memory. 60 seconds of time investment to be better at mentoring the next generation of technologists is worth it.

encoderer 2y ago

What is wrong with me that I dont have any problems with this? Maybe it’s how we name branches? I think I’ve only seen a few cases where I use checkout and it complains about being ambiguous.

baobun 2y ago
If you manage to get identically named branch and tag you're probably up for a lot of confusion if you're not familiar enough with checkout...

deleted 2y ago

[deleted]

kazinator 2y ago

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 basic consistencies are: - 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.

DriftRegion 2y ago

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-term-porcelain-mean-in-git 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.

xeonmc 2y ago
What should the ui layer atop porcelain be called? Gilding?
- divbzero 2y ago
  I believe the layer you’re thinking of is ‘glaze’: https://en.wikipedia.org/wiki/Ceramic_glaze https://en.wikipedia.org/wiki/Ceramic_glaze

wink 2y ago

I regularly learn and promptly forget about git switch. I guess that's what 15 years of (near) daily git usage does to you.

noirscape 2y ago

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

nayuki 2y ago
git checkout is not fine. git checkout <commit> requires a clean working tree, and will change HEAD to the specified <commit>. git checkout [<commit>] <paths> does not require a clean working tree, will replace the specified paths (i.e. files or directories), and does not change HEAD. These are extremely different behaviors. I agree with the article that git switch vs. git restore are better replacements. Since you bring up the topic of git reset, I also disagree with what you said; I don't think its main purpose is to update the index; rather, it is to update the current branch's pointer to an arbitrary commit with the possibility of orphaning children (unlike git commit or git merge, which never lose children). Factually speaking, git reset can update just the branch (--soft), the branch and then index (--mixed), or the branch then index then working tree (--hard). Of course, if you perform git reset and stay at the current HEAD commit, then you have the choice of updating just the index, or the index and the working tree.
fargle 2y ago

EE84M3i 2y ago

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.

g-b-r 2y ago

I am horrified by the article's last paragraph. Teach RESET instead of checkout??? The command with the most likelihood to make you lose work, and leave you with permanent errors?? And with the most convoluted usage and documentation?

dvektor 2y ago

As much as I conceptually agree with everything in this article... git checkout -b {branch} is not leaving my muscle memory any time soon