Yeah. That’s discussed in more detail in the code change that resulted from the issue report.

It’s a ballsy move by the VSCode team to not only include git clean but to keep it after numerous issue reports.

As others discussed in that thread, git clean has no business being offered in a graphical menu where a git novice may find it.

That said, I do think the expanded warning mesage they added addresses the issue by calling out that whatever git may think, the user is about to lose some files.

Apparently, it means changes to the directory structure and what files are in them, not changes within the files themselves. It really ought to be more clear about this.

“Changes” encompass more than you think. Creating / Deleting files are also changes, not just edits to a file.

• If the change is an edit to a tracked file, “Discard Changes” will reverse the edit.
• If the change is deleting a tracked file, “Discard Changes” will restore it back.
• If the change is a new untracked file, “Discard Changes” will remove it as intended.

It can also be all of them at the same time, which is why VSCode uses “Changes” instead of “Files”.

It appears that the behavior actually included a git clean. Which is insane in my opinion.

Yeah. Building a convenient accessible context free way to run git clean…sure feels like the actions of someone who just wants to watch the world burn.

Yeah, it’s unclear to me at the time if the dialogue box in the screenshot appeared when doing a select all operation, but it reads as though the OP dev didn’t understand git, discarded their work, and got upset that it was an option.

Realistically if the dialogue box appeared, I’m not sure there would be anything else the IDE could do to prevent the dev from themselves. Perhaps reject operations affecting 5000 files? But then you’ll just have someone with the same issue for 4000 files.

He said they’re not going to change it, just make the dialog a lot more clear and add a second button to it that will only do a reset without the clean.