So I will probably avoid both git restore --staged and git reset --hard (and suggest to others to do the same). I hope git status will keep the hint to use git reset to unstage, even after git-restore becomes stable.
These new commands were hatched in response to a blog post from a couple of years ago pointing out the confusion. https://redfin.engineering/two-commits-that-wrecked-the-user...
A good conversation on HN followed. https://news.ycombinator.com/item?id=14712269
I've long wished git checkout (and now, git restore) would save the contents of blown-away worktree files somewhere (e.g. a throwaway stash) so that they could be retrieved from the reflog or something.
In my mind's eye, the command would be something like "git trash" and it would throw your changes into a trash can, where you could fetch them back out again later, until the GC erased them in ~30 days or so.
This would be an amazing feature for nearly all git commands that affect the worktree. Many times I've done `git checkout ./src` to blow away "unrelated" files forgetting that the file I was just working on was in that directory. Whenever I teach git to a new-hire I always talk about wanting revision-control for revision-control.
Magit can do this. See https://magit.vc/manual/magit.html#Wip-Modes
For git branch -c one could say that the "branch" command should not do checkout-business.
Either switch/checkout will create or branch will switch.
I don’t see why choosing one for double duty is inherently worse than the other.
But I do consider your proposal of `git branch —create` as a poor command for create and switch branch.
The `git checkout -b` and `git switch -c` docs specifically note that they're shortcuts for going a git branch then a git checkout/switch.
The git switch subcommand's description is "Switch branches", so clearly it, too, is intended to handle a subset of the cases where you want to do something with a branch. Switching to a branch that doesn't already exist is a special case of git-switch's main purpose, and you have to be explicit about it. Further, when you create a new branch, you just about always want to switch to it (because while you can do some things with a branch that's not checked out, most commands are designed to work on the currently-checked-out branch), so what's the point in forcibly separating the commands?
> But a shortcut for "git branch -c" would be better if you want to keep the "create and switch" shortcut IMO.
Strongly disagree. In Git, creating a branch is a much smaller action than changing the state of your checkout. It makes much more sense to have the branch creation as the side effect than the other way around.
And all of git's branches are pretty light and flexible, at least compared against the branches of the previous generations of version control systems..
But yeah. That's definitely not what they were intending.
I tend to prefer smaller vocabularies tools: less to remember if you know what you are doing.
It can have new commands:
- `gitlite create` vs `git init`
- `gitlite branch create feature-dom` vs `git checkout -b feature-dom`
- `gitlite time-travel cfae736` vs `git checkout cfae736`.
- `gitlite undo cfae736` vs `git reset cfae736 --hard`
- gitlite release create v4.2` vs `git tag v4.2`.
Each command will call the translated `git` command, and perhaps improve upon the output from the command.
