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.
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.
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.
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.
We really need some kind of board like the one that controls the title for engineers.
Those are rookie numbers. I have at least a 35k one somewhere. More than one actually.
People run their businesses on this.
I once landed a job at a small company doing a software for medical analysis labs all over the country. Software had been around for over ten years at this point. They had no source control. Nothing. Absolute nightmare.
They were literally starting to use source control when I arrived.
In 2015.The “source control” when I first started was all the code on a shared drive, to check out a file you copied it to your machine, and renamed the extension on the shared drive to your initials.
When somebody edited without doing this there would be full blown meltdowns over lost work.
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:
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.
I dunno, “discard changes” is usually not the same as “delete all 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.
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.
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.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.
“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”.
And the terminology is misleading, resulting in problems. shrug.
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.
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!
4. Complain about lack of scary warning.
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.
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.
If you have set up your staging area for a commit you may want to discard (unstage) changes from the staging area, as opposed to discarding changes in the working directory.
Of course, the difference between the two is obvious if you’re using git CLI, but I can easily see someone using a GUI (and that maybe isn’t too familiar with git) misunderstanding “discard” as “unstage”.
Either way, what happened here indicates that all the files were somehow added to the VC, without having been committed first, or something like that, because git will not let you discard a file that is untracked, because that wouldn’t make any sense. The fact that the GUI let this person delete a bunch of files without first committing them to the index is what makes this a terrible design choice, and also what makes the use of the word “discard” misleading.
“Discard” is not a git operation.
Ok fair enough, but I’m under the impression these files existed before the source control was implemented.
I guess it’s all up to how the program handles existing files.
I guess the newly created git repository was empty, and all the files that was present in the folder represented “changes”
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.
I remember following the drama back in the day. That warning you saw was the result of this now-classic bug report.
Did you even read the thread?
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…
Honestly it probably just runs the underlying git command
Sorta, but sorta no.
It was actually addressed in https://github.com/microsoft/vscode/issues/32459 – the GUI implied a different git command than what actually got executed!
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.
No, by his own admission, he was playing around with the IDE. He wasn’t interested in the version control, he was interested in the pretty editor.
I suggest you go read the original issue.
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.
You’re 100% right.
But I defy anyone’s mouse-foo to come anywhere near the speed of my typing speed and alias list.
Even someone mastering GUI keyboard shortcuts isn’t going to be able to match, because my terminal is optimized beyond what is possible in a more graphical app.
What I’m trying to say is that no one can introduce a thoughtless mistake into production code as quickly as I can.
The real metric is dollars per second of destroyed hardware ;)
I once watched an engineer blow up a $200k prototype with a terminal alias.
That’s impressive. I’m glad I don’t have any story to match that. Hopefully they find it hilarious now. Probably no fun at the time.
If I want to commit a selection of files, but not others, then I’m clicking boxes not typing filenames.
That is the one use case I’ve seen where a gui is absolutely faster.
In my line of work, I primarily work on embedded systems or process automation so any new files in the repo directory either need to be added for tracking or to the ignore file. I’m not saying it will never happen, but at least in my experience it happens so rarely that I always try to teach command line when possible
git add -pDid you not know?
You can simply select all files you want to commit, in the File Manager, Ctrl+C, then paste in the terminal and it will automatically add all those file names (full paths) separated with spaces at the cursor. At least in KDE: Dolphin ->zsh+ Konsole it does.And sure, it might look like 2 extra steps, but you will still be clicking around a lot in case of a GUI anyway.
I tend to just type partial filenames and use tab completions, which are also pretty configurable. And the only dissatisfaction I have rn, is that I don’t have
zshmodule for completions with pascal case and snake case.
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.
Heh, I guess this shows my corporate software dev experience. Whenever I’ve taught git workflows it was always paired with a work ticketing system where any changes you were making were ideally all one single set of changes. If you need a feature or bug fix someone else was doing that was being done on another branch which you could pull into your code early and for tracking purposes we always made sure the other person merged into main first. The only time I’ve seen per line manipulation with git was when someone made a ton of changes in a file and wanted to revert a handful of lines.
Everything else you mentioned I’ve had a web git host like gitlab or bitbucket for, but I kinda put that more into peer review workflow than git itself
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
Currently using Tortoise and SVN for the first time at my job, and I hate it.
Welcome to the brotherhood. Haha. Ow.
Using SVN was like a having a thoughtful professional assistant who ignored half of what I said and occasionally threw medium sized objects at my head without warning.
You’re allowed to mock the whole organization mercilessly until they upgrade to git. Git is completely free, and the available upgrade tools are lossless. Also
gitactually works perfectly fine when naively treated like SVN.Source: I used git naively like SVN for awhile after (flawlessly) upgrading a huge number of repositories.
You get pretty far with just clone, pull, add, commit, push
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.
Checkout
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
gitvia 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.
I agree that the gatekeeping isn’t a good thing, but you should learn at least the basics of the CLI. It will give you a better understanding of what’s going on behind your GUI and makes troubleshooting and fixing problems a lot easier.
Definitely not required but it is absolutely a skill worth having.
It’s absolutely not a skill worth having. If you ever run into issues and need the CLI, you can always get your knowledge right in that moment. If you already can do everything with your GUI and get the same results, getting the knowledge to do it some other way is just wasted time and duplicate work.
It’s not even about the CLI. it’s about hygiene
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.)
“up in arms”:
Reality:
– “just don’t use them, some people find them offensive”
– “ok”Anonymous techbros online:
“yOu CanT sAY aNYtHiNg ThEsE daYs”
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.
What does
git add xxxdo then
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.
that’s a necessary step in your learning process, but certainly not sufficient. I’d recommend reading the book, since it shows in greut detail the inner workings of Git along with the basic concepts :
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:
That’s not a very good dialog box. He didn’t make any changes, so discarding them doesn’t sound like a problem.
There should be a notice when you enable source control that this will permanently delete all existing files with a checkbox (checked by default) that says “Add existing files to source control.”
He wouldn’t have seen the “Discard Changes” button at all if source control wasn’t already setup (and detected by VSCode).No sane program will delete files when you initialize source control either.As I found later, VSCode did have weird behaviors with source control back then. My experience is more with the latest versions.
My sibling ran into this issue once. I’m not sure if it’s a setting or a default, but vscode would assume they were working in a blank repo until they made a commit.
Sounds like this person had the project (without source control) in another IDE, tried out VSCode, and it assumed that it was all ‘changes’. I don’t use VSCode, do I can’t say for certain, but I know my sibling lost ~4 hours of project set up for the same reason (though they immediately realized it was their fault).
Reading your comment and #32459, I realize that VSCode source control did have some major issues back then.
It looks like they have improved though, as the latest VSCode I use doesn’t auto-initialize repositories anymore.
Hm ok yeah, that seems quite scary sounding so that i would strongly hesitate before clicking on “discard ALL changes”. Still, I wonder if a second confirmation dialog with more information is warranted for a command that’s so destructive.
I wouldn’t assume “discard changes” means “delete files that existed before the editor did”.
It’s changes from the prior commit in the repository, which, if they had not committed anything prior, would have been an empty directory.
This is perhaps a good lesson in teaching version control as its own concept rather than “streamlining it” by bundling it with an editor.
You shouldn’t be taking ownership of files and then deleting them without communication a hell of a lot better than that.
I understand what happened. I’m saying that if you’re going to delete stuff that was there before the software was, your flow to adding a project should include suggesting a base level commit of everything that’s there already.
That’s definitely fair, creating a repository in a non-empty directory could definitely suggest auto-committing the current state if it doesn’t already. I don’t use VSCode so I wouldn’t know.
Although now that I think about it, that could have been the intention here but not automatic, if that’s why 5k+ files were staged without the user explicitly staging them. Extra tragic if that’s the case.
Ok then, the changes to the repository shouldve been discarded. Anything he uploaded shouldve been deleted from the server. Why were files on his local machine deleted?
The repository in Git isn’t on the server, it’s on your local machine.
What makes you think a server was involved here? It was a local repository, evidenced by the reporter’s bewilderment that files can be deleted without going to the Recycle Bin first. Which tells us that in addition to VCS, they were unfamiliar with Windows as well.
It’s not that. It means discard all changes made after the last change committed to this local repository.
In this case it seems like it also performed a
git cleanand deleted his untracked files too. Someone actually opened a an issue to try and prevent the behaviour in the future
deleted by creator
discarding changes does not discard uncommitted new files. The VS Code button did a
git cleanwhich is completely unexpected. Git even refers to a git clean with completely different terminology.git reset -> “Resets the index and working tree. Any changes to tracked files in the working tree since are discarded.”
git clean -> “Cleans the working tree by recursively removing files that are not under version control, starting from the current directory.”. This command also requires you to specify a force option to actually do something, else it quits with an error.
Note that git clean never once refers to discarding anything, and git reset never refers to removing untracked files. VS Code was doing an idiotic thing. Running
git reset --hardANDgit clean. There is absolutely no reason to be runninggit cleanfrom an UI button ever. If you want to remove a file you can explicitly remove it.Imagine that the button said “Discard all changes” and then it ran
rm -rf --no-preserve-root /*. Would that make sense as a button? No. It definitely would not.or like “unmount d:” but instead it formats d:
Which is exactly the situation the dude was in. As a newbie, it’s an easy mistake to make. Telling somebody who doesn’t know “well, would you look at that, you didn’t know!” is not just unhelpful, it’s useless and condescending.
I guess cancelling would go back to the “Then you want to commit all files?” dialog, which the user didn’t want to, he just wanted to cancel whatever the IDE was trying to start.
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.
the problem is that VS Code ran
git cleanif you clicked yes, which is completely idiotic behavior. No other git client, text editor, or IDE on the planet does that.Either way, waiting 3 months worth of work before a commit is the big mistake here.
I think they hadn’t ever used git before, and according to at least one person in the linked issue, vs code might have auto initialized the git repository for the user.
In fairness, ALL git terms feel backwards at first.
Imperfect commits never existed when you squash.
Squash ftw. Simpler clearer history.
Interesting. I wouldn’t know, because I code everything perfectly the first time.
Disclaimer: The above flagrant lie was brought to you by my also using rebase and squash to hide all of my mistakes.
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.
No he asked for a discard after importing the project into VS Code. discard in git terms refers to
git reset, notgit clean. Even if he wanted to run agit resetthen this version of VS Code would have run agit cleanand deleted everything. Imagine he committed all 5000 files, but had a secret.json that he hadn’t committed. He didn’t add it to gitignore either. Running agit reset --hardwill not delete this file, but the VS Code button did exactly that because it ran agit clean.
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?
I’m sure 99% of the files were node modules. The npm bloat is real.
That is wild.
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.
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.
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.
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
My git gui has a tick box on that prompt to specifically include added files. I now see why haha
If you have no idea what Git is, that warning message is not telling you you’re about to delete 5000 files.
But I wonder if this person maybe does know about Git because they used the word „stage“.
“Discard changes” is usually equivalent to “cancel” or “quit without saving”. Not shift+delete files lol.
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.Months worth of work. Going an entire day without committing should never happen. Also, rawdogging it without a backup?
Nope, dude learned a hard lesson. No sympathy. He thought that the rules of data storage don’t apply to him and he got boned.
He did learn a hard lesson, but it sounds like this was exactly what he was attempting to rectify. “This project is pretty important to me. I should probably figure out how to use source control and put it on GitHub” but then by doing so, and due to some arguably poor UX decisions in VSC, destroyed the project.
If someone’s trying to learn how to do something you can’t just be like “well you should’ve already known how”, you know what I mean?
Well actually, let’s qualify that: there are cases where people try to jump right in the deep end. “I’m just learning woodworking! Step 1: build a new deck for my house”, like yeah bro what are you doing, let’s start with a birdfeeder or something.
But that’s not what happened here. He tried to use the built-in GUI, which many would assume would be easier to learn than jumping right to the CLI, and it burned him in a way he didn’t even realize was possible.
-
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.
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.
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.
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.
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
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
What about 2 offsite and 1 onsite? That’s been my approach, mostly due to storage limitations onsite.
As long as the off-site isn’t the same location or method of access, that’s generally fine. Essentially, you want to make sure you have a way to get at the data no matter what happens.
Fire/damage on location: pull off-site such as online backup Internet down: pull hardware based backup
Contingency plans, essentially
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.
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.
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.
This user was not using git though, he was using vs code. That button doesn’t say “git reset” it says “discard all changes”. And btw, what it does is “git clean”, which is something that git can do.
Just below the button there is a list of all the changes. In his case, there were 3000 changes of the type “file creation”. Discarding a file creation can only be made one way: deleting the file.
Anyway, this user is presumably in his learning phase, I would not assume that he knows what git reset or git restore actually do.
In other IDEs this discards tracked changes, untracked files usually stay untouched.
In my opinion, it’s a combination of user error and bad implementation here
Fair enough, git clean does exist. However, if the button saying “discard all changes” is really a button that runs
git clean, that’s just a plain terrible design choice.git cleanis “delete all untracked files”, which is specifically not discarding changes, because there can be no changes to discard on an untracked file. Even talking about “changes” to an untracked file in VC context makes little sense, because the VC system doesn’t know anything about any changes to the file, only whether it exists or not.That’s not even mentioning the fact that the option to “git clean” shows up as one of the easily accessible options in relation to a staging process. Especially if you’re coming from the git CLI, you’re likely to associate “discard changes” with “git restore”.
Mein Gott!
Yeah, I guess I’ve got to leave it like that now…
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.
There is a warning. IIRC it says “are you sure you want to discard all changes? This action is unreverisble”. In the context of version management. Creating a file is a change. And just below the button to discard all changes is the list of changes. In that list he could’ve seen 3000 changes of the type “file creation”, when you discard a file creation, it means to undo the creation, which is a deletion.
The button days what is going to do. There is a warning about what it’s going to do. And there is a list of the exact changes it’s going to undo.
The only way to avoid this from happening is to not have the button exist. In that case, the users that actually want to discard all changes would be unable to do so.
Right? “You are about to permanently delete 5,345 files, they will not be sent to the recycling bin, are you sure?”
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 CLIbacked up their files, this wouldn’t have happenedas easily.That too, but it seems like this was them attempting to back up their files. They just critically failed.
Using a program that’s not designed to be a backup solution that you are also unfamiliar with sounds even worse. Lol
