Ah, there it is. I was wondering when this would happen.
Facebook used to be involved with the Mercurial community, but it was difficult to work with them. They always wanted to do things their way, had their own intentions, and started to demand that the Mercurial project work the way that Facebook wanted. For example, they demanded that we start using Phabricator and started slowly removing sequential revisions from Mercurial in favour of always using node hashes everywhere, arguing that for their gigantic repos, sequential revisions were so big as to be useless.
Eventually the disagreements were too great, and Facebook just stopped publicly talking about Mercurial.
I figured they would emerge a few years later with their fork of it. They love doing this. HipHop VM for PHP, Apache Hive, MyRock; these are examples of Facebook forking off their development in private and then later emerging with some thing they built on top of it.
The Mercurial project is surprisingly still chugging along, and there are still those of us who actually use Mercurial. I doubt I'll switch over to Sapling, because I disagreed with the things that made Facebook fork off in the first place. But if others like Sapling and this manages to put the slightest dent into the git monoculture, I'm happy for the change and innovation. I really hope that git is not the final word in version control. I want to see more ideas be spread and that people can see that there can be a world beyond git.
Absorb is amazing! Even if you don't take up Sapling, there's a 'git absorb' plugin which I have found absolutely invaluable: https://github.com/tummychow/git-absorb
git-fixup will add fixup! commits, so it still needs the mentioned 'git rebase -i --autosquash' afterwards. Usually you do not even need to give it a specific commit if your branch is set to track an upstream branch.
Absorb is fantastic and one of Jun Wu's (seen in this thread as quark12) best contributions to Mercurial. I want everyone to know about this tool, it's amazing. I had fun trying to come up with a name for the feature:
It seems this is still based on changing history - Does hg have something to address the downsides of rebasing that are present in git? such as chilling effect on cooperation of branches (eg you don't dare touch or use remote branches which someone may use rebase on, and destruction of actual history for use in eg reconstructing a timeline of a bug and fix later found to be important).
Slight correction: HipHop for PHP was cleanroom, including rewriting large families of native extensions to work with its C++ runtime, although it eventually developed workalikes for the PHP dev headers to ease development. Source: I worked on HHVM, its JIT successor that initially shared its source tree and runtime.
Facebook developers seem to have a surprising amount of free time to go around reinventing things that are not obviously social network features. (Or to have had it in the 2010s, at least.)
Note WhatsApp had 35 employees when they were acquired and Instagram had 13. At that size you need to be productive at managing servers but you're probably not thinking how great it'd be to have a "whole new programming language and source control system" team.
WhatsApp and Instagram at the point of acquisition were simpler than Facebook is (and was), or even compared to what it is now. Once you scale you start to need a lot of engineers to help keep things standing up and everyone on the same page.
WhatsApp had like half a billion monthly active users when they were acquired, that could be considered fairly large scale, no? But I agree with your point in general.
Yes, but WhatsApp is a point-to-point communication tool with mostly small groups. Each individual message doesn't need to be distributed to a potentially very large audience like in Facebook, making processing and coordination of nodes smaller and simpler.
Note though that other large projects with similar scaling-git problems tended to just write wrapper tools to work around it, see how Chromium and Android do it.
I switched from git to Mercurial and was absolutely gobsmacked by how much better it is. The only comparison was switching from a Blackberry to an iPhone - everything just works exactly the way I want it to.
Yes, I read the manual for git, but I never needed to for Mercurial.
I guess you didn't start from cvs or svn, because the experience moving to git was otherworldly. If git was your first versioning system than you had to learn some concepts first, which you already internalized when you switched to Mercurial.
Due to my workplace I moved from svn to hg (awesome experience) and then from hg to git (terrible experience). That was years ago, and the git experience remains terrible.
If you're interested, can compare tfs to git. Maybe it's ide integration quality, but FWIW:
1) tfs: shelves are named and can be worked with independently; git: stashes are numbered in a sort of a stack and only the top stash is unpacked and deleted destroying your data, infuriating, also local edits are moved into the stash, not copied.
2) tfs: branches are mapped to different folders and can be worked on simultaneously; git: branches are mapped to single folder and switching branches deletes local edits.
3) tfs: pulling from server merges new text preserving local changes; git: pull and checkout deletes local changes.
4) tfs: can't commit unresolved merge conflicts; git: commits just fine, it's also not obvious if you have merge conflicts to commit or not.
5) tfs: handles concurrent edits as merge conflicts and handles them as they occur; git: you create feature branches and in case of concurrent branches you have merge conflicts when you merge to master, then you have p.4. Feature branches are advertised as a big fat killer feature of git, but I don't quite see the win here, you still have merge conflicts.
6) tfs: all commits in a branch are visible, it's not obvious how to delete them, you can only create rollback commits; git: if something happens to the branch label, the commits are gone.
> 1) tfs: shelves are named and can be worked with independently; git: stashes (...)
I don't think your comparison makes sense. Git stash is a way to quickly get to a clean local workspace that can be reversed as you see fit. You use local branches to track independent work.
> tfs: can't commit unresolved merge conflicts; git: commits just fine
Again, this doesn't make sense. In git, users determine whether a conflict is resolved or not. If you commit a changeset originating from a merge conflict, you have to explicitly state that the conflict was resolved and your changes are good.
> Feature branches are advertised as a big fat killer feature of git, but I don't quite see the win here, you still have merge conflicts.
Honestly I didn't understood what point you tried to make. Merge conflicts happen because multiple sources of change touch the same document region in a way that can't be resolved automatically, thus needing human intervention. To the best of my knowledge, there is no cvs in the world that eliminates merge conflicts.
Regarding Git's support for feature branches, the fact that you don't understand the big win Git brought to the world with it's branching model is already a testament to how groundbreaking Git was at the time, and how everyone around was quick to roll out Git clones that follow the same approach. To see what I mean, spend a day working with a SVN repository trying to do work involving feature branches.
> git: if something happens to the branch label, the commits are gone.
Aren't you actually saying that if you delete a branch then the branch is deleted?
I assume tfs and svn work with feature branches the same way. In my experience with feature branches in tfs they were a hindrance, not a win.
Local branches store immutable state, but shelves can be unpacked anywhere (like a stash), thus local changes carry over, but git deletes them on every occasion.
In a nutshell, git has an unintuitive and unfriendly CLI with bad defaults.
I want my VCS to be quiet, out of sight and do as it's told, because my main focus should be programming, not how to tame a tool that's supposed to save text. The fact that you have to "learn git", and that there are so many StackOverflow git question on how to do (what should be) trivial operations is probably a hint that things aren't great in the usability department.
For hg, I just read an introductory guide (I think it was Joel Spolski's one) and that was enough. I used to be able to do a more in-depth comparison and criticism but nowadays I use git and try not to think about it too much.
> In a nutshell, git has an unintuitive and unfriendly CLI with bad defaults.
I see this claim often, but it never is accompanied by evidence or any concrete example.
I've been using Git for years and I never noticed any semblance of unintuitiveness or bad defaults. Everything in the happy path is straight-forward, and all obscure things are a quick googling away.
Do you actually have any concrete example to back your claims? What's the absolute best example you can come up with of said unintuitiveness and unfriendliness?
In case I wasn't clear, "git has an unintuitive and unfriendly CLI with bad defaults" when compared to hg.
Just compare the man pages! "git help clone" vs "hg help clone".
A random (trivial) example off the top of my head. When working with branches:
> git pull
> git switch another-branch
Your branch is behind 'origin/another-branch' by 2 commits, and can be fast-forwarded.
(use "git pull" to update your local branch)
... why? I literally just pulled, why are you asking me to pull again? 99% of the people on the planet literally want the last version of that branch (provided there's no local changes leading to a conflict).
Compare with hg:
> hg pull
> hg update another-branch
Done.
I haven't worked with hg in a long time so I can't really provide an "absolute best example". All I can say is that, from memory, hg always got out of the way, and when I wanted to do something out of the ordinary I could either guess how to do it or it was easy to figure out from the manual.
With git, almost nothing's easy. It can become easy if you invest a lot of time in understanding how it works internally (which explains some of its CLI choices). But that to me is a sign of a bad tool. "all obscure things are a quick googling away" - why expose the user to obscure things to begin with?
The entire CLI is badly designed, with highly non-orthogonal commands interacting in unexpected ways. Recent versions of git has started introducing commands with a more top-down design (e.g. git switch), but that's a very novel development
Git also diverged significantly from the SVN command line, but instead of following the tasteful Darcs path of making commands clearer and cleaner it commonly:
- reused the same terms for different operations, usually less intuitive ones (e.g. the absolutely awful "git revert")
- removed clear commands to confusingly tack them onto others (e.g. "git add" to resolve commits)\
On that front, mercurial extended the existing commands-set much more cleanly and clearly.
Mercurial's CLI felt like an improved extension of SVN's, Darcs felt like a drastically different take with plenty for it, Git's felt like one of those ransom letters cut out of newspapers, full of jangly bits which make little sense, and concepts which worked fine altered for no perceivable reason.
The fact, e.g., that it's a completely different operation than checking out a single file or folder? (One changes HEAD, one doesn't. One warns about overriding local changes, one doesn't, etc.)
My experience is the opposite. Most of the staunch Mercurial supporters came from CVS or SVN and found Mercurial to fit better into their preexisting mental model of source control.
Users that started with Git are more likely to internalize Git's concepts as "the natural way to do version control", and more likely to find Mercurial counterintuitive.
Not my experience. As it happens, Mercurial and Git are very similar in terms of the "mental model" required to use them: history is just a DAG, and common operations consist of navigating the history and creating/editing/re-organizing commits.
But where mercurial shines with a clean, consistent and simple UX, git is a mess where storage-layer abstractions leak to the user and where single commands serve multiple unrelated purposes.
To give you a practical example, any command that takes commit(s) as argument (for checking-out, logging, rebasing, …) would be passed a `revset` in mercurial-land. Revsets are a simple DSL to address commits (by hash, lineage, topology, distance, …), which makes new commands easy to learn, and renders one third of `git help log` inadequate. Most commands that output something use templates as argument, which renders another half of `git help log` laughable.
There is nothing "natural" about the git UX, you've got to accept that it grew organically with no attention to details.
I really love git for the way it has taught me so many things by being so exposed. I love that you can easily use it as p2p, via email as a server or client, as a ci/cd solution. I love that you can easily inspect its model with cat. I love that while “branches” and “tags” seem special, you could just as easily use its “notes” or even just tack on your own ref system willy-nilly.
All this to say, I love git, and as a versioning system, it seems obvious to me that we can do better than git for 90% of workflows. Just yesterday I was surprised by how `git push --tags` worked and had to read the man page for `git-push` to see I wanted `git push --follow-tags`. Just reading this forum today I see that I alternately probably(?) could have figured out what I wanted with `git help push` which I didn’t even really realize was a thing.
But do I want to use an easier versioning system? I’m not sure. git has a kind of forcing function for a growth mindset. I value it for its creative expressivity.
Edit for sibling comment: Stockholm Syndrome, quite possibly. But as the “victim,” I still love git!
heh, I'm highly sympathetic of what you say :) . I also got to use git after being told how awesome it was, by people who themselves were told how awesome it was, and so on and so forth. And for many years, I was a believer, too, and probably heightened the bar of what I found acceptable as a result.
That's not to downplay git qualities, but as a social experiment in soft peer-pressure and group-thinking, I think it has value (though that's beyond my field of expertise).
I came to mercurial when, after shooting myself in the foot with git for the N-th time and going on a rant about it, someone on IRC told me to give mercurial a shot and move on with my life. I confess that TortoiseHG helped me translate my git habits into the equivalent hg commands, and the kind of history exploration that I was doing then set me up to speed with the revset way.
Then, what I found formidable was that all the knowledge about git intricacies that I had accrued and internalized with pride over the years became absolute no-brainers and irrelevant in the hg world: I remember a famous stackoverflow thread in 10 steps for merging two unrelated repos (including arcane git commands, shelling-out to sed, and non-transactional storage-level ops that would warrant a backup, as was the norm back then). How do you get history from a repo in hg? `hg pull`. How would you go about getting history from a repo (unrelated) in hg? `hg pull` as well. And thinking about it, would have git been nicely designed, it wouldn't have had to care about the difference and even less so had to expose it to the user.
Mercurial, although not perfect, really opened my eyes on what good UX design should look like.
People don't internalize Git concepts as "natural", they get Stockholm Syndrome.
I'm not saying mercurial is better, but there's a reason I have to remind people that this[1] is satire - the real manuals are so convoluted that they seem like parodies of themselves.
There are two reasons Git is better, and the UI is NOT one of them: speed and repository format. I think Keith Packard wrote about this best: Git is technically under the covers way superior over Hg, it's not even a competition. For usability, I think with Sapling we finally get some real competition and that might be the user interface alternative we need, as well as the monorepo approach it was basically made for, but let's just say that I don't trust people who think Mercurial is technically even close to a good idea.
I think the problem arises from when you switched to hg from those older systems and grew accustomed to it and then were FORCED to switch to git because of work or whatever.
I feel like the Mercurial fanbase is just another loud fanbase. I did start with CVS and SVN and git was absolutely fantastic when I started using it. On the other hand I could never get the hang of Mercurial. From MY PERSONAL perspective it has a terrible UX(which is the exact opposite experience of the loud hg fan git critics on HN). I absolutely cannot relate to the people who say that Mercurial has the better UX, but I don't remember myself constantly bashing mercurial either like the other side does. From my perspective `git add -p` is an important essential functionality that hg does not provide. I believe there was some sort of plugin but it was no where near as polished.
Yes, there are a handful of nice features in mercurial, but none which are actually necessarily needed inside of the git core.
I do faintly remember that my biggest problem with git was understanding that a commit doesn't push automatically. But then again that's just a difference between a DVCS and whatever was there before.
Having used svn, git, mercurial then back to git (with the last two at the same job, the business unit having decided to move from mercurial to a git-based solution) and I've preferred mercurial to git, where it feels like there's more possible foot-guns and its features don't bring enough value to justify the increased complexity when using it .
What are the changes that Mercurial has? I've read many times that Mercurial is easier but I've never seen the reasons. The times I've used mercurial (mostly to download a repo) it doesn't look that different, and other than the staging area weirdness I don't find git too difficult.
You know how when using git you have to add tons of flags to every command to make it do what a sane person would actually want? Mercurial just does what you want.
I'm going to be blunt and state that what most people want is not what they actually need. If you use Git for how it was designed, the commands remain generally pretty clean. If you come from an SVN mindset, you are probably not really using Git the way it was designed, and Mercurial fits better.
I have used (actually introduced) Mercurial before at a company and considered them basically equivalent enough, only to get stuck in some horrible design choices of early Mercurial (named branches and not having rebase by default). I am happy to see these elements corrected in Sapling, giving me enough confidence that I might actually use Sapling over time...
The way Mercurial is structured is, to me, intuitive, easy, and powerful. I'm still using it for all of my local projects; luckily hg-git lets you pull in dependencies from github, which would otherwise require me to switch to git.
As someone who used to be intimately involved in the development of PHP, HHVM was an interesting project because for a long time it supported standard PHP (alongside Facebook's custom language, Hack), so it brought competition to the implementation space! But eventually Facebook lost interest in that part, probably because they had no use for it.
If Sapling encourages a Git-usability renaissance the same way HHVM encouraged PHP to get good performance and typing, even if it eventually gets abandoned, I will be thankful for it :)
Mercurial has a far better user experience and mental model. The commonly used commands simply do what their names say: hd add, hg commit, hg revert, hg update, and so on.
Git is a twisty maze of operations combined under poor names (e.g. git reset) with dozens of obscure options (e.g. man git-log) and broken abstractions (e.g. what is HEAD and why does Git emit a warning whenever I check out a tag?). I often feel so sad that the entire software industry has fallen to Stockholm syndrome under Git — we think these contortions are normal, when in fact they are arcane.
I was going to say that they already had started their own successor to Mercurial called Eden, but it seems like Sapling is just a renaming of Eden. Maybe anyway. It's a bit unclear.
It's a pet peeve of mine folks that use python subprocess as a replacement for bash because it takes special discipline to not eat stdout and stderr, or to correctly try:finally: to show the Proc details before the raise eats the variable
> I really hope that git is not the final word in version control.
common problem in open source. any project that gets big enough effectively stops anyone from wanting to work on an alternative, or use an alternative, due to the momentum of the large project.
deviating from it makes it harder to collaborate or be productive because the big project does everything (though often poorly), everyone knows it already, and no one wants to learn something new, and no one wants to work with the people using the weird thing.
same reason why it's hard to make a Facebook alternative.
That's true, but that's not the whole story either. I remember not too long ago when it wasn't a big deal to jump from one VCS to another. Devs were proficient in CVS, SVN, HG, BZR, GIT as a standard, would go from mailing patches to a ML on a project to pushing to a repo on another, to zipping code and uploading it on a FTP on a third. It was the project's workflow of choice, and people would respect that.
Things really became one-sided after github started gamifying open-source contributions, and when a new generation who perhaps grew-up in a more competitive academic setting took it as an opportunity to make their resume more impressive.
We peer-pressured ourselves into collectively using a less-than-ideal tech because that was the price to pay to belong.
I'd add on that a tools ecosystem integrated with git/hub over other options has also made git adoption a more natural fit for those who are less about tools and more about a particular outcome, which also spanned git usage (or git as a background vcs) beyond just software developers.
The big baddie here, IMO, isn't even git itself but GitHub. Many younger devs don't even seem to realise that they're not the same thing, that git can be used without GitHub.
> Devs were proficient in CVS, SVN, HG, BZR, GIT as a standard
That's completely made up on your end. I've been doing FOSS for 17 years and the vast majority of people were barely competent with any of them at all beyond whatever their chosen ponyshow was (including off-brand ones like Darcs and Monotone), and any switching from a persons preferred one to the use of another project was often met with grunting and complaining, if it was done at all.
The reality is we only think this because we saw people do this, at great cost of their own time -- but that's the literal definition of survivalship bias. For every 1 person doing this 50 just stuck with whatever they used and wouldn't bother. I've literally seen people refuse to contribute to a project over tabs vs spaces, and people still do this with git vs hg today, just not as much today.
More people use Git and contribute to FOSS in a single day in 2022 than every developer who knew all these tools combined back in 2008 or whatever. Whether this is good or bad is up to you, but you don't need to make up claims about developers being epic journeymen in the past and mastering 50 version control tools to do a single days work. They did not.
> Things really became one-sided after github started gamifying open-source contributions, and when a new generation who perhaps grew-up in a more competitive academic setting took it as an opportunity to make their resume more impressive.
Sorry, but I consider this to be a similarly made up claim that's just sour grapes. I've been using GitHub since 2008, I'm one of the first users. GitHub didn't even have "gamified" social features until the past 3-4 years IME (what, stars are about it?), and before that its product was pretty poor in some key areas like code review and project management, org permissions, on-prem control, etc. I didn't even use GitHub commercially until like, 2018, because most orgs had setups that were better in some key areas. But it was pretty easy to use and get started with, which mattered, and still matters, and soon enough nobody could compete with the same ease of use for free projects.
If I had to "blame" "someone" in this vein, a better place to start: global monetary and fiscal policy for the past 20 years resulting in software development becoming one of the only places with rising wages to meet cost of living demands in places like the US -- resulting in an influx of new blood to increase their wages and quality of life, combined with political choices like low interest rates, and huge explosions in demand for software devs for things like VC adventures, etc. Subsequent developments like bootcamps designed to churn devs out to match rising demand, etc which solidified platforms like GitHub further as it was easier for them to paper over these fundamentals when there was a clear winner (git/github) to focus on and ignore everything else. Forest vs trees and all.
> That's completely made up on your end. I've been doing FOSS for 17 years and the vast majority of people were barely competent with any of them at all beyond whatever their chosen ponyshow was
I doubt either of us has actual figures, so it's "my experience" vs "yours" (and full of anecdotal bias which I'm willing to admit). At least what's factual is that a decade ago, the versoning and tooling ecosystem was much more diverse: where today github/-actions/-CI/-issues/… is a quasi-monopoly you would bump into a new hosting solution/bug-tracking, reviews and CA build systems every other week, and the major open-source projects were either using CVS, SVN, GIT or HG. So, in proportions, more people had to be able to switch from a system to another, just out of practical considerations.
And I'm not even looking back pretending that things were perfect back then, I'm only suggesting that the monoculture which ensued killed a lot of competition, innovation and convenience, from which we could benefit today, on top of increased standardization (did you know for instance that hg can pull and push to git?)
> For every 1 person doing this 50 just stuck with whatever they used and wouldn't bother. I've literally seen people refuse to contribute to a project over tabs vs spaces, and people still do this with git vs hg today, just not as much today.
There's some truth to that, but it's a pretty extreme view. All projects can benefit from a lower entry bar and should be as welcoming as feasible, but optimizing for drive-by contributions at the expense of more meaningful involvement is destructive on the long run: anyone having worked on larger projects knows that the bulk of the effort is carried by a smaller group of dedicated people over long periods of time, not hundreds of over-the-fence-throwing typo-fixes. And I'm totally siding with projects who don't want to adopt the github ways of organizing their work where it means making long-haul contributor's lives more difficult.
> More people use Git and contribute to FOSS in a single day in 2022 than every developer who knew all these tools combined back in 2008 or whatever.
[Ref. Needed]
> > Things really became one-sided after github started gamifying open-source contributions, and when a new generation who perhaps grew-up in a more competitive academic setting took it as an opportunity to make their resume more impressive.
> Sorry, but I consider this to be a similarly made up claim that's just sour grapes.
If "gamified" may not be the right term, you certainly can't be oblivious to how often people equate their github activity to their resume, and how it's used as a token of value by job hunters and recruiters alike. Putting aside the "merit" of most contributions, this really contributed to people "demanding" from projects to move to github, to bring visibility on themselves (before the interests of the project itself), hence the centralization around the single largest platform. I don't know about you, but I find this state of affairs quite discomforting.
Because motivated, high performing people need to have control over their own destiny. Because cookie-cutter solutions which work for 90% of use cases are often worse than something explicitly tuned for you.
People having specific needs, getting frustrated and then solving their problem is a feature of opensource code. Its not a bug. It is the engine of innovation and improvement. Forking means we can both get what we want, even if our needs are contradictory or we don't want to work together.
This happens with commercial offerings too - but its a mess. You can't just fork the code without paying (or sometimes at all). And every fork is private, so work is duplicated and collective learning doesn't happen. Expensive consulting-ware might be the best case outcome.
The ability of motivated people to fork projects and have their own spin on things is one of the biggest strengths of opensource. May the best forks win.
> Because motivated, high performing people need to have control over their own destiny.
This opinion seems to be peculiar to software and I think it has something to do with the fact that software is one of the few verticals where you can (attempt to) intellectualize everything.
Having control over your own destiny in any other skilled labor job seems to be 98% about finding a brand and model of tool that works the way you do, and 2% building your own tools or jigs for that specialty task nobody thought to build a tool for.
In software it's anywhere from 90:10 to 10:90 depending on how much emotional baggage your coworkers are carrying around.
Does it have to be so disrespectful, though? Demanding things, getting frustrated when denied and ghosting the original project to the point even they are surprised when a fork shows up?
There is always too sides to a story. We don't know what pressures the FB engineers were under and the problems they were trying to solve resulting in them "demanding" changes. In the end I think everyone wins with the forking.
> Because motivated, high performing people need to have control over their own destiny.
I don't quite buy this: Those same "motivated, high performing people" don't seem to have anywhere near the same "need to have control over their own destiny" when it comes to the commercial closed-source tools they use.
I’ve seen people reinvent the wheel all over the place because their tools weren’t quite working for them. This instinct is the reason most good software has APIs - so you don’t have to ditch the tool entirely to customise it to your workflow. And most medium to large companies have all sorts of wacky customisations on top of existing software.
Eg perforce at Google. Well, everything at Google. And a friend at a big broadcaster has a bunch of company specific plugins for Reaper for their audio editing pipeline. And everyone insists on customising Jira.
IME there's at most one of those wheel-reinventors for each zillion devs unthinkingly swallowing whatever (VSC) Microsoft is spurting down their throats this week.
Because that's how progress slowly happens? If I have an issue with something, and come up with a possible solution, and then ask why it's not actually done like that... Either other people tell me I'm wrong and explain why, or they agree and things get better.
> and there are still those of us who actually use Mercurial
I'm certainly in that camp; and it pains me every time I have to use the hggit extension to convert a mercurial repo to git in order to work with everyone else...
Yeah, we should give a shout-out to the octobus folks for making heptapod, a Gitlab fork bringing support for mercurial repos. That brings at least one mainstream hosting option for hg repos.
Absolutely. I guess most of us have a bunch of repos which are personal anyway which are just as easily "hosted" as Mercurial repos. I.e. if I have ssh access to a machine, "hosting" a remote Mercurial repo with
Facebook used to be involved with the Mercurial community, but it was difficult to work with them. They always wanted to do things their way, had their own intentions, and started to demand that the Mercurial project work the way that Facebook wanted. For example, they demanded that we start using Phabricator and started slowly removing sequential revisions from Mercurial in favour of always using node hashes everywhere, arguing that for their gigantic repos, sequential revisions were so big as to be useless.
Eventually the disagreements were too great, and Facebook just stopped publicly talking about Mercurial.
I figured they would emerge a few years later with their fork of it. They love doing this. HipHop VM for PHP, Apache Hive, MyRock; these are examples of Facebook forking off their development in private and then later emerging with some thing they built on top of it.
The Mercurial project is surprisingly still chugging along, and there are still those of us who actually use Mercurial. I doubt I'll switch over to Sapling, because I disagreed with the things that made Facebook fork off in the first place. But if others like Sapling and this manages to put the slightest dent into the git monoculture, I'm happy for the change and innovation. I really hope that git is not the final word in version control. I want to see more ideas be spread and that people can see that there can be a world beyond git.