A lot of it is familiarity and opinions. I was never as familiar with mercurial and so I liked git better. Mercurial is a longer word so for the rest of this I’m going to call it hg. I had friends that liked hg, but it’s been years so some of what I say may be wrong or vibey.

I think the main thing hg has going for it is that it works closer to how people think git works. There’s no concept of the index, it just adds all the changes from your working dir like git commit -a. I’m pretty sure rather than storing the full contents of files like git, and then computing the diffs for display, I believe hg actually stores the changes as a series of patches.

And if I remember correctly for that reason patches on hg “belong to” a branch rather than branches pointing at commits in git. This makes things like cherry-picks and rebases harder and thus less “normal” operations, and IIRC it was a bigger deal in hg to accidentally commit to the wrong branch, whereas with git you can use the reflog to reset the branch to where it was trivially, and that commit you made is still floating in the store with an address even with no branch pointing at it, so you can just point a branch at it still, or cherry-pick it to another branch or whatever. Nothing was lost.

But the main thing people talked about was the simplicity and intuitiveness of the commands. And I think a lot of that comes from the fact that hg worked the way people thought it did and the way people used it. So it was intuitive.

Whereas git, as I described in my main post and it’s follow-ups, is actually an addressable tree storage system with a version control system built on top, which gives it immense power and flexibility, but only if you teach people what git really is. It is intuitive once you know what is actually doing, but most git tutorials assume people can’t understand because it’s “too complicated”, or that they won’t bother to learn because it’s a side quest on the goal to just get tracking versions.

So the tutorials teach git as though it’s mercurial: like there isn’t an index, like changes are patches, like history is linear, and then yeah from that perspective the commands are unintuitive. Why do I have to add files with git add, but then commit with git commit -a all the time? Why would I need to pass a flag or it’ll do nothing? Shouldn’t that be the default? And then when fixing merge conflicts, I use git add for that too? The command I only use for new files? Why? What are all the flags to git reset? Why does that un-add stuff, but also rollback changes? Why when I checkout a commit am I in a broken “detached head” state, and the thing I was meant to use was git reset again? That’s random. I did a rebase, it didn’t go well, and now git “broke my branch” and my changes are gone.

And so they’ll go for 15 years of their career not knowing how the tool they use every day works, running the same 4 command strings they learned from a tutorial for beginners, and then sometimes something “weird” will happen and they’ll be confused or angry. Because they didn’t take the 30 minutes it takes way back at the start to teach git as git, at which point the commands names still are a smidge weird, but their operation is crystal clear and consistent.

And git reflog heals basically all wounds.

So yeah, that’s my impression of hg from way back. Simpler and more limited, which had the benefit of therefore also being easier to use and more intuitive because it implemented exactly what people thought it did, so there was match-up between interface and implementation.