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).
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.
Backups, backups, backups.
Like, damn son, at least make a daily archive of your project??
You have to expect things to go wrong, otherwise you have no one but yourself to blame.
I fucking HATE when abstractions over git use cutesy names that git doesn’t use.
Doing a
git cleanis a dick move.Yeah, real developers do
git clean -dxf.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).
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.
Yes, the dialog was changed, as part of this linked issue (and maybe again after that; this whole incident is very old). After reading some of the comments on that issue, I agree with the reasoning with some of the commenters that it would be less surprising for that menu option to behave like
git reset --hardand not delete tracked files.
please fix uwu
Screenshots of git issues are one of my favorite genres of meme
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
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.
Linus Sebastian enters the chat
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.
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”.
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
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.
Right? “You are about to permanently delete 5,345 files, they will not be sent to the recycling bin, are you sure?”
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.
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
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.
is op stupid ?
It does warn you it will erase the file when you discard…
Warns you that changes will be discarded…not quite the same words
I just tried right now to get the exact message.
Are you sure you want to DELETE foo?
This is IRREVERSIBLE!
This file will be FOREVER LOST if you proceed.The confirmation button even says
Delete File…User error.
This issue was from 2017
Ah looking at issue 32459 it was addressed shortly after.
You’re right that it did originally say “Discard”.
If you use git and understand that VSC’s source control stuff is just a thin wrapper around git, you should understand what “discard all changes” means
“discard” is not a git operation. Reset and restore are, but those weren’t the words used.
I’m not claiming that “discard” is a git action. I’m claiming a git user should understand what’s meant by the phrase “discard changes”. Run
git statusin a repo that has changes in the working directory. In the resulting output, there’s a message:Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) ...The phrase “discard changes” is used consistently in git’s output.
Read this comment from the linked bug. https://github.com/microsoft/vscode/issues/32459#issuecomment-322160461
Ok that’s understandable, I didn’t realize VSCode used to delete untracked files as well as a result of clicking through that dialogue.
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.
It’s not a bug, it’s intentional. They consider changes to be any change since the last commit including in untracked files. They did update it to make this behavior a lot more obvious though.
This comment in particular does a great job of explaining the UX problem with this. https://github.com/microsoft/vscode/issues/32459#issuecomment-322160461
Yes, honestly this situation reminds me a lot of the LTT trying Linux and destroying his system by installing steam despite apt warning him in the best way it really could that he probably didn’t want to do that. Sure the package shouldn’t have been in that state in a stable distro but shit happens. It goes to that point of, users will go through great lengths to achieve the end goal blindly jumping past warnings on the way no matter how dire they might be.
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.
Man who clicks confirmation for leopards to delete his work is angry and surprised when his work is deleted.
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
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
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.
You get pretty far with just clone, pull, add, commit, push
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.
-
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.
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 😁
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 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
If I want to commit a selection of files, but not others, then I’m clicking boxes not typing filenames.
Did 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.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 -p
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.
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
Maybe he would prefer perforce.
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.
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”?
