imho the natural default for any of these types of commands should be to reset the worktree, never the index. In my experience, people almost always want to review a file before they stage it, even if it's coming from HEAD.
So `git restore file` should reset the worktree, if you allow an unflagged version of that command.
"git restore file" does reset worktree. Sorry I didn't mention it. If neither --worktree or --staged is present, the default target is the worktree.
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.
I can't test the index. If the index and workspace are different, the index is wrong. I would like an option to make the index go away (or else become a buildable filesystem dir), and stash whatever I don't want to commit yet.
> I would like an option to make the index go away
By Git design, you will have to face the index when you have merge conflicts. I don't know how to avoid that (and now is not the time for fundamentally change how conflict resolution is done).
But yeah, the other times, I think you can just live just fine without knowing or touching the index.
> I can't test the index.
I'm not trying to convince you to use the index. But to me, the way I test the index is commit it. Then I could use "rebase -i" to revisit the old commits (i.e. the index content) and test or make more fixes if needed.
So `git restore file` should reset the worktree, if you allow an unflagged version of that command.