Linux

Again, github. If Mercurial had had something like github, it would have been closer. Github was git's killer feature; git itself provided nothing except a bunch of kernel devs were using it - and I'm not convinced that alone would have propelled it to success. Kernel contributors don't make up a large percent of all developers in the world.

Mercurial isn't perfect. Being written in Python frequently makes it a pain, but it's slowly converting to Rust.

I do wish darcs - also hindered by the language choice of the author - had done better. Theory-of-patches was incredible to work with, and practically eliminated merging being an issue. Pijul is going that route, but until they open source a server, it's a non-starter for me.

All of my personal stuff is in hg repositories at Sourcehut. Mercurial is, thankfully, still popular enough that it's got a reasonably large dev team and still has regular releases. As long as that holds, I'm good.

UX. The UI also sucks, though, in that the commands are obtuse, the behavior is complex and demands a relatively high cognitive load, and for very little gain. I guess if you interpret "UI" as "the command line," I won't complain. But the interface for me is the set of commands and operations you perform with them, which are awful and poorly designed - bad UI leading to a bad UX.

The shitty set of operations and how they modify history. It's an interface, the same way that an API is an interface. User Interface =~ Application Programming Interface =~ Application Binary Interface. git's interface - the set of commands through which the user interfaces with the tool - stinks.

Why? It's clearly an opinion.

But, ok: pull and fetch are really similar, but not really. Here's a hammer, and another hammer that looks almost exactly the same except it works just a little differently, and if you use the wrong one situationally you can fuck up your history and have to spend an hour unfucking it.

You can change history. Not only can you, but it's a common workflow, and it, too, easily leads to messed up clones. This was simply a really stupid design decision for a VCS.

The vast variety of errors you can encounter working with others - the one key feature of a DVCS - is astonishing. TF is "fast forward?" Don't answer that, I know, but you know what no other DVCS suffers from? Fast forward restrictions. Or, how about detached heads? That's a pretty uniquely git-level idiocy.

Merging is so badly implemented, it's a common requirement for projects to demand that MRs be squashed down into a single commit.

Rebasing is even worse, such that users find themselves squashing history just to be able to successfully rebase.

git contributed no clever features, such as Darcs' patch-based management; it provided no simplicity, like Mercurial; and, frankly, if it weren't for github, it wouldn't be nearly as popular as it is. Github was so innovative and useful, it overcame the handicap of being implemented on git. git eventually got a bisect command, so I can't complain about that anymore.

I'm really pinning my hopes on jujutsu; so far, it makes working with git better enough that I don't mind using it, although it's still not quite as good as Mercurial, and it's still very much a work in progress.

You know where git doesn't suck? If you're working on a project, alone, and you never branch. Then it's not so bad. But, then, you may as well just keep your code in btrfs and make snapshots instead of commits.

Hm. Well, I've answered in angry detail in a response to someone else, but as evidence that I'm not some loner, I present you with:

• Mercurial, for which it's hard to find usage estimates
• Pijul, the spiritual successor to Darcs, much younger that git; also hard to find usage stats
• Jujutsu, an interface currently on top of git, as an attempt to make git suck less by giving it a more Mercurial-like interface (or, "workflow" since a large number of people seem to be struggling with the concept that the set of commands of a CLI tool is its user interface). This one's a little easier, because we can see it's got 12k stars on github.
• On the Jujutsu README is a link to a list of "other tools trying to solve similar problems", the "problems" being how much the git UX sucks. That page mentions git-branchless, sapling, gitless, and sturdy -- all front-ends to git with less bad UIs.

forget that, he said UI.

I had my rant here. Even I have a limit for angry vitriol. Honestly, I wouldn't care, except there are two things I'm collaborating with where I have to use git. Actually, for one I could probably use Jujutsu, but the other is One Giant Monorepos and has very specific requirements about how history looks, and I just can't ensure that without using git directly. And it drives my utter bonkers every time I have to commit, because: despite the fact that there are only ever one or two people editing any given file; and none of the files has anything to do with any other; because there are hundreds of people editing hundreds of files in this repo every month or so when I want to make a change it's a nightmare of pulling and fetching and rebasing and trying to squash things down so it's pretty enough for an MR to get accepted into master. I'm about to give up contributing to that one; it's not worth the git pain.

Then, I was collaborating on another project as a contributor; the project owner was slow to merge PRs, so at any point in time I had 6 feature branches waiting to be merged. Sometimes, they conflicted with each other, so I had to wait until they merged one, then I'd have to go in and fix the other so it could be merged. It was a nightmare, and I eventually just hard-forked the project. Granted, this would have been a challenging situation for any VCS, but git's merge and rebase are so awful it was especially painful. It would have been easier with Mercurial - it's smarter about merging and rebasing, mainly (I believe) because it doesn't have to contend with the possibility that someone caused a temporal paradox by changing history, but it would in most cases not been at all problematic with darcs.

My preferred VCS is Mercurial. It used to be darcs, but I started having performance issues with larger projects and gave it up years ago. If it had been able to keep up, I'd probably have stuck with it.

The other tool I use is Jujutsu. It's in heavy development, and there are still some warts, but I can work with git projects with it without having to suffer git.

I'm keeping my eye on Pijul, which is patch-theory-based, like darcs. I'm a bit concerned about the fact that it smells a little like it's going to be monotonized through never releasing a self-hostable server - right now they offer free project hosting, but it means you have to host your source on their servers, or not publicly at all, and that gives me the heebes.