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.
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.
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!
loeg|2 years ago
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.
dang|2 years ago
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)
Flux159|2 years ago
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.
sneed_chucker|2 years ago
IshKebab|2 years ago
reissbaker|2 years ago
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.
ahahahahah|2 years ago
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.
Shish2k|2 years ago
Personally I don’t care about the backend at all - I’m loving sapling just as an alternative git frontend with considerably better UX :)
anotherhue|2 years ago
1propionyl|2 years ago
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.
0x6c6f6c|2 years ago
rawrawrawrr|2 years ago
LarsDu88|2 years ago
loeg|2 years ago