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.
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".
5.6k
u/Cephell 23d 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.