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: <a href="http://archive.is/EZX1O" rel="nofollow">http://archive.is/EZX1O</a>
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.<p>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.<p>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.<p>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.<p>Learning about version control, especially Git, is the most important thing a software developer can learn as early as possible in his career.
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?<p>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.<p>If there is anything positive to take away from this,it should be to learn to consider risk management.<p>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.<p>EDIT: archived <a href="http://web.archive.org/web/20170818080940/http://cc.bingj.com/cache.aspx?d=1462716999241&mkt=de-DE&setlang=en-US&w=xEsMxqoa0KJSwMsTh3p_8w2qryykfDvB" rel="nofollow">http://web.archive.org/web/20170818080940/http://cc.bingj.co...</a>
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.
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.
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.<p>A developer uses source control, it's as easy as that.
As a product developer, when a user of my software "makes a mistake" my first response is to ask myself "What could <i>I</i> have done to avoid the user making this mistake?"<p>As Jeff Attwood says:<p>"a well-designed system makes it easy to do the right things and annoying (but not impossible) to do the wrong things."<p><a href="https://blog.codinghorror.com/falling-into-the-pit-of-success/" rel="nofollow">https://blog.codinghorror.com/falling-into-the-pit-of-succes...</a>
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.<p>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.<p>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.
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.<p>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.
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.
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...
"This is Git. It tracks collaborative work on projects through a beautiful distributed graph theory tree model.<p>Cool. How do we use it?<p>No idea. Just memorize these shell commands and type them to sync up. <i>If you get errors, save your work elsewhere</i>, delete the project, and download a fresh copy."<p>- <a href="https://xkcd.com/1597/" rel="nofollow">https://xkcd.com/1597/</a><p>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<p><a href="https://github.com/Microsoft/vscode/issues/32459" rel="nofollow">https://github.com/Microsoft/vscode/issues/32459</a>
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.
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.<p>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.<p>Please always err on the side of not losing data, even if it means keeping around "annoying" extra tabs.