In the context of version control it does. Discarding a change that creates a file means deleting the file.

the alternative to deleting is emptying the file contents, which is essentially the same…

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 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…

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.

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.

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.

(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.

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).

Viscose is absolutely fine.

Most of these comments can be reduced to either

1. I use CLI by the way…

2. 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.

Oh, didn’t notice this was a 7 year old issue.

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!

I think it’s a joke about how noobs only learn javascript and make blazing fast webapps while knowing nothing about computers.

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 clean when you clicked this. Which like…yeah why the hell would it do that lol? I don’t think I have ever used git clean in my entire career.

He’s right, his shit doesn’t stink. His decision making was reasonable for a new programmer.

A feature that permanently deletes 5000 files with one click without warning deserves a fuck you.

I very much understand how one can think this would revert any changes done to files under version control but not delete the ones that are not. I believe this dialog has since been updated to explicitly state that fact.

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.

Yeah, those are novice numbers. I have infinite backups of my 0 files!

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.

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.

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

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.

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.)

That’s how git works. Every file and subfolder under the repo’s root folder belongs to the repo.

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

read the official book : https://git-scm.com/book/en/v2

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.

had no business anywhere near a project that size.

Lol. That’s a really good point, actually.

I add version control around file number 3200…

(I’m kidding. Writing even a couple lines without version control makes my eye twitch.)

“discard changes” button - the 5000 “new file created” changes, specifically.

See, that’s a mistake I could see myself making. I would just assume that OneDrive was making a backup, not tracking the file.

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 used git CLI 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 git CLI before and apart from being able to see blame in the editor itself and maybe a better representation of tree, I don’t feel the need to use any git GUI 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 used git CLI).

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 . and git 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 their HEAD status and removes all the new files that are not already in HEAD.

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.