Getting to "Fuck this noise, I give up." is a very clear indication that you aren't competent enough and you should take a GOOD course about git as soon as humanly possible.
> Getting to "Fuck this noise, I give up." is a very clear indication that you aren't competent enough
I think that's a tad judgemental for two reasons:
1- because git is legitimately hard to learn. Personally I suspect git is unnecessarily hard to learn, that command names and the concepts and workflows I need are possible to learn and use with less effort. For many years people around me have been asking for git help because I know how to recover from lost stashes and use the reflog, etc., and yet I still have to google the magic incantations for commands I use regularly because they're impossible to remember.
2- There is actually a lot of value in being able to spin up a new repo instantly, in knowing that you can, and in practicing it often. Not unlike the move to VMs for development environments. Plus, there are definitely bad situations where a fresh git clone is the simpler way to go -- just not in this article. ;)
Anyway, I also agree with you because this blog post doesn't describe any truly bad situations, and because for years I've seen people blowing away their repos and starting over, and always thought to myself it was funny. It's a drastic action that takes more work than a rebase or reflog or whatever the problem was, and doesn't work well if you've made changes.
1- That's certainly true, git is really hard to learn. But if you're a developer it's worth getting comfortable with it, which means not going for the "nuclear option" every time something weird happens. Someone on StackOverflow has had your problem, and has the perfect fix, look that up instead.
2- Yes, absolutely, it's good to remember that it's a fairly painless and easy process to spin up fresh clones. Though, if all you want is a fresh copy, in 99% of cases a "git clean -xfd" will do that for you (read the man page to find out what the options mean! man pages are your friend!). Though that one is generally a "pull ripcord in case of emergency" type of command, "git stash" generally suffices and avoids risk of losing data.
I don't recommend git stash, it frequently causes bad situations. Just branch instead, branching is safer and just as easy as stashing. Stash is not as safe as other git commands. From the man page: "If you mistakenly drop or clear stashes, they cannot be recovered through the normal safety mechanisms."
If the "right" solution is more difficult, and no more effective than fucking this noise, then in what sense is it even desirable or good to use the "right" solution? How is it more right?
I think the nuclear option is pretty nice, since it solves every git problem I've ever heard of. All the "right" solutions only solve some particular slice of cases. Why should I be bothered to care?
Totally depends on the situation, but it's uncommon for nuke to be easier and more effective than fixing things using a rebase. Specifically, all of the examples in the blog post are easier to solve with the right git command than they are with a nuke & re-clone.
There's a class of bad situations that nuke will make worse and not better. Any time you have un-pushed work, you're better off figuring out how to restore it with proper git commands than by nuking your repo. Dropped stashes or screwed up merges or rebase mistakes are all things that take some unavoidable time to learn how to fix.
If we had to take a GOOD course in every tool that can be used when writing software then we'd have no time to, you know, write software.
Not all people who write software are full-time developers. Not all people who use git are developers at all, come to mention it. Not all people who use git for one thing use it for everything. Not everyone can justify the time required for a course for something that might be a tiny part of their work.
Most of the problems can be solved easily if this is understood - Quote from that article - "Absorb that, internalise it, make it your mantra for the rest of your life or career: a git repository is a tree. "
I think that's a tad judgemental for two reasons:
1- because git is legitimately hard to learn. Personally I suspect git is unnecessarily hard to learn, that command names and the concepts and workflows I need are possible to learn and use with less effort. For many years people around me have been asking for git help because I know how to recover from lost stashes and use the reflog, etc., and yet I still have to google the magic incantations for commands I use regularly because they're impossible to remember.
2- There is actually a lot of value in being able to spin up a new repo instantly, in knowing that you can, and in practicing it often. Not unlike the move to VMs for development environments. Plus, there are definitely bad situations where a fresh git clone is the simpler way to go -- just not in this article. ;)
Anyway, I also agree with you because this blog post doesn't describe any truly bad situations, and because for years I've seen people blowing away their repos and starting over, and always thought to myself it was funny. It's a drastic action that takes more work than a rebase or reflog or whatever the problem was, and doesn't work well if you've made changes.