Git is so well-designed that expert users manage to trash their repositories and propagate the damage.
Maybe that's not a problem of libgit. But tools are both the infrastructure and the UI.
So, the solution to the fact that the merging UI is a pile of garbage is HAVE A SINGLE PERSON ALWAYS DO THE MERGE. Excuse me? The whole point of a distributed revision control system is so I don't have to have a single choke point. That's the definition of distributed.
Then there was the KDE disaster: http://jefferai.org/2013/03/29/distillation/
Yeah, the root fault wasn't Git. However, at no point did Git flag that something was going horribly wrong as the repository got corrupted and deleted. Other distributed SCM systems I have used tend to squawk very loudly if something comes off disk wrong.
Maybe the underlying git data structures are fine, but, man, the UI is a pile of crap.
And, I won't even get into rebase, because that seems to be a religious argument.
Seriously, you can not call yourself a git expert, if you think rebase is a difficult thing to explain.
Might you sometimes make mistakes? Sure. I hardly see this as a systemic thing, though.
The mirror shenanigans I agree suck. Not sure what the real takeaway is there, other than don't rely on mirror as a good form of backup.
That isn't what the post advocates. He says that having a single person approve the pull request is a good idea, but approving the pull isn't the same thing as manually doing a merge. Projects I've worked on required that the submitter merge master into their branch before their PR would be accepted.
