Well, can you explain why it applies here?
Mercurial vs. Git is IMHO a textbook example of "good enough with large user base" beats "subtly superior with smaller user base" over the long term.
Mercurial vs. Git is IMHO a textbook example of "good enough with large user base" beats "subtly superior with smaller user base" over the long term.
---
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
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).
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”.
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.
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.
Meanwhile, you're saying git is aligned with how people think merely because it got more mindshare early on.
And no, it's not how people think, nor how git shows it. Git shows changes as diffs, while it operates on compressed snapshots.
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.
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.
Unpacked commits are snapshots.
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.