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.
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
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.
You get pretty far with just clone, pull, add, commit, push
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)
Tortoise git is probably what convinced me to just use the CLI for everything back in the day. Tortoise SVN is basically 1:1 with the SVN CLI (as far as I could tell, at least); Tortoise Git was...not.
Maybe other git UIs are better. I hope so! Maybe even Tortoise has gotten better. But it was not good back then. (This was around 2013.)
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.
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
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.
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.
Checkout
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.
-
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.
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.
Clone too 😁
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.
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.
Left the --hardcore compile option on. Easy mistake.
Software development: hardcore mode
oof
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".
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
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.
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.
5000 files
0 backups
Someone's got their priorities mixed up.
having 5000 backups of 0 files is also kinda pointless.
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.
While I have some sympathy for anyone who loses months of work, as an IT administrator by day, all I have to say about their lack of backups, and lack of RTFM before messing with shit is:
HAHAHAHAHAHAHA HAHAHAHAHA. you got what you deserved fucker. GL.YF.
Yeah, it's bad enough that it could happen, the fact they allowed that to happen so easily is far worse.
I will RTFM after literally anyone else does.
At this point, I've read a good number of the manuals. Might not be the majority because there's so freaking many, but it's a lot.
In case anyone else is wondering, or simply doesn't like reading screen shots of text, this is apparently a real report:
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 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.
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.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.
It does warn you it will erase the file when you discard...
Go read the actual thread. There was a bug someone found that files you have in there that aren't even associated with git still get deleted. I'm not entirely convinced this was the poster's fault.
I did read the whole thread. I also referenced the resolution further down the comment thread.
They've adjusted the error message to be abundantly clear after the fact.
Warns you that changes will be discarded....not quite the same words
Man who clicks confirmation for leopards to delete his work is angry and surprised when his work is deleted.
Man I get paranoid about synchronization programs for this very reason. There's usually some turnkey easy-mode enabled as soon as you first launch that's like:
"Hey you wanna back up your entire NAS to your phone?! That'll be fun, right?!"
And you're like "...No."
And then it wants to obliterate everything so it's all "synchronized", often it's not easy to find a "No, stop, don't do anything at all until I configure this." Option.
iTunes was SO BAD about this.
Syncthing is the least-bad sync software I've ever run. It's got some footguns but it's still brilliant.
I would imagine there's still ways to back up version controlled software right?
Any professional would have a code repository and probably a build server which spits out binaries left and right, off site of course.
Bonus points if that is the easiest way to deploy the software, so all developers actually use it.
Edit: typo
I fucking HATE when abstractions over git use cutesy names that git doesn't use.
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.
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.
I'm sure that the "three months of work" was completely shit code. Anybody who is unfamiliar with source control (or even backups!) is prone to making stupid mistakes. Republican voters are likely to have a similar experience over the next 4 years.
What a delightfully divisive statement. We do all need to start somewhere though, and losing months of work is very discouraging!
PEBKAC
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.
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
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.
read the official book : https://git-scm.com/book/en/v2
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.
Linus Sebastian enters the chat
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.
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.
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
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.
That has the same energy as complaining that a file manager has "Delete" in the context menu.
except that the "delete" in file managers is actually "trash" and that's for precisely this reason. Anyone not using the trash bin for a GUI that is capable of deleting files is either incompetent or malicious.
frankly
rmshould default to using the trash bin as well, for desktop-focused distros.
No backup, no sympathy.
Looks like someone forgot about the 3-2-1 rule. Teachable moment.
Go on...
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.
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.
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.
Why are they messing with the source control options when they're not using source control? Perhaps learn about stuff before you start clicking buttons and performing delete operations on your super critical files?
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.
Makes no sense to me. I’ve never had a single problem. Best ide I’ve ever used.
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.
VSCode is absolutely fine.
Most of these comments can be reduced to either
-
I use CLI by the way...
-
Hating on VSCode because it's Microsoft product and for no other reason.
A Gitlab/GitHub account is free. VSCode absolutely lets you type git commands if you prefer that, The GUI only provides access to the most common actions you will do. And I could be wrong on this, but I feel like the discard button does prompt the user that the files will be permanently deleted and you have to click okay. But maybe that only applies to tracked files, not sure off the top of my head.
-
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).
(VS)Code(ium) is great. (VSCode is MS fork of the OSS Codium.) It's a popular editor with a lot of plugin for just about every language. It has an integrated console. It can do basic Version control (and you can use the console for anything more). It's my favorite editor/IDE (not technically and IDE, at least out of the box). Just don't do things you don't understand. It's that simple. The OP fucked around, and they found out what it does the hard way. It's really easy to use if you have a basic understanding of things though.
Every new project for me starts with setting up git. There's no reason not to. It takes seconds.
Nah you gotta submit a bug report for that
Yeah, standard practice is to set up source control before doing any work at all. Then you add whatever project template/scaffolding files to an initial commit and make it, and keep committing from there.
You should always be committing early and often. Saves you a lot of headache and make it a lot easier to clean up your history later too.
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 is without gitignore, so probably just installed one js dependency
Monorepos are a thing. But obviously this is something entirely different.
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.
Look at him. He's just learned that files can be deleted without going info the recycle bin, and he already wants to be treated as equal. Ha!
Doing a
git cleanis a dick move.The user clicked an option to "discard" all changes. They then got a very clear pop-up saying that this is destructive and cannot be undone (there's a screenshot in the thread).
Yeah, real developers do
git clean -dxf.
Jesus saves, and so should you
Often times, people learn that the stove is hot by touching it.
It's easier to blame the stove than the person who touched it. But if you laugh when you watch it happen, you're probably not laughing at the stove.
This is my take on this. People blaming the software but the truth is that no software can be trusted. Make backups. Make mistakes and learn. Sometimes it will be painful, but those are the most valuable lessons
In reality, VSCode has local file history called "Timeline". It's enabled by default.
https://github.com/microsoft/vscode-docs/blob/vnext/release-notes/v1_66.md#local-history
If the files were already staged then git should have blobs in the git folder, so they should be recoverable.
Looks like they weren't staged. He clicked on the staging option, it showed it would stage thousands of files, he said "hey I should fix my .gitignore" and clicked on what looked like either a "don't stage" or a "forget" button, and it was a "checkout --force" button.
The most impressive thing is all the people doubling down on the idea that a "checkout --force" button in a main interaction screen is a great idea, there's nothing wrong with the software, and the user is a moron.
"discard changes" button - the 5000 "new file created" changes, specifically.
Did you read the thread? There was a bug that deleted all files even ones unassociated with git.
Sounds like they weren't even using version control, and had no business anywhere near a project that size.
note to self: never use "discard"
Looks like windows should come with a dictionary.
"Huh, discard, I wonder what that does. Let's try it on all my work from the last six months"
Idiots gonna idiot...
Problem is, there's an entire generation of users that have gotten super used to "discard changes" as a means of signalling "on second thought, don't do anything".
That's definitely how it is seen.
If I were to see "Discard Changes" anywhere in a dialogue, I would assume it will discard whatever changes I made in that dialogue. In this case, probably some source control related changes. If it were to say "Warning: This will Discard ALL changes!!!", I might do a double take, but had I never usedgitCLI before, I would still assume that at most it would discard "ALL" changes made in the current session.For me personally, I would consider it more useful for it to say:
This action will delete the following files: - followed - by - a - list - of - files - that - would - be - deleted Continue?Which neither has to look like a warning, acting like you might be doing something you don't want to and also is much more useful for someone like me who wants to double check what exactly I am deleting.
Also, I have used
gitCLI before and apart from being able to seeblamein the editor itself and maybe a better representation oftree, I don't feel the need to use anygitGUI tool. Even when I tried, I realised it was slower and more finicky to use. So, it would stand to reason that it should be targetted towards people who don't use CLI (and might have never usedgitCLI).From a certain point of view - isn't this exactly what happened here?
I often go into a Git worktree of one of my projects and mess around a bit to try something out. If I find it's not working, I tell git to discard the changes with
git checkout .andgit clean -df. What I'm saying is exactly “on second thought, don’t do anything" - while what happens in practice is that Git restores all files to theirHEADstatus and removes all the new files that are not already inHEAD.Of course, the difference is that I already have all the work I want to keep under source control, so these changes I've discarded really were that - just changes. He, on the other hand, "was just playing with the source control option" - so these "changes" he was discarding really were all his work. But Git did not know that.
This feels like when my brother backed up a file with Onedrive, then figured he could delete the original... the one that Onedrive was keeping track of.
It's not that these aren't confusing, but why risk your file without testing what the software will do first? Especially before hitting anything like "delete" or "discard"?
See, that's a mistake I could see myself making. I would just assume that OneDrive was making a backup, not tracking the file.
I agree with the "learn the CLI", but to newcomers I'll also suggest to look at the IDE/editor's output channel - if there's GUI for Git, there are also most likely logs for what's happening under the hood - even if a little noisy, it can be a good learning resource. And of course if you're learning and unsure of what's happening (with the CLI or through a GUI), do so in a non-destructive manner (by having proper backups).
Same account that complained about the christmas santa hat
Link? It being "ghost" just means the user has been deleted so I can't actually go looking.
please fix uwu
VS Code could really use some work in that regard and I really do feel bad for that person, but this is also just funny as heck
In fairness, it's an old issue and they did put in the work to address the issue report.
Maybe he would prefer perforce.
Or Jazz RTC. That one was fun.
VSCodium better
This is 2000% user error lmao even tho VS Code is a pain in the ass on w*ndows
EDIT nvm my reading is 2000% user error
So VS Code isn't just slow and bloated, it also deletes your files. So glad I was turned off by its excessive memory consumption and deleted it before it deleted my files.
Edit: also why I only ever used git from the command line, I never found a git UI that is easy to understand, and never trusted them.
VS Code slow and bloated? Someone hasn't been spending nearly enough time in IntelliJ
It's really not slow or bloated. There's a reason it's so popular (even in Linux)
If it's running slow, maybe it's time to check your computer....
I literally had to use it to load 100 git projects simultaneously recently
No it doesn't delete your files. Hombre from the post told it to delete his files and was then shocked when it did. It even warns you that it's about to delete your files. Then on top of that, post person wasn't even using source control, so they can't get their files back. Don't mess with the source control options if you're not using source control. Don't just randomly click buttons without reading, if your project files are super critical. Don't only have a single version of your entire project in a single place on one computer. This person obviously has no idea what they're doing, which is fine, but they don't belong anywhere near a 5000 file project.
You think VS Code is slow and bloated? What do you use?
Also, on several occasions I've had VS Code help me recover accidentally deleted files, because the editor keeps the file in memory, regardless of if it disappears on disk (like most editors).
is op stupid ?
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.
Someone who does not know about "permanent delete" and not having backups, especially when switching to a new system, should have no business complaining about this.
