Yeah pour another glass for Mercurial, it is a shame that git ended up winning, but then again what to expect when it was a child of Linux kernel project.
Some arguably* technically superior designs end up being obsoleted over time, because the arguably* inferior design ends up being more lined up with how people think and machines work.
This is what we're seeing here, IMHO.
*: There's nothing "objectively something" in computer science, because it's all is a pile trade-offs to get the desired result.
hg was not superior to git at v1. I have no idea if it is now. hg was horrible at git style branches wich are arguably a killer feature of git. I've heard they were grafted in to hg but you can go look up old tutorials on the net from say 2008 and see they were clearly not the norm for hg
---
looked it up, the feature is called "bookmarks" and was added in 2010. And even after added, all tbe tutorials ignored them. no idea if they are the recommended workflow now but if not then you probably don't get why git is superior to hg
Bookmarks were a wonderful feature and I used them all the time for release workflow. It was basically like tags in docker.
Hg was indeed better than git, especially in the early days. But as git added features, made sane default choices more common, and cleaned up the CLI a bit, it doesn't matter now. They all do roughly the same thing, but the Hg workflow was still better imo because they just worked more intuitively coming from never using any DVCS before.
Git has better performance for a lot of users in a lot of use cases. Git is certainly not always better-performing than Mercurial, but it is often better performing, and the performance differences have varied at different points in time.
Some parts of Mercurial struck me as obviously better than Git, like the overall CLI UX, but some of the differences just seem like differences that come with tradeoffs. Mercurial is somewhat more opinionated about branches and allows some weird scenarios like “branches with multiple heads”, whereas in Git, a branch is just a label for one of the heads in the first place. Git’s index seems to trip up a lot of beginners, but as a long-time Git user, I don’t know how I could live without it.
I can see why people say “subtly superior”, but I think the superiority is overstated. The CLI UX is the only part where it seems like Mercurial has a clear advantage (and maybe better support for large files).
Both Git and Mercurial works on graphs and use very similar structures, however how Mercurial uses this is mentally overloading, while it's very trivial for a computer to handle these.
Mercurial labels everything on the graph. Multiple heads. many branches, a working copy, a tip. Manual merges, mandatory merge revisions, oh my...
Very neat for enabling collaboration, very easy for a computer to handle, very simple to implement, but very hard to process for a human. Also very hard to follow provenance.
How we came here? X merges, Y branches, Z commits, a curvy journey through the graph. An unbounded art which needs time to grasp.
Git is simpler. Divergences are branches. You add commits at the top of that branch. The place you're looking is the head. Simple, more stupid, a more clunky approach which enables many more things.
How we did come here? Branched at X, added n commits, Y merged along the way, m more commits and ta da. Who added these commits and when? A on Monday, B on the weekend. D merged their work on next Tuesday, and I did mine on today at 10.
Want to chop of specific parts off? Possible. Fork from a branch? Possible. These are things mentally easier to visualize. Mercurial can do these too, but it's more work, more mental effort and more complex to visualize.
Mercurial might be a better DVCS for nerds, but Git keeps is simple as possible and gets the job done well. This is why many people prefer it, incl. me.
Fossil is also a good idea with very high mental load. An idea which is searching for a problem, but I digress...
Of all the adjectives used to describe Git, “simple” seems to me the least appropriate.
Yes, the internal Git implementation is a “simple” DAG of content hashes, but the rest of the plumbing leaks so badly into user space you can’t begin to call using Git “simple”.
The usage of Git is not simple for the beginners or advanced scenarios. Even Linus accepts this, and this is why Git is named Git [0].
However, the mental model required by Git is much simpler than Mercurial, or at least designed to be presentable in a much simpler manner, and this counts for many folks, even if these people can work with much more complex mental models.
At the end of the day, our attention span and power is limited.
Hmm, I held onto mercurial for years, feeling that Git was kind of incomprehensible. I have never really lost that feeling, but I can do a lot of things with Git that I never could with Mercurial, and short of anyone solving the ‘merge one patch to multiple different branches without a bunch of conflict resolution’ I don’t think I’m likely to switch.
The superiority of Mercurial works against it, because while https://xkcd.com/1597/ is entirely relatable, people are used to Git's specific flavour of incomprehensibility. It's normal, and the lore helps folk avoid the sharp edges most of the time.
git stores diffs, but the usual operations are between commits, which resolve to a snapshot, yes.
but there are operations that get the diffs (interactive rebase for example)
so, git, in typical UNIX fashion, is a bit of this and that, a very useful collection of tools to work on a repository, under some allegorical unification umbrella.
Layers of abstractions. From the outside, we see diffs (or checked out trees). Looking at the next layer in, every file in every commit is present in the DAG. Then the storage layer deduplicates and packs similar blobs as binary diffs.
It's quite neat, the object DAG is the canonical representation, but we can optimise on one side for efficient storage and on the other side for our preferred visual representation. Both without particularly needing to worry about the canonical representation being an abstraction, as it's quite good at not being a leaky abstraction.
There are, broadly speaking, two ways for a tool to become popular. The first is to be really good, and unfortunately that way doesn't work. The second is to already be popular, and that's where MySQL and Git came from. If git weren't written by Linus Torvalds, I'm sure it wouldn't have become nearly as popular.
Git is, per the XKCD, a really neat graph system. There's not much that's special about that, though. Now it exists, we can write another just like it as a programming tutorial. The UI is better than it used to be, that's pretty much the best that can be said about it. But if you know the magic incantations you need to interact with it, and especially if you're using IDEs, it's really no worse than CVS.
The biggest difference between git and MySQL is that the former is solid underpinnings but poor UI and the latter is poor underpinnings but easy to deploy. In both cases, the foibles are well enough known that most folk don't need to worry about them, and and most projects I've worked on would derive no benefit from switching to a different system that's only going to confuse people.
I say this as someone who appreciates the graph, but has occasionally resorted to invoking plumbing directly because I can't work out which plumbing commands would do what I wanted.
