Developer accidentally deletes 3 months of work with Visual Studio Code(cc.bingj.com)
cc.bingj.com
Developer accidentally deletes 3 months of work with Visual Studio Code
http://cc.bingj.com/cache.aspx?d=1462716999241&mkt=de-DE&setlang=en-US&w=xEsMxqoa0KJSwMsTh3p_8w2qryykfDvB
74 comments
The original Github issue seems to have been deleted, but here's a fresher cache that includes a response from a VS Code Microsoft employee, including a pic of what the warning dialog looks like: http://archive.is/EZX1O
Thanks, that answer actually adds some very important context!
Yeah, I actually got this dialog once and immediately clicked on 'cancel' to make sure I understood what the command did.
Personally I think this little detail changes the whole situation. And that's not even taking into account the idiocy of not having a backup and not incrementally adding the project to some form of version control.
Hell, even for all but the simplest TOY project I create a git repository and push it to gitlab!
Personally I think this little detail changes the whole situation. And that's not even taking into account the idiocy of not having a backup and not incrementally adding the project to some form of version control.
Hell, even for all but the simplest TOY project I create a git repository and push it to gitlab!
This didn't happen to me and I'd like to think I'm being objective here - the dialog says:
> Are you sure you wish to discard ALL changes? This is IRREVERSIBLE!
Yes, very scary, like many warnings that some systems teach us to ignore.
It doesn't say what "changes" will be discarded. Are those the changes it made since the IDE was installed? Did the IDE make changes? Some kind of project files or directories? Some kind of setup? Is a novice supposed to know this?
Even on the home-grown IDE I use at work, it saves backups in a trash area when you delete files in case you accidentally delete something you don't intend to. (Actually, I got very concerned once thinking I had deleted something I hadn't committed yet... as I recall it was a false alarm, but I was pleased that my concern was misplaced.)
And given that a lot of other people have experienced this, I'd say there is evidence that this is a UX (User eXperience) problem, not necessarily a PEBCAK (Problem Exists Between Chair and Keyboard):
https://social.msdn.microsoft.com/Forums/expression/en-US/b3...
> Are you sure you wish to discard ALL changes? This is IRREVERSIBLE!
Yes, very scary, like many warnings that some systems teach us to ignore.
It doesn't say what "changes" will be discarded. Are those the changes it made since the IDE was installed? Did the IDE make changes? Some kind of project files or directories? Some kind of setup? Is a novice supposed to know this?
Even on the home-grown IDE I use at work, it saves backups in a trash area when you delete files in case you accidentally delete something you don't intend to. (Actually, I got very concerned once thinking I had deleted something I hadn't committed yet... as I recall it was a false alarm, but I was pleased that my concern was misplaced.)
And given that a lot of other people have experienced this, I'd say there is evidence that this is a UX (User eXperience) problem, not necessarily a PEBCAK (Problem Exists Between Chair and Keyboard):
https://social.msdn.microsoft.com/Forums/expression/en-US/b3...
The sad part is that he didn't learn his lesson. The problem obviously isn't with Visual Studio Code, but with Git (or whatever version control software he tried out). It seems that he didn't know anything about using git and accidentally checked out a bare repo instead of adding his files to stage. From his post, he says he's using windows and he's used to things going into the recycle bin, something a Linux tool like Git obviously isn't going to do. So this is a mismatch between a beginner software developer on windows never having used Git before, and the mental model of Linux tools like Git.
I agree with him that Visual Studio Code could probably have designed their warning message a bit better, for people like him who have no experience with Git.
And now to the sad part, having accidentally deleted all his files while trying out Git; he will probably never touch Git again! So instead of learning the lesson he should have learned; always use version control on everything, what he did learn was; Git is harmful, don't use it.
Of course it also kinda seems like he blames VS Code and doesn't understand that it was the fault of Git, but that won't make him start using Git anytime soon.
Learning about version control, especially Git, is the most important thing a software developer can learn as early as possible in his career.
I agree with him that Visual Studio Code could probably have designed their warning message a bit better, for people like him who have no experience with Git.
And now to the sad part, having accidentally deleted all his files while trying out Git; he will probably never touch Git again! So instead of learning the lesson he should have learned; always use version control on everything, what he did learn was; Git is harmful, don't use it.
Of course it also kinda seems like he blames VS Code and doesn't understand that it was the fault of Git, but that won't make him start using Git anytime soon.
Learning about version control, especially Git, is the most important thing a software developer can learn as early as possible in his career.
You're blaming the victim. Yes, it's better to know git than not knowing it, but the developer was merely tossing around with the various options of the IDE. It shouldn't be that easy to make an operation with such disastrous results. It is the responsibility of the product designers to prevent this.
I think the question is more likely: should an operation like this be possible at all? VSCode already gives you a big warning (as shown in the issue) that "discarding changes" is irreversible but it does not explain what "discarding changes" means.
When people empty their recycle bin they kind of understand what is going to happen. Discarding changes speaks to me but evidently not to this person. Personally I tend to put my code in Dropbox in early stages as git commits do not make much sense (of course one can squash everything and do a rebase but that is advanced git already).
When people empty their recycle bin they kind of understand what is going to happen. Discarding changes speaks to me but evidently not to this person. Personally I tend to put my code in Dropbox in early stages as git commits do not make much sense (of course one can squash everything and do a rebase but that is advanced git already).
There's a bug out for not deleting files that haven't been added to the repository when discarding changes:
https://archive.is/GisMJ
https://archive.is/GisMJ
I was surprised when the exact same thing happened the first time I "played" with Code :D ! Discovering this the hard way.
Well not that hard, because of course I tried it first on a copy of the project so haven't lost anything (if not time).
But even if I agree that what is going to happen is unclear for some (included me at the time), and a total wipe of your work is excruciating, you don't "try things" on the only copy of 3 months of work.
Well not that hard, because of course I tried it first on a copy of the project so haven't lost anything (if not time).
But even if I agree that what is going to happen is unclear for some (included me at the time), and a total wipe of your work is excruciating, you don't "try things" on the only copy of 3 months of work.
I think the obvious thing that VSCode could've done to avoid this disaster was moving files to recycle bin instead of deleting permanently on discard. You or OP might say why would the behavior of a Linux tool like git move to recycle bin? Well, TortoiseGit on Windows (git client) (or even going as far back as TortoiseSvn) will always move files to recycle bin when you discard changes. If they can, there's very little excuse why VSCode can't. There is also very little maintenance overhead for a user. Once in a while you notice your recycle bin isn't empty and you go and empty it.
If he has that large of a codebase, he may be a VS Code newbie and/or a git newbie but he isn't s computer newbie.
Anyone who has anything important on a computer should know to back it up somewhere.
Anyone who has anything important on a computer should know to back it up somewhere.
One of the earliest lessons I learned using a computer is that you don't toss around with options unless you have backups and/or already use form of (distributed!) version control.
Even most of my relatively computer-illiterate friends and family members do rudimentary backup for their stuff (usually in the form of emailing themselves or just creating a copy).
Even most of my relatively computer-illiterate friends and family members do rudimentary backup for their stuff (usually in the form of emailing themselves or just creating a copy).
The victim failed the first rule of using a computer, backup your work.
A three month project without backup or version control shows a lack of basic training.
I wish schools and universities would teach version control on day one of CS courses.
A three month project without backup or version control shows a lack of basic training.
I wish schools and universities would teach version control on day one of CS courses.
Certainly there might be room for improvement. But the warning was pretty clear I feel.
At some point you have to take responsibility for knowing your tools. This is a professional.
At some point you have to take responsibility for knowing your tools. This is a professional.
> This is a professional.
He might know how to write code, but obliviousness towards source control (and backups, for that matter) is a HUGE indicator of him not being a professional.
He might know how to write code, but obliviousness towards source control (and backups, for that matter) is a HUGE indicator of him not being a professional.
Yep. Also a quick search of his name reveals a bunch of Quora responses some of which are a bit disturbing. That's not terribly professional either.
I would agree. User friendliness isn't a bad goal for any piece of software, but there is a certain level of knowledge we can expect from a professional. Knowledge of their chosen tooling is one of them I feel.
It's not even knowledge of tooling, it's knowledge of practices. How would you feel about an electrician who doesn't properly ground the circuit he's about to work on? That's how I feel about a programmer who doesn't take backups of his code in short intervals (which is a big part of what VCSs do).
Come on though - there are so many ways you can lose data. Having 3 months of work not backed up in any way is foolhardy in the extreme. Hard disk failure, power surge, robbery, data corruption, coffee, fire/flood.. Personally I err on the side of paranoia with these things.
>You're blaming the victim.
The victim did it to themselves, it's like playing with a loaded gun then complaining when you accidentally shoot yourself in the face. A bad workman always blames their tools. At the very least they should have learnt Git.
The victim did it to themselves, it's like playing with a loaded gun then complaining when you accidentally shoot yourself in the face. A bad workman always blames their tools. At the very least they should have learnt Git.
The victim is not at fault.
1. On Windows, the standard mechanism to delete files it to move/ to 'Recycle Bin' - why did the IDE override the functionality?
2. In git, this action is equivalent to 'git checkout' that will show you a message to stash. In earlier versions of git, where message to git stash are not shown, the files are not deleted from disk.
The problem highlighted here is a genuine one, the IDE MUST and MUST show warning before such destructive operations.
1. On Windows, the standard mechanism to delete files it to move/ to 'Recycle Bin' - why did the IDE override the functionality?
2. In git, this action is equivalent to 'git checkout' that will show you a message to stash. In earlier versions of git, where message to git stash are not shown, the files are not deleted from disk.
The problem highlighted here is a genuine one, the IDE MUST and MUST show warning before such destructive operations.
> 1. On Windows, the standard mechanism to delete files it to move/ to 'Recycle Bin'
It is the standard mechanism when you are working with Windows Explorer (explorer.exe). However, if you try doing it via any API, it is far from trivial. All of the standard file delete operations in all platforms that I have worked with delete the files straight away. From developer's point of view, Recycle Bin is just a Windows Explorer's concept and not something that other applications should know how to work with.
It is the standard mechanism when you are working with Windows Explorer (explorer.exe). However, if you try doing it via any API, it is far from trivial. All of the standard file delete operations in all platforms that I have worked with delete the files straight away. From developer's point of view, Recycle Bin is just a Windows Explorer's concept and not something that other applications should know how to work with.
Many IDEs delete files permanently, not just VSCode.
VSCode has second confirm and warning you: "This is IRREVERSIBLE!"
VSCode has second confirm and warning you: "This is IRREVERSIBLE!"
I 100% agree that the warning is displayed. But can't we not make that a bit more user-centric - to say, "You are going to remove all your files from your disk. This is IRREVERSIBLE."
Would that not be a better info/warning message to a user?
And if many IDEs delete files permanently, why can't VSCode start to do what's the right thing - move it to Trash/Recycle Bin.
Many startups (like Slack) didn't copy what all did, they did the right thing.
Would that not be a better info/warning message to a user?
And if many IDEs delete files permanently, why can't VSCode start to do what's the right thing - move it to Trash/Recycle Bin.
Many startups (like Slack) didn't copy what all did, they did the right thing.
I think that the first lesson that he should learn is the need for regular backups.
In fact, I am not even sure he meant to use git ("I hadn't commited any of them to any repository"). If it that's the case, I would understand why he did such a mistake:
* Open the folder in VS Code
* Explore around, discover the Git tab on the left, "This workspace isn't yet under git source control", press the button
* "Whops, I didn't want to do this", check around and see that there is a button to "clean the changes"
* Destroy 5000 files by mistake.
In any case, I don't understand why developer oriented tools rarely take into account the fact that developers too make mistakes, and they should have the ability to undo them. This is especially true with Git, where the UI is in my opinion particularly convoluted and error prone.
In fact, I am not even sure he meant to use git ("I hadn't commited any of them to any repository"). If it that's the case, I would understand why he did such a mistake:
* Open the folder in VS Code
* Explore around, discover the Git tab on the left, "This workspace isn't yet under git source control", press the button
* "Whops, I didn't want to do this", check around and see that there is a button to "clean the changes"
* Destroy 5000 files by mistake.
In any case, I don't understand why developer oriented tools rarely take into account the fact that developers too make mistakes, and they should have the ability to undo them. This is especially true with Git, where the UI is in my opinion particularly convoluted and error prone.
This is it. I find myself making backups of my source controlled folder just in case something I do with SVN messes things up. The absurdity of this is not lost on me.
This is one of the reasons I'm happy to have Time Machine on macOS. I've had times where I accidentally removed files due to a careless rm -rf in the terminal, as well as lost file changes due to mistakes with git. If you have local backups enabled, it's easy to recover reasonably recent files and changes. Admittedly, it hasn't happened to me in a fairly long time... But knowing you have some kind of safety net is reassuring.
A lot of our tooling and operating systems were designed for a different time, and their age is really starting to show in cases like these. Fault tolerance is incredibly important, and it has taken a backseat position for far too long.
A lot of our tooling and operating systems were designed for a different time, and their age is really starting to show in cases like these. Fault tolerance is incredibly important, and it has taken a backseat position for far too long.
The problem with warning messages is that people will often still just click through them. Someone WILL 100% still click through it and then complain. This is the problem with power tools. They can be very convenient and useful to users who know what they're doing, but harmful to users who are just clicking buttons.
Then you have the option of just saying "you're an idiot" or developing a safety net around the feature so the action can be undone.
Then you have the option of just saying "you're an idiot" or developing a safety net around the feature so the action can be undone.
I know nothing about Visual Studio Code and very little about anything VS in fact, so I have no idea how much is VS's fault and how much is the user's, but seriously, how on Earth is it possible to have 3 months of work not backed up or source controlled in any way?
I once had a nasty file system corruption due to disconnecting the power cord that corrupted my (local) git repo and almost made me lose a day of work. Even with source control there are risks.
If there is anything positive to take away from this,it should be to learn to consider risk management.
If you write code even, say, once every week and haven't yet bothered to learn how to use source control, you owe it to your mental sanity to do it now.
EDIT: archived http://web.archive.org/web/20170818080940/http://cc.bingj.co...
I once had a nasty file system corruption due to disconnecting the power cord that corrupted my (local) git repo and almost made me lose a day of work. Even with source control there are risks.
If there is anything positive to take away from this,it should be to learn to consider risk management.
If you write code even, say, once every week and haven't yet bothered to learn how to use source control, you owe it to your mental sanity to do it now.
EDIT: archived http://web.archive.org/web/20170818080940/http://cc.bingj.co...
I never trust anything but the commandline when it comes to git. Then I know full and well what I'm doing regardless of the editor. When there are too many icons and buttons to click I don't like to have to remember what they all mean, or how well they map to the underlying core git concepts.
I know what you mean, but for all its faults I like Sourcetree here: it doesn't use anything but what git does. You have a staging area, adding, interactive rebasing, everything uses gigs proper terminology. As opposed to the GitHub for Windows app for example which has new words.
+1 Graphical tools may help when presenting changes in a repo, but when it comes to making changes I too prefer the CLI.
The commandline offers just as much opportunity to screw up your repository as a GUI does, if not more.
Here's the description for the man-page for git-clean:
> git-clean - Remove untracked files from the working tree
https://git-scm.com/docs/git-clean
Now I would call that description very precise and readable.
Here's the GUI's warning:
> Are you sure you wish to discard ALL changes? This is IRREVERSIBLE!
What changes? He didn't change anything. Did the GUI change something? Maybe it did. Maybe nothing will happen.
Foolish not to back-up before experimenting? Sure. But GUI's imply friendliness to the inexperienced. This seems like bad UX.
> git-clean - Remove untracked files from the working tree
https://git-scm.com/docs/git-clean
Now I would call that description very precise and readable.
Here's the GUI's warning:
> Are you sure you wish to discard ALL changes? This is IRREVERSIBLE!
What changes? He didn't change anything. Did the GUI change something? Maybe it did. Maybe nothing will happen.
Foolish not to back-up before experimenting? Sure. But GUI's imply friendliness to the inexperienced. This seems like bad UX.
This is a valid complaint. You simply don't design UI that allows to delete a large number of files with a press of a single button. That he didn't have backups is irrelevant. Even accidentally deleting fresh changes is quite damaging. VS Code doesn't say anything about Git, or what Git is. You can't expect anyone who downloads MS software to be a Git expert.
[deleted]
But it wasn't a single button, there was a warning message:
https://archive.fo/EZX1O
See joaomoreno's comment on that page.
See joaomoreno's comment on that page.
It may be victim blaming, but having 3 months of work and it only exists on one hard drive on one computer isn't very bright. He learned the hard way. I mean honestly, disk drives fail. PCs break. The code should never be in only one place regardless.
Also, coming from VSS to Git has been, and still is, one of the hardest things I do as a windows dev. I hate git. It is non-intuitive and I have accidentally deleted my work before also, the difference being that I have it stored else where to get it too.
So, his hard drive could die. He could have a virus or a crypto infection. All would delete his work.
A developer uses source control, it's as easy as that.
A developer uses source control, it's as easy as that.
Quite apart from the problem of total code loss there's the lack of a safe way to prototype changes - how the hell does he revert in a situation where he inadvertantly breaks his previously working code?!
If this guy did any kind of decent IT or programming course you would think they would have covered at least backing up at some point. If he has done a course and still ended up in this situation I'm tempted to say it's time for him to find a new career.
If this guy did any kind of decent IT or programming course you would think they would have covered at least backing up at some point. If he has done a course and still ended up in this situation I'm tempted to say it's time for him to find a new career.
A developer agrees.
No source control, no backups and you "play" with a new software to see how it handles 5000 files?
Well... not sure what to say here..
As a product developer, when a user of my software "makes a mistake" my first response is to ask myself "What could I have done to avoid the user making this mistake?"
As Jeff Attwood says:
"a well-designed system makes it easy to do the right things and annoying (but not impossible) to do the wrong things."
https://blog.codinghorror.com/falling-into-the-pit-of-succes...
As Jeff Attwood says:
"a well-designed system makes it easy to do the right things and annoying (but not impossible) to do the wrong things."
https://blog.codinghorror.com/falling-into-the-pit-of-succes...
He says that it wasn't in a repo, so it's a bit weird that it would delete all his files, it looks more like he had an initialised repo and hadn't committed the files yet.
I don't even know how you could work 3 months without committing, even working on a throwaway thing for more than a few hours I make a new local repo, it doesn't cost much.
Also the files are not gone, they are still on the hard-drive/SSD it's not that hard to look up file recovery software.
I don't even know how you could work 3 months without committing, even working on a throwaway thing for more than a few hours I make a new local repo, it doesn't cost much.
Also the files are not gone, they are still on the hard-drive/SSD it's not that hard to look up file recovery software.
This post shows the likely sequence of actions that makes it happen: https://stackoverflow.com/a/33235641
It seems to have happened to rather a lot of people https://social.msdn.microsoft.com/Forums/expression/en-US/b3...
It seems to have happened to rather a lot of people https://social.msdn.microsoft.com/Forums/expression/en-US/b3...
Exactly, a good portion of deleted files could probably be salavaged using "Recuva" right away, for example
Exactly, all the deletion does is remove the file system connection to the location of the data on disk. Someone needs to get in touch with this guy and tell him to stop using that drive!
He deleted his profile, rightly so - thats no way to act on github, open forum for pretty much every web developer out there. Not making a good name for yourself
I predict one day we will look back and be horrified that there was ever a time where you can't just roll back an entire system to an arbitrary timestamp to undo accidental changes.
In some sense this is already achievable if you just always work inside a Dropbox folder (which keeps a 30 day history of any synced changes). But resources aren't yet cheap enough for all changes to be immutable.
In some sense this is already achievable if you just always work inside a Dropbox folder (which keeps a 30 day history of any synced changes). But resources aren't yet cheap enough for all changes to be immutable.
On mac os you have system built-in version control on most text based file by default.
I recovered lost work with it in a discard once (discarded on the wrong branch and no stash to reapply).
https://support.apple.com/kb/PH18862?locale=en_US
His story is a little funny and a little sad. I had a similar experience but I was much more cautious. I had actually backed up my project through GitHub desktop and committed it before formatting my computer. After cleaning and setting the system back up, I lost a days worth of work. I was 100% sure I had committed it. When I started back where I was and committed my changes, I checked the web Github to ensure that the changes were still submitted and they weren't. There was a bug with Windows 10 and Github that caused it. After that I decided to use Google Drive to backup my Github upon changes. Don't try to use Github folders and Google Drive folders as the same directories. Something weird happens and only one will work. Now I make submissions to Github and have a duplicate folder (using relative paths in my project) in my Google drive. Alternatively, you can submit your changes through the Github website, but it takes forever.
I learned about "git checkout ." the hard way once, too. Only lost three hours then, though.
But, for real, 3 months of work and not a single backup?
Really feel for the guy. Hasn't happened to me, but I would hope a developer friendly editor would give warnings about when something like this could happen. Does VS Code have a tutorial? Haven't used it before, can't say I am inclined to right now...
My response to this person would be:
well you're going to have to restore from backup.
Oh you don't have a backup? Why not? (Some excuse) LOLZ
well you're going to have to restore from backup.
Oh you don't have a backup? Why not? (Some excuse) LOLZ
[deleted]
"This is Git. It tracks collaborative work on projects through a beautiful distributed graph theory tree model.
Cool. How do we use it?
No idea. Just memorize these shell commands and type them to sync up. If you get errors, save your work elsewhere, delete the project, and download a fresh copy."
- https://xkcd.com/1597/
I think MS would do well to just buy this comic from Randall Munroe and display it on git init. In 10 seconds you get a more useful and realistic appraisal of the tool than you will from reading the docs for an hour. You heard me right: Docs by Meme.
Cool. How do we use it?
No idea. Just memorize these shell commands and type them to sync up. If you get errors, save your work elsewhere, delete the project, and download a fresh copy."
- https://xkcd.com/1597/
I think MS would do well to just buy this comic from Randall Munroe and display it on git init. In 10 seconds you get a more useful and realistic appraisal of the tool than you will from reading the docs for an hour. You heard me right: Docs by Meme.
I have seen people learn to source control the hard way multiple times, but usually they were saved (at least partially) by the local history feature in IDEs. This guy was hit very hard, I feel sorry for him.
This got "fixed" in #32459
https://github.com/Microsoft/vscode/issues/32459
https://github.com/Microsoft/vscode/issues/32459
Pro-tip : you can keep your little projects in a Dropbox folder. Will keep track of your file changes automatically and can help restore deleted files / or restore them to earlier versions.
Streisand effect is taking off: https://github.com/Microsoft/vscode/issues/32795
This is like someone is trying to learn how to cook the first time and burned the house down. Instead of blaming himself, he blame the stove and fire.
Well, that's not very positive... but I can relate. VS Code lost some work of mine on the first day I tried it, so I decided not to continue using it. It wasn't super important so I wasn't angry, but it was a good chunk of code I had just spent probably 45 minutes writing and debugging.
You could argue it was my fault because I didn't stage and commit the new file, but there's no reason to close a buffer just because the backing file is gone. Close it if I say so, otherwise keep it open with the last-seen contents of the file. This has always worked fine in Sublime.
Please always err on the side of not losing data, even if it means keeping around "annoying" extra tabs.
You could argue it was my fault because I didn't stage and commit the new file, but there's no reason to close a buffer just because the backing file is gone. Close it if I say so, otherwise keep it open with the last-seen contents of the file. This has always worked fine in Sublime.
Please always err on the side of not losing data, even if it means keeping around "annoying" extra tabs.
Excessive automation considered harmful: even if you want something to happen 99% of the time, it should still be a manual operation. Otherwise, it will bite 100 of your 10,000 users at least once.
If it's a destructive operation, yeah. I was really, genuinely surprised that their editor works like that. As you say, it's not something that will bite you often, but when it bites, it could be pretty painful.
Actually you can control this behaviour with "workbench.editor.closeOnFileDelete": false
its always sad to see people learn the lesson of source control the hard way.
This is more of a backup lesson.
I would call it a UX design lesson, primarily, although all undesirable changes are also backup lessons.
Exactly. Also, source control is not backup. It is possible for bugs in git or mistakes in your workflow to mess up all the copies of your repository.