git restore --staged file # reset the index from HEAD
git restore --worktree file # reset the worktree from the index
git restore --source=HEAD --staged --worktree file # reset both the index and worktree from HEAD
Still in development [1] so if you think something can be improved, I'd love to hear it.
[1] https://github.com/git/git/blob/pu/Documentation/git-restore...
First, the default source changes depending on the target. In my opinion it would be more intuitive and simple if the default source is always HEAD. The documentation for --source in your link probably makes sense for a git developer, but not at all for a user. (Especially the part about its default value if absent).
Second, rename "--staged" to "--index".
So in summary, to update your examples, how about:
git restore --index file # reset the index from HEAD
git restore --worktree file # reset the worktree from HEAD
git restore --worktree --source=index file # reset the worktree from the index
git restore --index --worktree file # reset both the index and worktree from HEAD
git restore file # reset the worktree from HEAD
So `git restore file` should reset the worktree, if you allow an unflagged version of that command.
It still restores worktree from the index though. But if your workflow ignores the index, then index should be the same as HEAD. "restoring from index" and "restoring from HEAD" will mean the same thing.
Would you mind giving the current commands to achieve the three things you just listed?
That way I learn the future restore command along with the current approach and you description. T
"git restore --worktree" is the same as "git checkout -- file".
"git restore --source..." should be the same as "git reset --hard -- file" if --hard was made to work with individual files.
Though "git restore" should make it clear (or clearer) to the user what they want to restore without resorting to more mysterious options like --hard/--soft. So if that's not obvious from my examples, I think I've failed :)
I've tried maybe 3 different GUIs for git and none of them really seemed to help that much. However my usage of git is pretty basic, with branches and tags being about as complex as I get.
The problem is, in the end, you'll still need to know the original git commands with all their quirks in addition to the easier commands, because that's what you'll find on stackoverflow or when asking colleagues or inside of error messages. And those command names will either clash with the names used in plain git or are different partially-overlapping concepts (`git reset` is the worst offender here). So eventually you'll need to memorize twice as many things.
