Git is probably a technology people don’t feel comfortable criticizing because they think whatever problems they have with it are due to them not properly understanding it. I suspect that they feel like disliking it is akin to admitting ignorance. I have this intuitive feeling that git’s design suffers from unnecessary complexity. At some point someone will come along and make an easier to use dvcs, and git will fall out of popularity like cvs did when subversion showed up.
Having now used a number of other VCS tools (Perforce/Piper and Mercurial), I still think git intuitively gets the "model" right, better than the others, but goodness the API naming makes almost no sense.
Git is a very sophisticated and substantially well built tool, with several key weaknesses that border on fatal flaws. Unfortunately, too many of the people in control of git's fundamentals and ux don't recognize those flaws as such and refuse to fix them. This has a bizarre consequence of causing many who also see git as one of the best VCSes out there to fail to see those flaws clearly as well due to groupthink. Unfortunately it will likely be years and years before they're seriously addressed.
3. Simplisitic branch namespace forcing repos to be used as semantic concept
4. Lack of O(1) incremenental checkouts.
The good news is a reimplentation could solve all of these but the namespace probablem, which in turn could probably be a very lightweight protocol extension.
The UX in general is a mess. There are odd inconsistencies between how things are named, how parameters are used and what they're called throughout the CLI. For example, sometimes you use remote/branch sometimes you use remote<space>branch to reference a branch in a remote. It's a little thing, but it adds up along with everything else and is effectively a tax that uses up mental capacity that could have been better spent elsewhere.
Additionally, the whole workflow around branching and rebasing is pretty terrible. Almost every demo I've seen of how cool and useful rebasing is inevitably runs into some huge fuckup that has to be backed out of carefully. It shouldn't be that hard, even in complicated situations that happen less often but are still common enough to happen routinely.
In a similar vein, the tooling that git (and github) provide for merging and merge resolution are terrible. They work only in the simplest cases, and for anything beyond that they just start to fall over. Almost every developer who has used git has ended up in a situation where git fucked up dealing with a merge conflict so bad that they had to just do the work manually by opening up some "base version" of a file then meticulously applying diffs by hand coding and then figuring out what the final file should look like starting from there. I've used a lot of different VCSes over the years and git is surprisingly one of the worst at this workflow. It relies far too heavily on commit history to figure out the right thing to do and it doesn't even leverage that as well as it could. VCS tooling should help the user, not shove them into the middle of a bunch of machinery and then force them to do all the heavy lifting to make things right.
Code reviews and branch management are also very weak in git/github, for no good reason. Again I've used a ton of different alternatives, some of which were just internal tools built by random folks in the company, and almost all of them were superior to the experience with git. Given that merging and code reviews should be where git/github shine, this failure makes zero sense to me.
Good tools do the monotonous grunt work heavy lifting for you, they make easy stuff trivial, hard stuff easier, and they help you manage the complexity of the really difficult stuff. Git does a good job of this sometimes but when it fails it fails hard. Git is like a multi-million dollar yacht that has some components held together by gum and bailing wire. And when you run into those parts you look around with an expression on your face of "can you believe this shit?" and yet only a tiny fraction of the people around seem to see what you see, all the rest seem content to just ignore it, imagining that that's just the way that all super yachts are built, or something.
There are so many ways that it's easy to just be doing normal day to day stuff in git and end up in a bizarre state that causes your productivity to come to a halt while you figure out how to fix it. Detached head? Uh, how did you get here, what does it mean, how do you get out of it, how do you ensure you aren't accidentally destroying work? Failed rebase? Poorly handled merge conflict? Even simple stuff like reverting local files or rolling back commits is harder than it should be. And the fact that "git push --force" is ever, ever, ever seriously recommended, ever. All of these things could be vastly improved by taking the time to do some quality of life improvements, but the git maintainers think that there's nothing wrong with operating a tool that is half luxury level fit and finish and half exposed razor sharp gears and live uninsulated wiring.
Git is a technology people don't feel comfortable publicly disliking because the obvious alternatives tend to be even worse.
You don't put things on your "won't use" list because they have design problems, you put them there because you want to use something else that you like better; so decent things get disliked because you simply prefer a different style but horrible things get accepted if there's no better choice.
