Microsoft Please Fix

The real issue is already going 3 months without source control.
- I have heard things from another apprentice who just does not use version control at all and the only copies are on his laptop and on his desktop. He is also using node.js with only 1 class and doesn't know about OOP (not sure if you even use that in js no clue 😅) and has one big file with 20k lines of code I have absolutely no clue how he navigates through it
  
  I know the type. Usually the kind of confident know-it-all who refuses to learn anything but delivers changes really quickly so management loves them. I had the misfortune to fix such a project after that 'rock-star' programmer left the company. Unfortunately the lack of professional standards in our industry allows people like that to continuously fail upwards. When I left the project they rehired them and let them design the v2 of the project we just fixed.
  
  Those are rookie numbers. I have at least a 35k one somewhere. More than one actually.
  People run their businesses on this.
  
  Reading this just give me a panic attack
  
  He just heard monoliths were in again
  
  Ey! Reminds me of my middle-school years! I still can't belive I made an entire game without a single class... Just storing info in arrays and writing in comments what location represents what data. But I was a literal child, too young to read guides or sit through "long" tutorials.
  I don't want to sound too mean, but whenever I see anything similar at work, I wish that person get a job they're actually good at. It's fine and all that the company started hiring actual programmers to fix things, but the fact that the old crew still fucks shit up with senior privileges is a major grievance.
- The person didn’t have any git repository; probably a new programmer that didn’t know how version control works and just clicked discard without understanding what that means in this situation

In case anyone else is wondering, or simply doesn't like reading screen shots of text, this is apparently a real report:
https://github.com/microsoft/vscode/issues/32405
- Steps to Reproduce:
  1.Go near this fucking shit editor.
  2.Commit the deadly sin of touching the source control options.
  🤣
  
  Ignore the scary warning VS Code shows you when you press the button.
  
  The dude ranted for awhile in the issue thread and closed the issue himself too! lol
- This link was included in the post but I realize that "source" was probably not the best label for it. Updated to make it more clear.

I feel bad for this kid. That really is a bad warning dialog. Nowhere does it say it's going to delete files. Anyone who thinks that's good design needs a break.
Half the replies are basically "This should be obvious if your past five years of life experience is similar to mine, and if it isn't then get fucked." Just adding insult to injury.
- I'm not great at English, but "discard all changes" shouldn't ever mean "Delete".
  
  In the context of version control it does. Discarding a change that creates a file means deleting the file.
  
  I'm pretty sure vscode shows a confirmation dialog when discarding changes will permanently delete a file. I've done that recently with temporary files that were no longer needed.
  
  the alternative to deleting is emptying the file contents, which is essentially the same...
- Also, why not send them to the recycle bin? I never really thought about it before, but that does seem a reasonable UX improvement for this case
  
  I wonder if there's already a git extension to automatically stash the working tree on every clean/reset/checkout operation...
  
  Because “the underlying Git nukes them right away, so why shouldn’t we perma-delete the files, too?”
  Anything else’d be effort…
- Came here to say this. No one deserves this, not even new programmers who try to learn things.
  Some programming tools are really powerful compared to what new users are used to. If you come from the world of Microsoft Office and Apple whatever it's called, everything is saved automatically to cloud and there is some local backup file somewhere which you can just restore. Modern programs are designed to protect users against their own mistakes, and when suddenly that is taken away, it can be a jarring experience.
- It's so fucking infuriating that so many devs act like this. "This should've been obvious!" Fuck off, that's an unhelpful statement. "You should've been using version control! No backup, no sympathy!" Fuck off, they were literally trying to begin using version control for backups.
  Even half the comments on this very Lemmy thread are disparaging this dev. I wonder how many actually read the thread and found that there was a bug discovered causing this feature to delete files not even associated with git?
  But, congratulations to them, I suppose. Congratulations on making fun of someone. I hope it makes them feel powerful. 🙄 Devs can be so toxic.
- If you're going to use a git tool, you need to know how git works.
  There are 0 excuses for not having months of work in a repo, none. I have no sympathy whatsoever. How the fuck do you spend so many months without backing up your project or stuffing it in a repo?
  No sympathy. Dude is a shit developer and he learned an invaluable lesson.
  
  My guess is that this is a teenager, and this is probably their first experience with git and version control in general. Just a hunch.
  Anyway, it is reasonable to expect a mainstream GUI app from one of the largest companies in the world to be approachable for people who do not know all the inner workings of the command line tools that are used behind the scenes. And it is reasonable to expect any destructive action to have clear and bold warnings. "Changes will be discarded" is not clear. What changes? From the user's perspective, the only changes were regarding version control, so "discarding" that should leave them where they started — with their files intact but not in version control.
  Have mercy on the poor noobs. We were all there once.
  
  If you're going to use a git tool, you need to know how git works.
  I guarantee you at least half of git users would get glossy eyes as soon as you mention blobs and trees, yet they all still manage to use it daily successfully.
  There are 0 excuses for not having months of work in a repo, none. I have no sympathy whatsoever. How the fuck do you spend so many months without backing up your project or stuffing it in a repo?
  I need you to listen to me very carefully: THEY WERE FUCKING SETTING UP A REPO WHEN THIS HAPPENED.

let's turn this into a constructive angle for future devs and current juniors: just learn git cli, I promise you it is much simpler than it seems.
all those memes about git having like a thousand commands are true, but you really will only use like 7 at most per month.
learn push, pull, merge, squash, stash, reset, im probably missing like one or two
I promise you again: it is much simpler than it seems. and you won't have to use these stupid git GUI things, and it will save you a hassle because you will know what commands you are running and what they do
short disclaimer: using git GUI is totally fine but low-key you are missing out on so much
- im probably missing like one or two
  commit. Lol
  
  And mergetool ?
  I don't use push/pull btw.
- Every time I mentor a dev on using git they insist so much on using some GUI. Even ones who are "proficient" take way longer to do any action than I can with cli. I had one dev who came from SVN land try and convince me that TortoiseGit was the only way to go
  I died a little that day, and I never won her over to command line despite her coming to me kinda regularly to un-fuck her repository (still one of the best engineers I ever worked with and I honestly miss her... Just not her source control antics)
  
  The difference in speed is familiarity, not some inherent efficiency gain by typing commands into the cli.
  
  If I want to commit a selection of files, but not others, then I'm clicking boxes not typing filenames.
  
  So I’m normally a command line fan and have used git there. But I’m also using sublimerge and honestly I find it fantastic for untangling a bunch of changes that need to be in several commits; being able to quickly scroll through all the changed files, expand & collapse the diffs, select files, hunks, and lines directly in the gui for staging, etc. I can’t see that being any faster / easier on the command line.
  
  Currently using Tortoise and SVN for the first time at my job, and I hate it.
  
  that's exactly why I'm saying this. I know from experience helping other devs with git issues it's always because they're using a GUI alternative to the CLI and they're clicking on things they don't understand
- You get pretty far with just clone, pull, add, commit, push
- Checkout
- The main draw to the CLI for me is portability. I've been a dev for ten years now and used tons of different editors on different platforms and while each one had a different way to describe the changes, how to commit, or how to "sync" (shudder), the CLI hasn't changed. I didn't have to relearn a vital part of my workflow just because I wanted to try a different editor.
- For a first step you can get away with just add, commit, push, and pull. Maybe reset, but tbh using git like svn at first is fine.
  Next branch, checkout and merge. At this point show, log, bisect and blame also start to be useful.
  I'm not a fan of stash, and would instead recommend reflog and cherry-pick as the first two advanced commands to learn. Then rebase and squash.
- Personally, I'm pretty good with the CLI version, but sometimes I just use the Code VC interface. For some tasks (basic commit, pull, push) it's pretty fast. I don't know if it's faster than CLI, but I switch between them depending on what I'm doing at that moment. Code has a built in console, so using either is pretty seemless and easy. If you only use the GUI you won't ever understand it though. I think everyone should start with CLI.
  Honestly, this is true for almost everything. GUIs obfiscate. They don't help you learn, but try to take control away so you can't mess up, and as an effect can't do everything you may want.
- I use gitkraken for two primary purposes:
  Having a visual representation of my project history.
  resolving merge conflicts
  Of these, the first is really the only thing I really want a GUI for. I'll just have it open on my side-screen if I'm managing some more or less messy branch structure or quickly want an overview of what has been done on which branches, where common ancestors are, etc. All the actual doing of things is done from the CLI, because it's just better for that.
- Clone too 😁
- How about Git’s CLI stop being so shit? All of the options are obtuse & usually 3 ways to do the same thing.
  Developers should normalize non-Git DVCSs.
- For me, it is easier to learn to use git via CLI instead of a UI. When I first started using git, I learned a few command/flag combinations that I use every day and I barely learned anything else about git after. Everything I don't do regularly I don't remember, but have written down in a text file of incantations. It is harder to write down what buttons and what menus I have to click.

Say you don't know how to use git without saying you don't know how to use git.
- That's what happens when people stumble across that website called GitHub, get hooked and now have unrealistic expectations for the real git.
  "I just installed Git for Windows. Where is the drag-to-upload box?"
  — A statement dreamt up by the utterly deranged
  Real git involves a lot of sweat, requires you to clean up any mess you make, and communicate with any partners about their preferred techniques instead of rawdogging it and waiting for issues. The pushing and pulling will come naturally but you need to know how and when to release, and be clear about how you wish to commit. Nightly is an option but good luck getting everyone on board. People might judge you for using the word "master" but it should be alright in private.
  
  I'm literally a software dev working for a top company and I can barely use git on the CLI. I do all of my version control operations using a GUI, so there's no sense in gatekeeping any of that. This is true of both my work projects and personal ones. It's cool if you prefer the CLI, but it is absolutely not a required skill in order to have a successful and meaningful career.
  
  People might judge you for using the word "master" but it should be alright in private.
  I snorted. It was my inner 12-year-old's fault. (Also because of recently some idiots getting up in arms about these terms in technology.)
  
  involves a lot of sweat, requires you to clean up any mess you make, and communicate with any partners about their preferred techniques instead of rawdogging it and waiting for issues. The pushing and pulling will come naturally but you need to know how and when to release, and be clear about how you wish to commit. People might judge you for using the word "master" but it should be alright in private.
  Don’t talk about my mom that way
- Git doesn't automatically recursively add all files in the directory to the repository though - VSCode decided that should be the default behavior, while other editors (intellij) ask if you want to add newly created files to version control
  
  I just hate the vscode source control. It has always felt clunky and like it breaks things (or i just never figured out the workflow - either way i dont need it lol) It is way clearer to see what is happening the console
  
  That's how git works. Every file and subfolder under the repo's root folder belongs to the repo.
- Alright you convinced me its time to pick up this skill. How does one best learn git? Just play around with it and break things?
  
  That's basically how I did it.
  To properly learn it using this method, create a directory that contains only text files and sub directories and treat it like a real project. Add files, delete them, play around with updating the repository. Try and go back a few updates and see how the things react. Since it's not a real project there's no risk of loss, but you'll still get to see the effects of what you do.
  
  read the official book : https://git-scm.com/book/en/v2

Skill issue
- I don't know anything about programming, i came here from /all, but it seems to me that a command that's this permanently destructive warrants a second confirmation dialog message reminding the user that the files will be permanently deleted and not undoable
  
  Here is the exact warning that a user had to click through in order to get to where they got:
  
  The problem is that these are “source control basics” that everyone needs to learn the hard way once it seems.
  Waiting 3 months in between commits however is a really bad rookie mistake because you were worried about making a commit that wasn’t perfect.
  
  They clicked discard changes, confirmed it, and the computer did as instructed. This operation is normally not so destructive as it only discards uncommitted changes to realign the local directory with the remote server. Unfortunately for user, it sounds like they have never committed a change, so realignment meant reverting to an empty folder.
  
  I think it’s important to know that this program is for code developers, and the issue here is with a tool called git. Git is like file saving on steroids, because on top of saving a single file, you save many changes to files in git, add a comment for why you made those changes, and share your changes across dozens of files with other developers.
  What this guy did was develop for many months after starting to use git, but he never actually committed the files. Then he asked for to reset everything back to the original state, something that I do multiple times a day, and it gave him a warning that original means original and you will lose everything. And he said do it anyways.
  
  Perhaps. Still I am not sure why someone who is not aware of this would be using VSC. If they are a student then what kind of project are they working on that they have so many files?

5000 files
0 backups
Someone's got their priorities mixed up.
- having 5000 backups of 0 files is also kinda pointless.
  
  Yeah, those are novice numbers. I have infinite backups of my 0 files!
- You have to lose it all to know what matters (speaking from experience 😭)
  
  I once lost three hours of work early on during my learning, not much that I lost but it was a moment when I learnt a lesson. Never lost work after that ever.
- And they were trying to correct their priorities by looking into the source control features, so I don't see how that's anything other than victim blaming for them not doing it sooner.
  
  I would argue that it's common sense to at least make a point in time copy, to... IDK, a USB drive? Before trying to implement a new source/control system.
  Just plug in an external drive, or a thumb drive, copy/paste, unplug it, then proceed with testing.
  I don't see how anyone who values their time and effort could do any less.
  As for the files, undelete is a thing, and it shouldn't be hard to do.

I fucking HATE when abstractions over git use cutesy names that git doesn't use.

The reactions here are why people don't join forums, don't ask questions, or choose to learn alone. "duh, I knew that". Yes, the dude didn't, which is exactly why he's frustrated. I think too many have forgotten what it's like to be a beginner and make a fatal mistake, which would explain the mocking responses here and things like recommending new linux users Arch.
Anti Commercial-AI license
- I understand the impulse to be empathetic and kind. But it's very hard to respond in good faith to someone who just made a post where more than half the words are "fuck you".
  
  A feature that permanently deletes 5000 files with one click without warning deserves a fuck you.
- There is a difference between someone who is new and experiences something like their IDE deletes a file that was unexpected and asking a question about why it did that.
  Then there are arrogant assholes who believe their shit doesn't stink and that they couldn't have done anything wrong and it was the IDE's fault for not knowing what they wanted to do versus what they commanded it to do.
  The OP is the latter.
  
  I mean, not entirely, and he says he lost months worth of work. Like imagine you know nothing of git:
  Click buttons in the IDE to add source control.
  IDE says a bunch of files have been changed.
  But I don't want to make changes to the files, I want to source control them.
  Attempt to undo the changes. Click "discard changes" thinking it will put them back to how they were before clicking add source control. Get a warning dialog that this is not undoable, but that's fine because I don't want whatever changes it made to my files anyway.
  All files are deleted and unrecoverable.
  Like that experience sucks balls and it's reasonable that a person wouldn't expect "discard" == "delete". Also, from reading the GitHub thread, apparently at that time VSCode was doing a git clean when you clicked this. Which like...yeah why the hell would it do that lol? I don't think I have ever used git clean in my entire career.
  
  He's right, his shit doesn't stink. His decision making was reasonable for a new programmer.

Poor guy basically did a git reset —hard HEAD without even a git repository
- Even reset hard wouldn't delete untracked files. This was a complete overreach by the GUI, performing a clean (and likely a forced one, as git's requireForce defaults to true).
  And they did rectify that eventually, giving a warning, and an option to simply reset. It's unfortunate this poor person had to be the trigger for that change.
- WORSE! If you read the thread and linked issue, it was closer to a clean.

Looks like someone forgot about the 3-2-1 rule. Teachable moment.
- Go on...
  
  3 backups: 2 different places/media on-site 1 off-site
  
  https://www.backblaze.com/blog/the-3-2-1-backup-strategy/
  This person lost 3 months of work because they couldn't be assed to backup their data despite having three months to do so.
  Never trust an OS, or a piece of software, to protect you. Protect yourself.

Obligatory mention of file recovery as an option if you get in this situation.I recommend testdisk but there are other more gui friendly options.
NTFS takes a relatively long time to destroy the data so chances of recovery are good on Windows.
- pretty unlike fat32 (fats fragmentation rate is obscenely high tbh)
  well thats unless youre on ssd but most people use hdd

I always found Git GUIs, especially the ones built into IDEs, to be more confusing and clunkier than working with Git on a terminal. It often feels like unlearning what one knows about Git, and relearning it the way that specific GUI demands.
Heck, I am going through the aforementioned feeling as I force myself to use Magit on Emacs. It just does not feel intuitive. But I will not give up until I have made an honest and full attempt.
The only sensible Git GUI I ever used is Sublime Merge[0], after a coworker praised it immensely. Even that is reserved for the rarest of the rare times when the changes in the workspace gets unwieldy and unruly. For every other instance: Git CLI on a terminal.
[0] https://www.sublimemerge.com/
E: typo, and link to mentioned GUI.
- JetBrains has really nice Git integration. Interactive rebaseses and merges are quite pleasant but I'm still dipping into the command line to do stuff occasionally. Most commonly a git reset HEAD~ cause I want to split a commit though I had to dig through the reflog the other day cause I suddenly realized I lost an important branch that ended up being over a hundred commits back.
- How do you view diffs and merges when you say you don't use git GUIs? External tool or terminal/command line?
  I use Jetbrains IDEs and most of my life has been IDE based git interaction. And I honestly love it, easy access to see my diffs, the most common commit, push and stage(or shelve as Jetbrains does it, which is better than visual studio). Hassle free and available beats writing anything to me.
  
  How do you view diffs and merges when you say you don't use git GUIs? External tool or terminal/command line?
  Terminal.
  I use Jetbrains IDEs and most of my life has been IDE based git interaction. And I honestly love it, easy access to see my diffs, the most common commit, push and stage(or shelve as Jetbrains does it, which is better than visual studio). Hassle free and available beats writing anything to me.
  Perhaps, it is a mix of learned behaviour and cognitive fixation, as I started out my development journey predominantly using a terminal, that I cannot fathom Git GUI being hassle free.
  Nice to read a different perspective on such a fundamental thing that I take for granted while working. Thank you for sharing it.

Reminds me of a hilarious bug in early GHC: https://gitlab.haskell.org/ghc/ghc/-/issues/163
The compiler will delete your source file if there's any compile error. And the user complained only by sending a very polite email to report this bug. Simon Peyton Jones mentioned it in one of his talks and I still find it quite hilarious till this day.
- Left the --hardcore compile option on. Easy mistake.
- Software development: hardcore mode
- oof

Honestly no idea why someone would go around a completely unknown menu in a new unknown editor and randomly click things with caution completely out the window. Not having a copy or trying a blank project, not even reading any messages. I mean even if we don't know it's a nuke button, God knows what other edits it could do to your code without you knowing.
This goes beyond rookie mistake. This is something 12 year old me would do. Same with the issue page being 90% swear words.
- I don't even know why people ITT are blaming the IDE and completely ignoring this.
  When you learn git, you do so on a dummy project, that has 5 files which are 10 characters long each.
  An IDE is not made so you can't break things, it is tool, and it should let you do things. It's like complaining that Linux will let you delete your desktop environment. Some people actually want to delete your desktop environment. You can't remove that option just because someone can accidentally do it by ignoring all the warnings.
  
  Got will not delete untracked files though, which is what happened here. If you want to discard changes to a file with git, you first have to commit the file to the index at some point, which means there's only ever so much damage an erroneous "git restore" or "git reset" can do. Specifically, neither of them will delete all the files in an existing project where VC has just been added.
  
  They could have a warning though. I agree with you, but there are some easy ways to prevent this from happening. It just takes time to implement, and would be required in other places too. Is it worth the dev time? I doubt it.
  
  Linus Sebastian enters the chat
- Honestly no idea why editors give shit random names instead of using the terms git uses.
  
  I find it amazing, how every time I see a git GUI I'm completely lost and that it's always completely different, considering it's the same app underneath and that app doesn't have THAT many different functions.
- This is a disease of GUIs. Most people are so used to having their hands held and being unable to make a mistake that when a GUI actually gives you the power to fuck up they don't expect it. I promise you, if this user was using the CLI, this wouldn't have happened as easily.
  
  I promise you, if this user ~~was using the CLI~~ backed up their files, this wouldn't have happened ~~as easily~~.

Backups, backups, backups.
- Like, damn son, at least make a daily archive of your project??
  You have to expect things to go wrong, otherwise you have no one but yourself to blame.
- 80% of my used storage accross all my drives (theyre a lot of them) is backups 💀
  might be a little paranoid...? idk

It does warn you it will erase the file when you discard...
- Go read the actual thread. There was a bug someone found that files you have in there that aren't even associated with git still get deleted. I'm not entirely convinced this was the poster's fault.
  
  It's not a bug, it's intentional. They consider changes to be any change since the last commit including in untracked files. They did update it to make this behavior a lot more obvious though.
  
  I did read the whole thread. I also referenced the resolution further down the comment thread.
  They've adjusted the error message to be abundantly clear after the fact.
- Warns you that changes will be discarded....not quite the same words
  
  I just tried right now to get the exact message.
  Are you sure you want to DELETE foo?
  This is IRREVERSIBLE!
  This file will be FOREVER LOST if you proceed.
  The confirmation button even says Delete File...
  User error.
  
  If you use git and understand that VSC's source control stuff is just a thin wrapper around git, you should understand what "discard all changes" means
- Man who clicks confirmation for leopards to delete his work is angry and surprised when his work is deleted.

deleted a chunk of my work the other day by pressing Ctrl z in windows explorer. my project was without source control installed (cuz it was in Dev stage), and Ctrl shit z/Ctrl y hotkeys didn't work, so that chunk was just gone, persished forever... or so I though. I remembered vs code having a file history under some panel. found it, and here it was - at least some of the latest history of my file. lesson learned: even in Dev where nothing is yet working, finish your day of coding with a commit to a remote repo.
- Makes no sense to me. I’ve never had a single problem. Best ide I’ve ever used.
  
  You can avoid this problem by not doing version control in your code editor. Different programs for different purposes. VS Code is fine for editing code and should not be used to manage an entire project.
  
  I begrudgingly switched to vscode a few years ago. I've never had any issues like this with it. My only issues have been with a plugin that I installed optionally (and that was later fixed by the plugin author).
  
  Viscose is absolutely fine.
  Most of these comments can be reduced to either
  I use CLI by the way...
  Hating on vscode because it's Microsoft product and for no other reason.
  A Gitlab/GitHub account is free. Vscode absolutely lets you type git commands if you prefer that, The GUI only provides access to the most common actions you will do. And I could be wrong on this, but I feel like the discard button does prompt the user that the files will be permanently deleted and you have to click okay. But maybe that only applies to tracked files, not sure off the top of my head.
  
  (VS)Code(ium) is great. (VSCode is MS fork of the OSS Codium.) It's a popular editor with a lot of plugin for just about every language. It has an integrated console. It can do basic Version control (and you can use the console for anything more). It's my favorite editor/IDE (not technically and IDE, at least out of the box). Just don't do things you don't understand. It's that simple. The OP fucked around, and they found out what it does the hard way. It's really easy to use if you have a basic understanding of things though.
- Every new project for me starts with setting up git. There's no reason not to. It takes seconds.
- Nah you gotta submit a bug report for that
- Yeah, standard practice is to set up source control before doing any work at all. Then you add whatever project template/scaffolding files to an initial commit and make it, and keep committing from there.
  You should always be committing early and often. Saves you a lot of headache and make it a lot easier to clean up your history later too.

If you ever happen to have 5000 uncommitted files, you shouldn't be asking yourself if you should commit more often. You should be asking yourself how many new repos you should be making.
- The person didn’t have any git repository; probably a new programmer that didn’t know how version control works and just clicked discard without understanding what that means in this situation.
  
  This person is why we have that meme where devs would rather struggle for a week than spend a few hours reading the documentation.
  
  Just curious, git doesn't touch untracked files though?
- This is without gitignore, so probably just installed one js dependency
- Monorepos are a thing. But obviously this is something entirely different.

Doing a git clean is a dick move.
- The user clicked an option to "discard" all changes. They then got a very clear pop-up saying that this is destructive and cannot be undone (there's a screenshot in the thread).
  
  I very much understand how one can think this would revert any changes done to files under version control but not delete the ones that are not. I believe this dialog has since been updated to explicitly state that fact.
- Yeah, real developers do git clean -dxf.

No backup, no sympathy.

Screenshots of git issues are one of my favorite genres of meme

Often times, people learn that the stove is hot by touching it.
It's easier to blame the stove than the person who touched it. But if you laugh when you watch it happen, you're probably not laughing at the stove.
- This is my take on this. People blaming the software but the truth is that no software can be trusted. Make backups. Make mistakes and learn. Sometimes it will be painful, but those are the most valuable lessons

While I have some sympathy for anyone who loses months of work, as an IT administrator by day, all I have to say about their lack of backups, and lack of RTFM before messing with shit is:
HAHAHAHAHAHAHA HAHAHAHAHA. you got what you deserved fucker. GL.YF.
- Yeah, it's bad enough that it could happen, the fact they allowed that to happen so easily is far worse.
- I will RTFM after literally anyone else does.

Typical web developer. He didn’t even know files can be deleted without going into „recycle bin”
- Why are we dissing web developers? What is this bullshit elitism?
  
  I think it's a joke about how noobs only learn javascript and make blazing fast webapps while knowing nothing about computers.
  
  Look at him. He's just learned that files can be deleted without going info the recycle bin, and he already wants to be treated as equal. Ha!

That has the same energy as complaining that a file manager has "Delete" in the context menu.
- except that the "delete" in file managers is actually "trash" and that's for precisely this reason. Anyone not using the trash bin for a GUI that is capable of deleting files is either incompetent or malicious.
  frankly rm should default to using the trash bin as well, for desktop-focused distros.
- I clicked delete and then clicked confirm when it asked me if I'm sure I want to delete, and all my files disappeared! What the fuck?!? Fuck this fucking operating system!!!!1!!1one!!!
  
  Did you even read the thread?
  CANNOT EVEN FIND THEM IN THE RECYCLE BIN!!!!

Man I get paranoid about synchronization programs for this very reason. There's usually some turnkey easy-mode enabled as soon as you first launch that's like:
"Hey you wanna back up your entire NAS to your phone?! That'll be fun, right?!"
And you're like "...No."
And then it wants to obliterate everything so it's all "synchronized", often it's not easy to find a "No, stop, don't do anything at all until I configure this." Option.
iTunes was SO BAD about this.
Syncthing is the least-bad sync software I've ever run. It's got some footguns but it's still brilliant.
I would imagine there's still ways to back up version controlled software right?
- Any professional would have a code repository and probably a build server which spits out binaries left and right, off site of course.
  Bonus points if that is the easiest way to deploy the software, so all developers actually use it.
  Edit: typo
- iTunes would stomp all over your hard drive, fucking up every MP3 file it could find, and then refuse to believe you could have one copy of a file. Either it's on your iPod and your computer, or it's getting dragged behind the woodshed.
  Give me sync software that only ever increases redundancy.

PEBKAC

I'm sure that the "three months of work" was completely shit code. Anybody who is unfamiliar with source control (or even backups!) is prone to making stupid mistakes. Republican voters are likely to have a similar experience over the next 4 years.

In reality, VSCode has local file history called "Timeline". It's enabled by default.
https://github.com/microsoft/vscode-docs/blob/vnext/release-notes/v1_66.md#local-history
- In reality, that was added four and a half years after this issue was opened.
  
  Oh, didn't notice this was a 7 year old issue.

Jesus saves, and so should you

Why are they messing with the source control options when they're not using source control? Perhaps learn about stuff before you start clicking buttons and performing delete operations on your super critical files?

please fix uwu

Fuck all victim-blamers. "Discard" is not how you label a button that permanently erases anything.

VS Code could really use some work in that regard and I really do feel bad for that person, but this is also just funny as heck
- In fairness, it's an old issue and they did put in the work to address the issue report.

If the files were already staged then git should have blobs in the git folder, so they should be recoverable.
- Looks like they weren't staged. He clicked on the staging option, it showed it would stage thousands of files, he said "hey I should fix my .gitignore" and clicked on what looked like either a "don't stage" or a "forget" button, and it was a "checkout --force" button.
  The most impressive thing is all the people doubling down on the idea that a "checkout --force" button in a main interaction screen is a great idea, there's nothing wrong with the software, and the user is a moron.
  
  "discard changes" button - the 5000 "new file created" changes, specifically.
- Sounds like they weren't even using version control, and had no business anywhere near a project that size.
  
  had no business anywhere near a project that size.
  Lol. That's a really good point, actually.
  I add version control around file number 3200...
  (I'm kidding. Writing even a couple lines without version control makes my eye twitch.)
- Did you read the thread? There was a bug that deleted all files even ones unassociated with git.

I agree with the "learn the CLI", but to newcomers I'll also suggest to look at the IDE/editor's output channel - if there's GUI for Git, there are also most likely logs for what's happening under the hood - even if a little noisy, it can be a good learning resource. And of course if you're learning and unsure of what's happening (with the CLI or through a GUI), do so in a non-destructive manner (by having proper backups).

Same account that complained about the christmas santa hat
- Link? It being "ghost" just means the user has been deleted so I can't actually go looking.

Maybe he would prefer perforce.
- Or Jazz RTC. That one was fun.

- It also plays on the weird trope of people swearing at devs in foreign languages
  https://github.com/ruffle-rs/ruffle/issues/17205

Looks like windows should come with a dictionary.
"Huh, discard, I wonder what that does. Let's try it on all my work from the last six months"
Idiots gonna idiot...
- Problem is, there's an entire generation of users that have gotten super used to "discard changes" as a means of signalling "on second thought, don't do anything".
  
  That's definitely how it is seen.
  If I were to see "Discard Changes" anywhere in a dialogue, I would assume it will discard whatever changes I made in that dialogue. In this case, probably some source control related changes. If it were to say "Warning: This will Discard ALL changes!!!", I might do a double take, but had I never used git CLI before, I would still assume that at most it would discard "ALL" changes made in the current session.
  For me personally, I would consider it more useful for it to say:
  
  This action will delete the following files: - followed - by - a - list - of - files - that - would - be - deleted Continue?
  Which neither has to look like a warning, acting like you might be doing something you don't want to and also is much more useful for someone like me who wants to double check what exactly I am deleting.
  Also, I have used git CLI before and apart from being able to see blame in the editor itself and maybe a better representation of tree, I don't feel the need to use any git GUI tool. Even when I tried, I realised it was slower and more finicky to use. So, it would stand to reason that it should be targetted towards people who don't use CLI (and might have never used git CLI).
  
  From a certain point of view - isn't this exactly what happened here?
  I often go into a Git worktree of one of my projects and mess around a bit to try something out. If I find it's not working, I tell git to discard the changes with git checkout . and git clean -df. What I'm saying is exactly “on second thought, don’t do anything" - while what happens in practice is that Git restores all files to their HEAD status and removes all the new files that are not already in HEAD.
  Of course, the difference is that I already have all the work I want to keep under source control, so these changes I've discarded really were that - just changes. He, on the other hand, "was just playing with the source control option" - so these "changes" he was discarding really were all his work. But Git did not know that.
- This feels like when my brother backed up a file with Onedrive, then figured he could delete the original... the one that Onedrive was keeping track of.
  It's not that these aren't confusing, but why risk your file without testing what the software will do first? Especially before hitting anything like "delete" or "discard"?
  
  See, that's a mistake I could see myself making. I would just assume that OneDrive was making a backup, not tracking the file.

VSCodium better

"Microsoft Please Fix" ifadesi, genellikle kullanıcıların Microsoft ürünlerinde yaşadıkları sorunlara veya hata bildirimlerine yönelik bir çağrıdır. Tostçu Mahmut Menu

So VS Code isn't just slow and bloated, it also deletes your files. So glad I was turned off by its excessive memory consumption and deleted it before it deleted my files.
Edit: also why I only ever used git from the command line, I never found a git UI that is easy to understand, and never trusted them.
- VS Code slow and bloated? Someone hasn't been spending nearly enough time in IntelliJ
  
  Two things can be right at the same time. I remember when I used to run VS6, IE and WinAmp in 128MB with KBs to spare. Even today, proper VS is a much better product than VSCode while being a full fledged IDE and not just a glorified text editor.
- It's really not slow or bloated. There's a reason it's so popular (even in Linux)
  If it's running slow, maybe it's time to check your computer....
  I literally had to use it to load 100 git projects simultaneously recently
- No it doesn't delete your files. Hombre from the post told it to delete his files and was then shocked when it did. It even warns you that it's about to delete your files. Then on top of that, post person wasn't even using source control, so they can't get their files back. Don't mess with the source control options if you're not using source control. Don't just randomly click buttons without reading, if your project files are super critical. Don't only have a single version of your entire project in a single place on one computer. This person obviously has no idea what they're doing, which is fine, but they don't belong anywhere near a 5000 file project.
  
  should have at least had the decency to send them to the trash instead of outright deleting, this is just good and sane design
- You think VS Code is slow and bloated? What do you use?
  Also, on several occasions I've had VS Code help me recover accidentally deleted files, because the editor keeps the file in memory, regardless of if it disappears on disk (like most editors).
  
  What do you use?
  Either an IDE like Visual Studio or Xcode or a text editor like Notepad++, Vim or nano, it depends. I also use Android Studio but I hate it.

Someone who does not know about "permanent delete" and not having backups, especially when switching to a new system, should have no business complaining about this.

This is 2000% user error lmao even tho VS Code is a pain in the ass on w*ndows
EDIT nvm my reading is 2000% user error
- Did you actually read the thread and see the bug they found where it deleted files unassociated with git?
  
  I did but I must have misread maybe? Because what it looked like was it picked up the existing fucked up git repo but if vscode did the fucking up the less of a skill issue 😮‍💨😮‍💨😮‍💨

is op stupid ?

Fuck around things you don't understand, find out. Why even go near the source control area and start clicking stuff if you don't know jack shit about it.
- It seems like he was trying to learn though? He clicked it, like "hell yes I want source control, let's figure this out"
  "It says all my files are changed? Oh shit why did it change my files? Shit fuck, undo, how do I undo...Do I want to discard the changes? I don't even know what it changed. Yes please undo whatever changes you did to my files"
  And poof.
  
  Who learns with five thousand files though?