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