[bsder]

Sapling is Mercurial with some advancements. Mercurial is ridiculously better than git, but lost the network effects battle due to Github. So, JJ probably doesn't give you anything amazing.

JJ is useful for those of us who understand the shittiness of Git but have to work in a world that got locked into path dependent network effects by VC money.

[CharlieDigital]

From the blog:

    > When I left Google three years ago I recall they were trying to figure out what to do about either making Git scale, or adopting Mercurial, or what.

It's interesting because I used Mercurial (hg) for close to a decade after coming from Subversion.

Rarely had to consult the docs for weird edge cases and generally operation felt natural and seamless. It was easy to onboard new devs of all experience levels.

I switched to git 5 years back and I still feel lost sometimes and inadvertently end up in detached head state once in a while. Git feels really "unnatural" or "unintuitive" to me in some way that Mercurial never did (I can't put my finger on why because I never gave Mercurial much thought).

[sunshowers]

You're like most developers! The core problem is that Git's workflow treats branches as the source of truth for what's in the repo, while Mercurial and its progeny (Jujutsu and Sapling) treat individual commits as the source of truth. The latter is vastly simpler, and also (as Jujutsu shows) more powerful.

While working on a stack of changes, you should be able to check out an earlier commit, amend it, and have its descendants be automatically rebased. Of course you should be able to -- this is a natural and straightforward way to think about working on changes, and builds on prior knowledge about how to work with individual commits and how to rebase them onto a newer upstream. Now compare this to git rebase -i.

[fragmede]

Mercurial was slow, right when it mattered, and didn't have the Linux kernel using it. GitHub's VC funding helped, for sure, but that had more to do with the rise of GitHub over Gitlab, SourceForge, Google Code, and BitBucket than the success of git itself. Getting people to switch RCSes has a bootstrapping problem that the Linux kernel solved for git. Firefox was on Mercurial/hg, as was CPython, but neither of those have the same ecosystem of developers.

if you take the time to learn it, the underlying data model for git makes sense, leading to the tools making sense, for those that put in the time investment to understand the underlying data model. This meant that there was a bunch of git expertise floating around IRC and mailing lists. Git tooling also wasn't super opinionated, letting pre-git workflows be run on git with little modification (which is also its problem, but does drive adoption). Sure, a recommended workflow has emerged, but that came later. By the time GitHub started in 2008, that was three years after its invention and use on the Linux kernel and git already had the mindshare and intertia. Without VC funding, GitLab or BitBucket or even Google Code might be the dominant platform, but it really was git's speed and fast branching, and proven scalability from managing Linux kernel development that led to git's rise as the preferred solution. (Its inability to handle monorepos like Google/Meta wasn't an issue for that time.)

Mercurial's lack of speed and inflexibility are what hurt adoption. VC money pouring in might have saved it, by somehow addressing those two issues, but unfortunately we'll never know. Mercurial's workflow is pretty central though so I doubt its community would have supported changes to the central workflow. Moving from Subversion to a DVCS (aka mercurial/hg or git) required learning a new tool and being forced to change workflow on top of that made the decision to go with git easier since a git expert could make a company-specific cheat sheet that didn't also require learning and adapting to a new way of working at the same time.

Most of the world was on SVN by the time git came around, and Git-svn was a pretty popular adapter. You could use git and its fast local branching before the company turned to git. I really can't stress the fast local branching enough as a reason for git winning. SVN server-side branches took forever to be created (even with the underlying data not actually being copied) and I remember even just running "hg" and no arguments being slow.

VC funding helped GitHub, but git still would have won out because hg didn't have a dev community to rival the Linux Kernel. Maybe Wikipedia/Wikimedia, but that's a much smaller codebase.

[sunshowers]

> I remember even just running "hg" and no arguments being slow.

This was definitely a really big complaint. Python's just slow to start up, and last I checked Python 3 makes things even worse here.

Startup time really made me believe that the optimal language to write CLI tools is Rust.

[pimeys]

That and the great libraries Rust have for CLI apps. Really good stuff, and you can get productive quickly.

[samatman]

Git succeeded to large degree because of GitHub, yes. But that isn't how it happened at all. They built an amazing product that people loved, there was nothing even vaguely like it before, and it earned its adoption through providing a superior product than the competition, by leaps and bounds.

It ended on a bitter note when Microsoft bought them, sure. But let's not rewrite history, GitHub was not dumped on the market by deep-pocketed VCs. GitHub was self-funded from 2007 to 2012, at which point it was wildly popular and used a big cash injection to get to where it is now. By the time that happened it had the #1 position in commits per month and was about to become #1 in repos hosted also.

[layer8]

Git and Mercurial both were initially released in the same month (April 2005), and DVCSs had existed for some time before [0]. Linus even considered Monotone, which is also based on SHA-1 hashes, as a replacement for Bitkeeper before starting his own Git. Most people who worked with both Mercurial and Git consider Mercurial’s UI to be superior. It was mostly the draw of Linus and then GitHub that made Git “win”.

[0] https://en.wikipedia.org/wiki/Distributed_version_control#Hi...

[riwsky]

You aren’t contradicting your parent; neither Linus nor GitHub were VC money dumps.