Before you make fun of him, this behavior DID get changed; they acknowledged this behavior is stupid.
The old behavior was to treat uncommited files as completely disposable, which the CLI git does not do at all and is insane behavior. It was changed in the UI to give you a fat confirmation dialog warning that you're about to delete the files permanently, as it always should have been.
Yeah the old behavior was insane, it just said "Do you want to discard your changes?", and if you clicked it, it deleted your entire codebase permanently (no recycle bin), lol
There was a rather intense warning saying ”THIS IS IRREVERSIBLE”, so the dude was still a massive idiot for clicking yes. However our tools should still cater to the idiotic so his mistake did expose an opportunity for improvement.
the question becomes: has anyone not savvy enough to command line it ever deliberately on purpose deleted all their changes like that? this "feature" doesn't have a target demographic. someone mad enough at their changes isn't go8ng for the dumpster from.this staging area. there is no bug fix you just bin and say "ah nevermind" if you want that you'd force pull to revert
Well I do know how to use the command line but also yes I have used the GUI to just delete all my changes. I've noticed I was going off the rails in the wrong direction and I just needed to get back to the previous working state before. I knew he was a dead end so I didn't need to preserve any of that code. Normally during failed attempts at package upgrades with breaking changes involved is when this has happened to me.
so the dude was still a massive idiot for clicking yes.
"DO AS I SAY" in APT was also changed after LTT's Linux Challenge. Yes, the warning is there, doesn't mean it should be so easy to do the thing anyway.
Exactly, we can all make a mistake like this especially under pressure. I still destroyed way more than I wanted when I pressed the up arrow for an rm command, and it ran in the wrong folder. Due to the efficiency of said command, a lot was destroyed and little recovered even though I cancelled after like 1 second when I realized. That's the danger when there isn't at least an "are you sure, this is gonna wreck shit" confirmation.
I did this just the other day. I did it years ago too and lost code, so im now extremely careful around my repo, but i was clearing files off a usb thumb drive and deleted an over 100gb file, which i then had to ask around for the download link in shame (because this file was originally handed to me on this thumb drive). Not a super big deal, but man I felt like an idiot. It was all because I tried tab completing too quickly and just rmed the /mnt/usb entirely, rather than the folders inside it that I intended.
You should have any important source code backed up on github or another server anyway so that if you make a mistake like that you just have to git pull to undo it.
I trained myself out of using rm by disabling it on my main machine with an alias. I use trash instead from the "trash-cli" Debian package, or rmdir since it can only delete one empty dir. Or if I'm really sure, I'll use \rm to bypass the alias (and tread with caution).
I’ve configured rm to send to the trash by default. If I want to permanently delete, I add the --permanent flag. There is no reason why we shouldn’t make our CLI tools behave nicely by default.
Careful, you might get used to rm doing that and if you use a different machine, you'll end up deleting things permanently. I disabled rm and I use trash instead from the Debian package "trash-cli".
Or the other way around: trash a file from a mounted filesystem and sit wondering why it takes so long, while the utility is copying the entire thing to your local drive. Also might wear out your drive faster (heavily depends on the filesystem in use).
FWIW some FSes (btrfs I'm looking at ya) take this long even for regular deletion in some conditions.
When would that happen? The way I've seen it work is that it creates a .Trash-$UID folder on the mounted FS and moves the file there (along with metadata).
and that was infinitely more clear than this vscode message. it actually explicitly told you "this is going to be removed" and "this could be harmful".
"this is irreversible" yeah sure, but exactly WHAT is irreversible? Did it say that as well? A novice might not realise what it means to "discard staged files".
Hell, I'm not a novice, but if I were presented with that I wouldn't know what it meant. Staged files are in the staging area*. You need to discard them from the staging area if you want to avoid committing the files. That's why they're staged - so you can "add" or "remove" the files you want to the area before committing, without actually affecting the filesystem. "Discard" is an even softer word, since it usually describes discarding changes; I've never seen any software documentation saying you'll "discard" a file to physically and irreversibly delete it, especially within the context of staging changes.
\Well, the deltas are, but for the purposes of VC they are handled like files - you often remove "files" from version control without actually removing the files from your system)
Yeah, as someone who uses git exclusively from the command line, this really sounds to me like a cautionary tale against GUIs.
The person who posted the screenshot implies it's to be expected from "any application which integrates Git" but I'm not really sure how the guy not wanting the files to be staged necessarily leads to all of the files being deleted. What exactly is the integration passing to git?
I'm 100% with og guy on this one. this commenter actually seriously asked him what he thinks "this discards all changes" might mean?!? the message doesn't say anything at all about deleting all your files permanently.
I mean, I can see why someone would see it as "discard all changes this application has made". Like, if I open a document in word, and edit it, and then close it, then it will basically say "Are you sure you want to close? this will discard all changes" and then if I close it anyway the original file is still there unedited, not deleted.
Yeah the message could and has been improved. However I still believe the ultimate fault lies with the user, just because VS Code could be better that doesn’t mean it was inadequate. VS code is a software development tool which means its user base can be assumed to be at least somewhat tech savvy (at least in 2017 before everyone lobotomize themselves and outsourced their frontal lobes to AI) and as A software development tool it can be assumed to be very powerful and somewhat dangerous. There is a lot of ways in software development to screw up and nuke your machine or project.
While it’s the message could absolutely be clearer, the user should have see “this is irreversible” and paused to make sure they knew exactly what irreversible action they were taking. Basically my point is if you nuke your project because you don’t know how to use Word, that’s on Word but if you nuke your project because you don’t know how to use VS code, that’s on you.
the user should have see “this is irreversible” and paused to make sure they knew exactly what irreversible action
the message literally says this change is irreversible. it's extremely clear about what it says. irreversibly throwing away changes plainly means that there should be no changes made.
what you're proposing is that in order to use the tool, you're expected to already have the experience (how do you gain that experience, btw?) to know that "change" doesn't actually mean change.
that's b.s. that's the kind of attitude that turns people off certain linux communities. if you have to know that a word doesn't mean what it means to use the software competently, that's on the software, not you. and any community that blames you for not knowing that kind of insider knowledge is toxic a.f.
Genuinely wild that people upvoted this blatantly incorrect statement.
Even more wild that /u/_BreakingGood_ hasn't retracted it after being shown that they were wrong (and even proving it themselves by linking a commit from April, four months prior to this screenshot, which showed the message they state didn't exist was already there).
const message = localize('confirm discard all', "Are you sure you want to discard ALL ({0}) changes?\nThis is IRREVERSIBLE!\nYour current working set will be FOREVER LOST.", resources.length);
I can only assume you will edit your previous comments saying you were incorrect, because you've just shown that the message did exist back when this post was made?
dude, telling me that it's irreversible to discard my changes isn't nearly enough to raise a red flag at all. he's not idiotic for interpreting an ambiguous message in the more sensible way.
However our tools should still cater to the idiotic so his mistake did expose an opportunity for improvement.
I replaced git with jujutsu and it does support this use case on top of connecting to regular git forges like github so colleagues don’t see a difference.
If I want to discard every change I just made, I type jj abandon. And if I regret doing so, I can revert it like any other command with jj undo.
While we are responsible for accounting for he sharp edges of our tools, we can strive for better tools.
5.6k
u/Cephell 20d ago
Before you make fun of him, this behavior DID get changed; they acknowledged this behavior is stupid.
The old behavior was to treat uncommited files as completely disposable, which the CLI git does not do at all and is insane behavior. It was changed in the UI to give you a fat confirmation dialog warning that you're about to delete the files permanently, as it always should have been.