4 ms·

This is correct, ‘git restore’ is the way to do this in the current version of git. ‘checkout —-‘ still works, but the ‘help’ text in ‘git status’ now recommend

by 40four 6y ago

This is correct, ‘git restore’ is the way to do this in the current version of git. ‘checkout —-‘ still works, but the ‘help’ text in ‘git status’ now recommends using ‘restore’. 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.

masklinn 6y ago
> Not only is it more semantic, it reduces the complexity of ‘git checkout’ which is a common complaint. It doesn’t since the feature can’t be removed from git checkout for BC reasons.
- mlyle 6y ago
  It does, because it sounded like he was concerned with the complexity of explaining the broadness of uses for git checkout. Now we can treat git restore like it is a separate thing.
  - 40four 6y ago
    This is a better way to say it and what a I meant thanks.
- paublyrne 6y ago
  I don't see why it couldn't be removed from a future release after a period of deprecation.
  - masklinn 6y ago
    Because there’s a million aliases out there which alias « git checkout —- . » to something sensible and there is no real justification for breaking them: checkout can trivially delegate to restore.
nyanpasu64 6y ago
I have a Git alias for `rs = restore -SWs`. `git rs commit :` more-or-less mimics what `git checkout branch :` did. (BTW, : means "repository root, regardless of current .")
JimDabell 6y ago
> ‘git restore’ is the way to do this in the current version of git. 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.
- 40four 6y ago
  Fair point, I had honestly never read the docs page on restore. 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.
  - JimDabell 6y ago
    > the help text in every ‘git status’ message explicitly states to use ‘restore’ 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.

by 40four 6y ago

masklinn 6y ago

> Not only is it more semantic, it reduces the complexity of ‘git checkout’ which is a common complaint. It doesn’t since the feature can’t be removed from git checkout for BC reasons.

mlyle 6y ago
It does, because it sounded like he was concerned with the complexity of explaining the broadness of uses for git checkout. Now we can treat git restore like it is a separate thing.
- 40four 6y ago
  This is a better way to say it and what a I meant thanks.
paublyrne 6y ago
I don't see why it couldn't be removed from a future release after a period of deprecation.
- masklinn 6y ago
  Because there’s a million aliases out there which alias « git checkout —- . » to something sensible and there is no real justification for breaking them: checkout can trivially delegate to restore.

nyanpasu64 6y ago

I have a Git alias for `rs = restore -SWs`. `git rs commit :` more-or-less mimics what `git checkout branch :` did. (BTW, : means "repository root, regardless of current .")

JimDabell 6y ago

> ‘git restore’ is the way to do this in the current version of git. 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.

40four 6y ago
Fair point, I had honestly never read the docs page on restore. 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.
- JimDabell 6y ago
  > the help text in every ‘git status’ message explicitly states to use ‘restore’ 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.