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
I fucking HATE when abstractions over git use cutesy names that git doesn’t use.
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.
Honestly no idea why editors give shit random names instead of using the terms git uses.
Poor guy basically did a git reset —hard HEAD without even a git repository
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.
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…
Jesus saves, and so should you
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.
This is without gitignore, so probably just installed one js dependency
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?
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
What about 2 offsite and 1 onsite? That’s been my approach, mostly due to storage limitations onsite.
technically isn’t a vcs supposed to be one of those different places?
Yes, but the OP went 3 months without it and then messed up during setup
Maybe he would prefer perforce.
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.
all I’m learning from these stories is to stay far far away from vscode.
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).
Nah you gotta submit a bug report for that
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.
The real issue is already going 3 months without source control.
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
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
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.
Those are rookie numbers. I have at least a 35k one somewhere. More than one actually.
People run their businesses on this.
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.
Jesus, reminds me of a similar story. My gf once lost a job to someone who literally just pasted code into LLMs, also delivering quickly, even tho it was hot garbage. Anyhow, she spent a lot of her time fixing his shit and so her output went down. I hope that company burns to the ground with completely un manageable software.
When I left the project they rehired them and let them design the v2 of the project we just fixed.
Lol. Wow.
And that is why I’ve been unable to work myself out of a job in all my long years as a developer.
My company for the longest time had two engineers they would give all the new projects to. They would rush through some prototype code as fast as they could then management would bring in a new team to take the project over. The code was always garbage and crammed into one place. I kept getting new projects and instead of starting from a nice clean slate we always had to build on that garbage. It sucked so bad.
He just heard monoliths were in again
Reading this just give me a panic attack
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.
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.
It had a reasonably clear warning, though; a screenshot is included in this response from the devs. But note that the response also links to another issue where some bikeshedding on the warning occurred and the warning was ultimately improved.
I disagree that that warning is reasonably clear. Even the comment that included it has the line of thought, where the user, not knowing what terms git uses thinks that they just did an action that is going to change each of their files. It makes sense that they’d want to discard those changes. That user then goes on with some snark about not wanting to learn any more about what they are playing with and that other programs would do the same, but “discard changes” seems like it would have a clear meaning to someone who doesn’t know git.
The warning says it isn’t undoable but also doesn’t clarify that the files themselves are the changes. Should probably have a special case for if someone hits discard changes on a brand new repository with no files ever checked in and hits discard on a large number of files instead of checking them in. Even a “(This deletes all of the local files!)” would make it clear enough to say what the warning is really about.
Even if you know git, you wouldn’t assume that “discard all changes” affects untracked files. It’s bad design all around
OK this is hilarious
When you sell hammers you’ll likely have people using them to hit their own heads, which, understandably, they will put the hammer at fault. Now, we already put a big don’t hit this on your own head label on our hammer. Should we actually prohibit people from head hitting with our hammers? Probably not, since some users still want to hit heads with it. It’s just how hammers work.
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 cleanwhen you clicked this. Which like…yeah why the hell would it do that lol? I don’t think I have ever usedgit cleanin my entire career.-
He’s right, his shit doesn’t stink. His decision making was reasonable for a new programmer.
In case anyone else is wondering, or simply doesn’t like reading screen shots of text, this is apparently a real report:
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.
4. Complain about lack of a scary warning.
I dunno, “discard changes” is usually not the same as “delete all files”
If the “changes” are all your files, discarding them for me means basically delete my files, you know, the ones you are trying to add.
At the same time, OP seems a layman, and might be coming from things like Microsoft Word, where “Discard all changes” basically means “revert to last save”.
EDIT: After reading the related issues, OP may have also thought that “discard changes” was to uninitialise the repository, as opposed to wiping untracked files.
Nowadays the warning even says that this cannot be undone. Maybe that wasn’t present in 1.15, though.
It was. If you go through the OP thread, one of the responses is a picture of the dialog window that this user clicked through saying, “these changes will be IRREVERSIBLE”.
The OP was just playing with a new kind of fire (VSCodes Git/source control panel) that they didn’t understand, and they got burned.
We all gotta get burnt at least once, but it normally turns us into better devs in the end. I would bet money that this person uses source control now, as long as they are still coding.
What exactly do you think discard means?
“Changes” are not the same thing as “files”.
I’d expect that files that are not in version control would not be touched.
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 cleanbut to keep it after numerous issue reports.As others discussed in that thread,
git cleanhas 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
gitmay think, the user is about to lose some files.“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”.
If the change is a new untracked file
Wasn’t the issue that it deleted a bunch of preexisting untracked files? So old untracked files.
And the terminology is misleading, resulting in problems. shrug.
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.
Yeah. They did substantially modify the message to make it much clearer, thankfully.
It means both.
Having done exactly 0 research, I going to assume it’s one of those “DO NOT PRESS OKAY UNLESS YOU ARE EXPERIENCED AND KNOW WHAT YOU ARE DOING” and someone went “pffft I know what I’m doing. click now what does this option do…”
reading through it, it sounds like they opened a project in VSCode, and it saw that there was a local git repo already initialized, with 3 months of changes uncommitted and not staged. So the options there are to stage the changes (
git add) to be committed or discard the changes (git checkout -- .). I guess they chose the discard option thinking it was a notification and i guess the filename would be added to gitignore or something? Instead, it discarded the changes, and to the user, it looked like VSCode didrm -rfand not that this was the behavior of git. Since the changes were never committed, evengit reflogcan’t save them.From this issue: https://github.com/microsoft/vscode/issues/32459
It appears that the behavior actually included a git clean. Which is insane in my opinion. Not sure if they changed it since, but there’s definitely a dev defending it.
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.
The issue I linked has a very good analysis of the UX issues and several suggestions for fixing these. They went with a minor iteration on the original message box, which not only includes a clearer message and the number of files affected, but also defaults to not touching untracked files (while preserving the option to delete untracked files as before).
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.
The second button is actually a pretty major change!
Pretty sure the scary warnings in big bold text are more recent than this report.
Nope. The scary warning is even screenshotted and used as an example in the post report discussion.
It’s quite the fun read!
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.
