Is that better or worse than pushing a corrupt C-00000291*.sys?
this post was submitted on 23 Jul 2024
444 points (96.4% liked)
Programmer Humor
19503 readers
585 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
Better. I'm not even sure this is bad, per se. Presumably you're sure your present repo is trash.
Why learn how to use the entire swiss army knife when you can keep it closed to use it as a very small hammer?
I always use this command as $rm -fr and read it as remove, for real
I do write it as rm -rf, but then my brain always continues singing The Lion Sleeps Tonight...
singing The Lion Sleeps Tonight...
"reeHEEEEEEEEEEEEEE--EE--Eaally ya-sure ya-wan-nadothaaat?"
(rm -rf, rm -rf, rm -rf)
it's for the French locale
Hey, sometimes you need to hose out the cruft.
Why yes, I do maintain a legacy application that still stores user files in Program Files in blatent violation of 15 years of Windows best practices and continues to be done contrary to my repeated advice, why do you ask?
Another one of this kind is rm -rf node_modules && npm install
Why not git clean -dxf?
Nuke the reflog
What? Why would you need to do this? Is someone fucking with the .git directory?
It does sometimes happen that something in there just breaks and isn't easy to recover. But it can also be a matter of (inexperienced) devs just deciding, fuck it, I won't try to merge it, I'll just copy my changes elsewhere and throw away the repo.
I have never had git get into a state I cannot get out of. Even if that is a reset, checkout or clean. And those are very rare. How are people breaking things so often.
Learn the tools you use daily, it saves you a lot of headache in thelong term.
Oh yeah, but I'm talking about the internal Git state just genuinely being broken, for example: https://stackoverflow.com/questions/14448326/git-commit-stopped-working-error-building-trees
Ultimately, if you spend half an hour debugging that, it just starts being a waste of time compared to cloning anew.
As for how to merge, yes, one should learn that. The problem is that the complexity of the code changes adds on top of whatever insecurities you might still have with Git.
I did put "inexperienced" in braces there, because even as an experienced dev, merges are sometimes just not worth doing. In that case, you could just checkout the branch a second time, but well, still not that different.
Step 1. Forget to push local commits
Step 2. Push commits from another machine
Step 3. Pull from remote om the first machine
I'm a bit of a noob, I often do this when I get too careless.
That should not break things though. Maybe get a merge conflict that you need to sortout at worst. This is essentially the constant state of working with other people on a project.
But it can also be a matter of (inexperienced) devs just deciding, fuck it, I won't try to merge it, I'll just copy my changes elsewhere and throw away the repo.
Pretty sure that's actually it. Git has a learning curve and, for example, some naive rebase not working out as intended can be scary if you don't know what you're doing.
People inexperienced with git can get stuck after doing some funky checkout / rebase stuff. If you don't know your way around git so well, I guess this is the obvious solution.
I've been doing this yesterday. Not because Git broke, but since Intellij kept pulling invalid configs from the cache, and that was based on some kind of path identifier it seemed.
Gradle!
Fucking gradle. I do config stuff, rerun gradle error here, I fix the error rerun gradle: sth. Violation error.
Ok intellij invalidate chaches and restart.... Still same error.
Fine I'll do it again
git add.
git commit -m "stuff"
git push
rm -rf repo
git clone repo
You can probably use something like
git clean -xdf
To get rid of all the artifacts not tracked by git, in this case it's virtually the same as deleting the repo and re-cloning it.
NOTE: Make sure everyhing is staged, otherwise that data is gone
I feel dumb: Why git rm -rf and not rm -rf? O.o
git rm -rf is only usable within the scope of the git repository and removes files in the staging area and working directory but doesnt affect untracked files or .git. rm -rf affects everything. For this case rm -rf probably would be the better option
edit: did a quick edit on the meme to change it to rm -rf since it makes more sense
rm - rf is the only version that makes sense, since the only reason to delete and re-clone is to recover from an unexpected .git/ state, and git rm won't remove that.
Thanks
Never heard of it, makes total sense, but I'd guess 95% of developers just nuke the directory raw.
That's the joke, yes.
I guess that's probably easier than learning how to wipe your ass.
ew french language pack gross
Delete container, rebuild container. Sometimes it's just useful to clean up all the mess of cache files
Crowdstrike?
No, not this time, at least
