This description, by Linus Torvalds, on how to revert a faulty merge reminded me why git is the wrong choice for many projects:
https://kernel.org/pub/software/...

Or just use ci to make sure you don't merge broken code.

Continous integration is no silver bullet to ensure that "broken" code isn't merged into a release branch. Test coverge will never be 100%.

What would be your preferred alternative to Git?

@krylzkvi it should be enough to prevent regressions, or else what good is it?

So what is the right choice?

@spongessuck the problem is that the regression tests themselves can be "broken", i.e. only testing a small subset of what should have been tested or being plain broken. In the end things will broken all over the place and the need for reverted commits will not go away.

Iff a project is populated with developers sharing a common network (even via ssh) I would not use a DVCS; not if it include all the *pain* git introduces. I would just stick with, for example, svn. Iff the developers do *not* share a common network I would pick git and live with its bloatness. In that case all the git pain at least has an upside.

Well, I still don't see what you mean. If a faulty merge occurs, tag the last good commit on master in case you need to build, fix the bug, and merge it in. Like Linus says, continuing normally is a better workflow than trying to revert the merge. It sounds like you just have a grudge against git. I've never heard of anyone who knows both git and svn suggest using svn.

I must be unique then. Fine with me.