FWIW, since Git 2.23 I prefer using "git switch" and "git restore" instead of "git checkout".
Not only is it more semantic, it reduces the complexity of ‘git checkout’ which is a common complaint.
Really, It doesn’t make much sense to tack on some random ’--‘ flag on ‘checkout’ for that functionality. ‘restore’ is clear and describes what it does.
It doesn’t since the feature can’t be removed from git checkout for BC reasons.
Now we can treat git restore like it is a separate thing.
No, that’s incorrect. `git checkout` is the way to do this in the current version of Git.
The current version of Git allows you to use `git restore`, but the documentation says this about it:
> THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.
Until that warning goes away in a future version of Git, `git checkout` is the way to do this.
But, I still have to disagree. They may not have landed on the final shape of the API, but they are clearly encouraging people to use restore for this purpose.
There is no ‘warning’ message in the CLI. In fact the opposite, the help text in every ‘git status’ message explicitly states to use ‘restore’ for the case of resetting the changes of a single file, where it used to say use ‘checkout —-‘.
Yeah I’m used to using checkout —- like the rest of us, and sure we can all still do it if we want. But I would never recommend ‘checkout —- filename‘ to anyone in 2021. It doesn’t make any sense that that would be how you do that. It’s confusing trying to explain it to someone.
“Yeah I know you usually use this to completely change branches, or go to a particular commit hash. But if you use this weird ‘—-‘ flag & a file name, it does a mini ‘reset’ on that one file”
Why would you use some random flag on a command (checkout) that is typically used for a totally different use case? If anything, this should be a flag on ‘reset’.
I’m not a git ’complexity hater’, but it’s a perfect example of why a lot of people complain about git.
Good point. This makes no sense. There should either be a warning in the documentation and `git status` should not recommend it, or there should not be a warning in the documentation and `git status` should recommend it. It’s either ready for use or not, it shouldn’t be inconsistent about it.
I agree it’s a positive change, but the current state is ambiguous when it shouldn’t be.
You don’t need the “weird -- flag” in most cases, by the way, it’s not Git to blame for that, and it’s the same for both checkout and restore. The `--` is the standard POSIX way to distinguish between options and filenames. If there’s no ambiguity (e.g. `git checkout .`) then you can skip it. You only need it if the pathspec could be interpreted as an option.