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.
this post was submitted on 20 Nov 2024
539 points (97.4% liked)
Programmer Humor
19623 readers
1506 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 1 year ago
MODERATORS
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.
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.
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)
If I want to commit a selection of files, but not others, then I'm clicking boxes not typing filenames.
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.
load more comments
(1 replies)
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.
I fucking HATE when abstractions over git use cutesy names that git doesn't use.
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.
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 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.
Mein Gott!
Linus Sebastian enters the chat
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.
Honestly no idea why editors give shit random names instead of using the terms git uses.
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".
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.
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.
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"
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
load more comments
(3 replies)
Poor guy basically did a git reset —hard HEAD without even a git repository
view more: next ›