>but there are commercial alternatives (I'm thinking of Perforce) that make even less sense.

Have you ever worked with Rational ClearCase? It's a true horror show.

ClearCase is wonderful if you fit the use case, which is a sizable team on a fast LAN.

It's great being able to change a ClearCase config file to choose a different branch of code for just a few files or directories, then instantly get that branch active for just those specific files.

I have during several occasions in the past (up to 2007), and while it is a monster, I still felt more productive than using git nowadays.

Remember, back then companies had to hire dedicated Clear case engineers to get things working properly.

You mean just like we have to reach out to IT to sort out git issues for anyone that strays outside the path?

Not really a common occurrence here.

Does it happen often at your workplace? What kind of issues are we talking about?

Basically the usual ones that end up with copying the modified files to a temporary directory and doing a fresh clone followed by a manual merge and commit, because someone messed up their local repository while trying out some git command beyond clone/pull/push/checkout/commit, and now cannot push without messing everyone's else.

Interesting; that never, ever, ever happens where I work, and most of our engineers are fresh-outs.

How often does this happen? Doing a fresh clone should be a last resort.

A couple of times per month, not everyone is a git black belt.

And there are alternatives that make better sense, too.

But the existence of something even worse doesn't excuse something that is merely bad. And git is so much more widely used that its total overall harm on developer productivity is worse.

You really only need to know a half dozen commands for basic productivity.

I started in the late 90's when cvs was popular. Then we moved to svn. You had productivity issues of all sorts, mainly with branching and merging.