1. Linus Tovalds wrote it
2. GitHub
3. Linus Tovalds wrote it
To be fair, there are some real differences; e.g. there is no easy "hg rebase" by design, and whether that's a good or bad thing has been a topic of contention for about 15 years. But that Linus wrote it gave it a huge boost, and GitHub really was much better than many things that came before it (and arguably, still is).
I don't think performance was the main motivator; from what I recall it was mostly that Linus felt that the subversion model was "completely broken" and that there weren't any good distributed "bitkeeper-like" tools out there (and then, suddenly, there were three).
"When we first started working on Mercurial, we found that it was slower than Git in several notable areas. To narrow this performance gap, we’ve contributed over 500 patches to Mercurial over the last year and a half."
https://engineering.fb.com/2014/01/07/core-data/scaling-merc...
Personally I can't recall any serious performance difference after I switched from mercurial (which included some large-ish repos) to git, but it's been quite a few years ago and perhaps I just forgot.
Like the one I use semi often (aliased to re) is "git reset HEAD~1". If you read the Git book, you know what reset does, you know that HEAD is where you currently are, and you know that "~1" means "commit before". So you tell git to reset current tree to commit before the one you're currently on (essentially "undo commit").
Actually, having "git undo" to "revert whatever I just done, regardless of what it was" and "--explain" ("tell me what I am about to do") would probably help a lot...
0.5. it doesn't get in the way of getting things done (at least most of the time)
A lot of the UI simplicity of other tools rests on not doing (3). For example, OP awards negative points for rebase but as far as I am concerned I won't even consider using a UI that doesn't support rebase.
I don't. This is "worse is better" at its core! https://www.jwz.org/doc/worse-is-better.html
Simplicity of implementation prioritised over simplicity of interface can take you a lot further than the other way around, in a fast-changing, experimenting environment.
I do have a bunch of aliases and one added command (shortcut to deleting some stuff) but nothing really more complex that shortening up commonly used stuff.
Mercurial Queues exists and people use(d) it. It has many, many more footguns than Git, and it's shockingly easy to loose work. The fact that this was ever acceptable is interesting.
Phabricator is not good, or at least not as good GitLab, GitHub, or Gerrit (IMO). This is important, because Git alone is half the picture nowadays.
The extensibility of Mercurial is also interesting, and leads to codebase-specific commands. This is maybe good for long-term developers, but makes onboarding new hires just that much harder.
So Mercurial's UX being that much better than Git is - in my very limited experience - a myth.
I started using Mercurial as the first serious DVCS I used (dabbling earlier with things like bzr) and my experience doesn’t support this at all.
I think it’s hard to underestimate the degree to which familiarity skews these assessments, especially with the additional confounding factors of project custom and experience. If you first used Git when contributing to a larger or more complex project than you were used to, it’s easy to misattribute the challenges to the tool and forget that everything got easier with experience using any DVCS.
This is especially true for the not uncommon case where the problem is really that someone has strong opinions about how they think the tool should work and refuses to learn its actual design - I’ve known multiple people who ranted about Git who were also the guys who hacked up their development boxes before saying a project was too hard to install (“Python packaging is terrible!” “Didn’t you use sudo to overwrite /usr/bin/python with Python 3 right before getting all of those Unicode decode errors?”), or, in one notable case, say Debian packaging was broken after they manually upgrade MySQL and somehow managed to render the system unbootable.
Of course, Git won for a reason, but I doubt that it wouldn't have still won had it incorporated some UX design ideas from Mercurial or elsewhere.
> I have loved working with Git since it was created and I still enjoy working with it every day.
I have been profoundly frustrated by working with Git every day, hence the article, and the linked set of tools which I wrote to improve my workflow. Not even because its mental model is hard to grasp or that the UI is poor, but because it doesn't even streamline the kinds of workflows that it should be good at (in the article, and discussed in its own `gitworkflows` man page).