It had a reasonably clear warning, though; a screenshot is included in this response from the devs. But note that the response also links to another issue where some bikeshedding on the warning occurred and the warning was ultimately improved.
When you sell hammers you’ll likely have people using them to hit their own heads, which, understandably, they will put the hammer at fault. Now, we already put a big don’t hit this on your own head label on our hammer. Should we actually prohibit people from head hitting with our hammers? Probably not, since some users still want to hit heads with it. It’s just how hammers work.
I disagree that that warning is reasonably clear. Even the comment that included it has the line of thought, where the user, not knowing what terms git uses thinks that they just did an action that is going to change each of their files. It makes sense that they’d want to discard those changes. That user then goes on with some snark about not wanting to learn any more about what they are playing with and that other programs would do the same, but “discard changes” seems like it would have a clear meaning to someone who doesn’t know git.
The warning says it isn’t undoable but also doesn’t clarify that the files themselves are the changes. Should probably have a special case for if someone hits discard changes on a brand new repository with no files ever checked in and hits discard on a large number of files instead of checking them in. Even a “(This deletes all of the local files!)” would make it clear enough to say what the warning is really about.
That depends on what you map “discard” to in your mental model. Whoever designed the VSCode feature chose to associate it with reset+clean, rather than just reset. Presumably that’s why they called the menu option “discard” rather than “reset”. (But I agree that this is a surprising choice, and that they managed to make an already-famously-bad UX even worse.)
If you don’t know what git is, you should probably avoid choosing the “confirm” option when you’re warned that an operation is dangerous.
That said, I think the change they ultimately made in the linked issue, which words the warning differently and, more importantly, provides an option to only discard changes to already-tracked files, is a vast improvement.
Well, yeah, that’s why they updated the warning pop-up. It’s still the case that the user didn’t bother to find out what the warning meant before choosing the inherently destructive option.
Here’s the revised pop-up, according to the linked ticket:
I haven’t checked the current behavior (this whole incident was seven years ago).
It had a reasonably clear warning, though; a screenshot is included in this response from the devs. But note that the response also links to another issue where some bikeshedding on the warning occurred and the warning was ultimately improved.
OK this is hilarious
I disagree that that warning is reasonably clear. Even the comment that included it has the line of thought, where the user, not knowing what terms git uses thinks that they just did an action that is going to change each of their files. It makes sense that they’d want to discard those changes. That user then goes on with some snark about not wanting to learn any more about what they are playing with and that other programs would do the same, but “discard changes” seems like it would have a clear meaning to someone who doesn’t know git.
The warning says it isn’t undoable but also doesn’t clarify that the files themselves are the changes. Should probably have a special case for if someone hits discard changes on a brand new repository with no files ever checked in and hits discard on a large number of files instead of checking them in. Even a “(This deletes all of the local files!)” would make it clear enough to say what the warning is really about.
Even if you know git, you wouldn’t assume that “discard all changes” affects untracked files. It’s bad design all around
That depends on what you map “discard” to in your mental model. Whoever designed the VSCode feature chose to associate it with reset+clean, rather than just reset. Presumably that’s why they called the menu option “discard” rather than “reset”. (But I agree that this is a surprising choice, and that they managed to make an already-famously-bad UX even worse.)
My git gui has a tick box on that prompt to specifically include added files. I now see why haha
Well, yeah, that’s why the linked ticket led to a massive improvement:
That’s way better. His sacrifice benefited others in the end.
(I haven’t checked what the warning says today.)
If you have no idea what Git is, that warning message is not telling you you’re about to delete 5000 files.
But I wonder if this person maybe does know about Git because they used the word „stage“.
If you don’t know what git is, you should probably avoid choosing the “confirm” option when you’re warned that an operation is dangerous.
That said, I think the change they ultimately made in the linked issue, which words the warning differently and, more importantly, provides an option to only discard changes to already-tracked files, is a vast improvement.
“Discard changes” is usually equivalent to “cancel” or “quit without saving”. Not shift+delete files lol.
Well, yeah, that’s why they updated the warning pop-up. It’s still the case that the user didn’t bother to find out what the warning meant before choosing the inherently destructive option.
Here’s the revised pop-up, according to the linked ticket:
I haven’t checked the current behavior (this whole incident was seven years ago).