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…

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.

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.

3. Ignore the scary warning VS Code shows you when you press the button.

The dude ranted for awhile in the issue thread and closed the issue himself too! lol

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.

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.

3 backups: 2 different places/media on-site 1 off-site

This person is why we have that meme where devs would rather struggle for a week than spend a few hours reading the documentation.

Just curious, git doesn’t touch untracked files though?

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.

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