Mistake in the new "git restore" section?

[Fabien-jrt]

The "undo things" section mention that:

"It’s important to understand that git restore --staged <file> is a dangerous command. Any local changes you made to that file are gone — Git just replaced that file with the most recently-committed version. Don’t ever use this command unless you absolutely know that you don’t want those unsaved local changes."

I realised that the warrning added is more about the git restore <file> command.
Indeed, this command throw away my local work.

The git restore --staged <file> command, however, unstage the file in question.

The only thing I found about it is this comment, originally posted by @HonkingGoose in the pull request conversation.

Do I missed something?
Do we need to remove the --staged flag?

[HonkingGoose]

Good catch!

I've tried to get my work destroyed by using git restore --staged and it doesn't work, because I still have a saved copy in the working directory.

What DOES throw away my work is using git restore before any changes have made it to the staging area.

I'm not sure if there are any edge-cases where you would be able to permanently throw your work away with git restore --staged <file>? Maybe when some changes are staged, and some other changes are not staged, especially if you edit the same lines. Maybe @ben can chime in on possible edge-cases.

I suspect you're right though and I just made a error, and the warning should really be about git restore <file>... 👍

[ben]

Hmm yeah, looks like I misread the documentation as well. If it's only changing the index, then the most you can lose is the carefully-constructed "draft" of your next commit, which you can rebuild from the changes that are still in your working directory.