Video summary
Dev Deletes 3 Months of Work, Blames Code Editor
Main summary
Key takeaways
Technological concepts & product behavior discussed
Git version control basics (for collaboration and rollback)
- Git is presented as a system to track code history via commits, where each commit records metadata such as:
- author
- timestamp
- change description
- A project’s history is likened to a linked list of commits, with the main branch typically deployed to production.
- A common workflow:
- Pull from remote
- Create a branch
- Code + commit
- Open a pull request (PR)
- Review/approve
- Merge to main
- Git uses a staging area (
git add) before committing.
Staging vs untracked files
- VS Code shows changes including modified, deleted, and new files.
- New files are untracked until staged, meaning they may not appear when comparing against earlier commits.
- Utility commands like
git cleancan remove untracked files.
The core VS Code/Git disaster scenario
- A user initializes a Git repository inside an existing folder containing about 5,000 files.
- The project files already exist, but they are untracked.
- In VS Code Source Control, the user clicks “Discard All Changes.”
- Intended expectation:
- It should only revert editor/source-control changes.
- Actual result:
- Files are permanently deleted from disk, not merely removed from the Git UI.
Why the deletion is permanent
- The video claims VS Code’s “discard all changes” triggers Git cleanup behavior (notably
git clean). - It then deletes files using low-level filesystem deletion (via POSIX
unlink), analogous torm -rf. - This explains why files may not go to the recycle bin.
Review / issue analysis and “fix timeline” (from the controversy)
Community responses
- Some users argue the warning was “valid,” but many victims report they never committed anything, so they had no version history to recover from.
- Multiple people describe similar incidents, suggesting it was not a one-off misunderstanding.
Root cause investigation
- Microsoft acknowledges there is supposed to be an obvious warning, while others claim the UI is misleading or the prompt is inadequate.
- The investigation attributed the behavior to how the feature interacts with Git’s handling of untracked files.
Recommended UX/behavior changes discussed
Potential remedies proposed:
- Improve prompt clarity (explicitly mentioning deleting from disk).
- Change default behavior to delete only tracked files.
- Remove the feature, though Microsoft reportedly resisted this due to:
- backwards compatibility
- support for power users who prefer the existing behavior
UX criticism also focused on the button label:
- “Discard All Changes” may be misleading because, in strict Git terminology, untracked files are not “changes.”
Actual product changes over time
- The warning message was updated to explicitly indicate deletion from disk.
- The prompt gained two options:
- Discard everything (original behavior)
- Discard only tracked files
- March 2022: VS Code adds Local History, enabling restoration of file contents (as a mitigation).
- February 2025: final fix—default “discard all changes” behavior is adjusted so deleted files go to the recycle bin/trash for easier recovery.
Key takeaways / “tutorial-style” points embedded in the video
- If a Git repo is newly initialized and your files are untracked, VS Code actions like discard all changes can effectively perform a force delete via untracked-file cleanup.
- For safety:
- stage and commit instead of discarding, or
- use Local History (when available).
- UI wording matters:
- features should clearly communicate whether disk deletion (not just version-control discard) will occur.
Main speakers / sources (as referenced)
- “Ghost” (the user who experienced the deletion)
- A Microsoft employee who apologizes / provides clarification
- Theer (initiated follow-up investigation / findings)
- Rem Corours (another commenter recounting past experience)
- “Issues Insights” / the video narrator (“Issues Insights” frame)