Sapling – A VCS from Meta | Hacker News Reader

Sapling – A VCS from Meta

github.com

77 pointsbensadeh23 comments

Any new reason to discuss this now? I guess the context is the Jujutsu (jj) git-replacement which has been discussed a couple of times recently.

Previously:

https://news.ycombinator.com/item?id=33612410

https://news.ycombinator.com/item?id=34033040

https://news.ycombinator.com/item?id=33726274

And a bunch of other zero-comment threads.

Thanks! Macroexpanded:

Ask HN: Is Sapling, the new SCM/DVCS, getting any traction in the wild? - https://news.ycombinator.com/item?id=34033040 - Dec 2022 (9 comments)

Sapling: A new source control system with Git-compatible client - https://news.ycombinator.com/item?id=33612410 - Nov 2022 (525 comments)

Eden - https://news.ycombinator.com/item?id=31006003 - April 2022 (227 comments)

Have been using Sapling for a year and also used Meta's internal Mercurial fork before that - the interop with Github PRs and familiarity with branchless development is one of the huge benefits of Sapling.

Being able to just "sl clone <github_url>" and then use sapling CLI commands is nice, but also Sapling's interactive smartlog in VSCode https://sapling-scm.com/docs/addons/vscode/ makes it easy to learn commands as well while giving a UI to commit, amend, and move diffs.

I think the only thing Sapling's really missing is git-lfs support which would make repos with binary assets easier to manage.

Btw Metas "internal mercurial fork" has been sapling for a while now. If you work there try typing `hg --version`.

Does it only work with GitHub specifically or any git host (e.g. self hosted Gitlab)?

Any git host, though the integrations for eg “show pull-request code-review status” are configured for github by default

When I was at Meta, using the custom VCS tooling was pretty great, especially considering the repo size. That being said, for both this and Jujutsu, I feel like without open-sourcing the secret sauce (the super-scalable backend), it's hard to understand why anyone outside of the respective orgs would adopt; it's a not-well-known layer on top of Git, which is:

a) Known by almost anyone you're likely to hire or work with, and

b) Will have all the same scalability problems with large monorepos regardless of what client you're using.

If Sapling and Jujutsu don't solve the scaling problems, and everyone already knows git (and you're still using git under the hood), what's the point?

It's nice that it's open-source but to get traction I feel like they need to open-source the backends. I'm sure plenty of mid-sized companies struggling to manage their git repos would be happy to use the Meta/Google solution to the problem, but neither of these projects includes the part where the problem gets solved.

They've actually open sourced almost everything you need. It includes the cli, the virtual filesystem, and the backend.

From github:

Sapling SCM is comprised of three main components:

The Sapling client: The client-side sl command line and web interface for users to interact with Sapling SCM.

Mononoke: A highly scalable distributed source control server. (Not yet supported publicly.)

EdenFS: A virtual filesystem for efficiently checking out large repositories. (Not yet supported publicly.)

And from the mononoke page:

Mononoke is still in development. We are making it available now because we plan to start making references to it from our other open source projects.

The version that we provide on GitHub is omitting some functions.

This is because the code is exported verbatim from an internal repository at Facebook, and not all of the scaffolding from our internal repository can be easily extracted. The key areas where we need to shore things up are:

Support for running thrift based apis.

Production metadata SQL support (e.g. something like a MySQL backend). We provide sqlite in OSS for now.

Production blobstore storage backends (e.g. something like S3). We provide SQL (on sqlite) and File System backends currently in OSS.

Linux is Mononoke's primary target plaform with OSS CI also running on MacOS. Other Unix-like OSes may be supported in the future.

I would say "not yet supported publicly" is a pretty big caveat — especially because neither Eden nor Mononoke (according to the README) actually build if you only have access to the open-source tools. Not sure if I'd call source dumps that don't successfully build "almost everything you need" ;)

I'm not holding my breath either; EdenFS was open-sourced many years ago with broken-for-OSS builds IIRC; it doesn't seem like there's much urgency in getting it buildable using tools available to non-Meta-employees.

Check GitHub actions. Mononoke OSS currently builds and EdenFS did a month or so ago. Not claiming it’s perfect, but the OSS versions are buildable

Oh interesting — the README says they don't, but it must be outdated. Pleasantly surprised to hear they build now, albeit inconsistently.

EdenFS Linux building now as well, problem was some minor python 3.8 incompatibility in a test

> it's hard to understand why anyone outside of the respective orgs would adopt

Personally I don’t care about the backend at all - I’m loving sapling just as an alternative git frontend with considerably better UX :)

It's different, but I'd hesitate to call it better. I've been using it for work for over three years now and still regularly get tripped up by weird behavior or missing functionality relative to git. And it's not portable to other employers, because almost no one uses hg/sapling.

Alas, sl is a command name already well taken. https://github.com/mtoyoda/sl

I have a pernicious habit of throwing sl on any shared server I manage.

There's also: https://github.com/rwos/gti

As you might guess, it's for git typos and renders a Volkswagen Golf GTI.

Amusingly, if your typo is gti push or gti pull it also includes a stick man pushing or pulling the vehicle.

I honestly can't tell if this is a joke.

It is a joke, and a rather old one. It used to be somewhat common for sysadmins to add it to shared systems as a little harmless prank on their users.

Some of us yet keep the torch lit...

Can't tell if joke command is joke.

fwiw I installed it as a cruel joke once, while teaching a clumsy typer about linux.

Git is to SVN as Sapling is to Git. It's really a great tool, makes version control a lot more productive imo.

Really would be nice for this monorepo oriented alternative to git to take off. There are many benefits to monorepos when something more scalable than git is used!

You can just scale git in the same way! VFSforGit or whatever.

Reply on news.ycombinator.com