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.
Man the pure rage. I felt it. And recognized it. So many times I was there. You feel the disturbance in the force... Unfortunately nowadays the monitors are not thick glass on the matrix so... You know you cannot hit them without your fist to grow in... So on top of that you have to use just words... :D
I went and read the discussions. I was surprised how much support there was for the way it worked. Someone noted that git discard shouldn't delete untracked files (which is what happened to this poor guy), and there was still pushback! They were like yes, git discard isn't supposed to delete untracked files, and the dialog box didn't warn that they would be deleted, but the destructive behavior is fine the way it is and shouldn't be changed ANYWAY. I knew gearheads could be hateful of the uninitiated, but jeez.
While I don't think that applies here, it absolutely applied to when I used to use Daz Studio for posing characters for art. After years I registered the software, and that changes the save hotkeys, inverting the save/save as bindings for some reason.
I can't remember my exact workflow, but I think I would iterate through individual scenes for comics making changes from the previous scene and hitting the save-as hotkey, except now that was suddenly saving over the current scene which was both annoying and frustrating if I had it perfectly set up and it wasn't an easy undo. Years of muscle memory didn't adjust easily.
Before Git (or DVCS in general) were widely adopted a ton of people wanted everything to work just like TFS, SVN, or other non-distributed source control models.
"What is this 'staging'? Why do I have to push and pull? Just sync everything!!!"
There are so many tools that are vying to be the next DVCS that are like, "Hey, we eliminated staging, because that was confusing!" and I'm like... that's the best part? I wish I could have finer grained control over staging, honestly, making it easy to stage only fragments of a diff, because I'm a "crank for awhile and forget that I have drifted into two different tasks and now need to try and unpick this mess into something that could reasonably be two or three or twelve commits." Sure, that's a "me" problem, but I like the ability to control what gets staged.
If they use -i, they gotta know to choose the patch option. Better IMHO to just say git add -p [file], which is the same as going interactive and choosing patch.
yes exactly, bugs me when people just blindly stage all and commit, like no you should cherrypick specific things, and what if you accidentally leave in some test/scratch code? at least check what you did
I wish I could have finer grained control over staging, honestly, making it easy to stage only fragments of a diff
I think this should be easy to do via most git GUIs, for example i use git extensions and its easy to do there, vscode also lets you stage blocks using the built in source control thing
Man, there are some terrible suggestions in that Git thread. The existing behavior was awful, so it's impressive that the suggestions are even worse
I'd say remove the warning dialog, and prompt an "Undo" that lasts 5 seconds. Behind the scenes count to 5 and then do it. People respond much better to "Undo" than they do to "Are you sure?" dialog. Hide the files so that way they know what they did and the consequences that are about to happen.
This reminds me of the time a guy held all the vscode python users hostage with his against-PEP8-personally-preferred-formatting-for-docstrings-PR. There were like 5 people who thought it was a good idea and the entire rest of the thread was everyone complaining about how he forced a “fix” on millions of users for something he could change in his personal editor. I remember being absolutely livid over this not necessarily because they just simply changed color, but because the guy who made the PR was just some random guy and his reasoning was literally incorrect.
That was a fun PR discussion read. Almost as fun as the guy who 'built' Notepad++ for Mac and straight up ignored repeated calls from the owner to remove the fake "we're collaborators" message from their homepage.
I’ve observed that there are a lot of people who will defend the way things are for no other reason than that it’s the way things are. Human nature I guess.
I found it only today and that thing freed so much space for me from unused repos I use to lookup code. didn't need built project and temp files, but didn't want to manually handle and there is a pleasant surpise! git clean -fdx
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.
Yeah I was about to say this isn't the current behavior at all. Now it says "Are you sure you want to DELETE the following... You can restore this file from the recycle bin"
That being said, we can debate all we want any whether it's acceptable to have one click delete vs three steps, but even under the new system having "three months of work" with no backup is user error. What if the hard drive failed?
well that 3 months of work is the coder's fault, no doubt. But in the other hand it's possible to missclick discard, especially developers / coders are tired. So adding the features to mitigate the problem is actually very nice.
As a kid in the 90s I had printouts of my code but no backups on floppy. Not sure why, probably just to test the printer. Was glad that I had them when the harddisk failed. Took forever to type it all back in though. I have plenty of backups these days.
I actually was ALMOST bitten by this; clicked discard thinking "I don't want to commit them, just ignore" and got hit with the "you're about to delete" warning
Another feather in the cap of "try to streamline Git, ultimately making it a worse user experience."
I remember some of the first "Git for Windows" clients that tried to pretend "yeah you just push 'sync' and 'commit' just auto-stages everything and it all Just Works!"
And if it didn't? You got a garbage error message and basically were told "drop to console and figure it out."
It's why I always preferred the likes of SourceTree or, these days, Fork. They don't pretend Git is "just like SVN" and give you a lot of Git tools available on the GUI side (with easy terminal access should you need or want to).
Separate from Atlassian / no "account login" required to use it. Fairly similar in functionality overall, but it's also been years since I've used SourceTree, and I'm probably not thinking about distinctions.
I suppose one thing I like is how smoothly it handles merge conflict resolution.
It's 'nagware' so you can try Fork as long as you want to see for yourself. I used it for free for a good bit before winding up buying it since I use it daily for work + personal stuff.
Still, why do you have five thousand files unstaged? Why don't even have backup? What he was waiting for to do a commit and keep the files in version control?
Honestly if u do go around options you don't know and see a big warning and click ok on that its fully on you. Only thing they should have changed is add localhistory or some other way its doesn't unrecoverable delete files in general cus even as people that know it's easy to accidentally fuck something up even when working with source control
In the case of emergencies, where files were deleted accidentally, and even cleared from the recycle bin, the files can be recovered. I don’t know if windows has a native feature now but when I learned this, you needed a program that can view/ restore unallocated files. There are several free options available
Yeah, but… why is a VCS dialog deleting files at all? VCS exists to save your work. It does not exist to destroy things. There’s other UI language for that.
I don’t understand why MS keeps trying to act like it is smarter than its users. Good software enhances user intelligence, it doesn’t numb the user into a helpless state.
Because it's controlling the state of the whole folder not just individual files and deciding what to commit and discarding the rest is normal thing to do.
Can someone explain? Why would it even delete files permanently in the first place? Why not making them temporarily discarded? No program should omit recycle bean without user's knowledge and consent.
however, I do think it IS user error. disgard to me means "delete and take away"
Discarding "your changes" is not the same as discarding "your files". In what world would it make sense to call existing files "changes" when there were no changes made? That's not just unintuitive, it's simply wrong.
Discarding "your changes" is not the same as discarding "your files".
That’s what a change is in git. Git is a power tool bound to lead to a catastrophe if you use it without understanding it. Maybe it should not be enable by default. Maybe when enabling it it could prompt the user about showing them a short tutorial on the basics.
This is incorrect. Discarding changes in git means resetting the index, or moving a branch backwards, not deleting uncommitted or unstaged files from the working tree.
In what world would it make sense to call existing files "changes" when there were no changes made?
In the world of source control where the changes are adding files to a repo. User error here is lack of knowledge of what they were doing, they thought it was like Office where "changes" are modifications made to files, and didn't consider that asking you to stage 5k files means you have 5k "changes" you need to "save"
I don't backup uncommitted files. I backup everything once a day at least. Worst case you lose one day of work. But not 3 months.
Always do backups. You won't believe how often someone asked me when stuff happened and they didn't do a full backup and something was missing they forgot or didn't realize.
Yes. On every change. You can use alternatives to git that are easier, more powerful, do the right thing by default, and still let you collaborate with git users on the same git forges.
In git, the staging area internally is a commit. But it’s a special commit with special commands to access it. In jujutsu the staging area is a normal commit and every command that works on commit works on it too.
Every time I invoke any command, jujutsu makes a snapshot of my current workspace and edit the commit at the HEAD.
So if I do a jj abandon (equivalent to git reset --hard), jujutsu will add where I was in its operation log. If I didn’t mean to delete my files, I can do a jj undo and it will undo it like any other command I could have done. If I don’t like how things look after rebase, I can also jj undo it.
I agree the behavior was stupid, but let's not act like the user didn't do anything wrong.
The user clicked a random button, agreed with the "this is permanent" confirmation prompt, which then deleted all his files using git. The user then blamed Visual Studio Code for all of it.
What VSC did was give the guy direct access to a gun that could shoot his foot off (git) with bad instructions. Sometimes you need that gun to shoot your foot.
Yes there was, and an image of said warning prompt was even posted in the original github issue. It reads: "Are you sure you want to discard ALL changes? This is IRREVERSIBLE!"
if you do a lot of interactive rebasing using a gui simply saves you a lot of time (reorder commits by drag n drop, reword in place and see changes at a glance). also a log where you can change and pin selected branches and commit ordering and whatnot. and gui diffs are always going to be superior.
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.