Sapling: A new source control system with Git-compatible client

Ah, there it is. I was wondering when this would happen.<p>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.<p>Eventually the disagreements were too great, and Facebook just stopped publicly talking about Mercurial.<p>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.<p>The Mercurial project is surprisingly still chugging along, and there are still those of us who actually use Mercurial. I doubt I&#x27;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&#x27;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.

Thank god.<p>I have been waiting ten years (<a href="https:&#x2F;&#x2F;www.google.com&#x2F;url?q=https:&#x2F;&#x2F;stevebennett.me&#x2F;2012&#x2F;02&#x2F;24&#x2F;10-things-i-hate-about-git" rel="nofollow">https:&#x2F;&#x2F;www.google.com&#x2F;url?q=https:&#x2F;&#x2F;stevebennett.me&#x2F;2012&#x2F;02...</a>) for someone to develop a better CLI for git, someone with the scale and clout to do it well and gain mindshare. It&#x27;s not that useful to learn a new workflow if no one you ever work with will be familiar with it.<p>This looks incredible. A simple command to uncommit or unamend makes you further realise what a disaster the Git CLI is.

Not a big fan of FB as a company, but I think their open source work is pretty impressive. Various other large companies have the problem of giant monorepos that they constantly need to onboard new developers to, but I can&#x27;t think of anyone other than FB who consistently released their solutions.<p>Sure, most people are probably fine with Git once they learned it and if they only work with small to mid sized code bases (like me). But I&#x27;m still happy Sapling is out there, I might use it or learn from it if I ever run into the problems it solves.

In the argument of monorepo vs not, the usual argument goes like this:<p>- It&#x27;s too hard to scale for a large monorepo!<p>- Google does it just fine!<p>- But I don&#x27;t have access to Google&#x27;s tools!<p>So kudos to Meta for both solving the problem and making it available to others. It will be interesting to see how useable it is outside of Meta. I know for example that while Netflix open sourced a lot of tools, most of them weren&#x27;t useable unless you ran all of them together. So far Meta has been good at avoiding that, so hopefully that remains the case.

I use the staging area to allow me to more easily break larger changes into smaller commits. I am usually all over the place while writing&#x2F;refactoring code and making commits as I go along doesn&#x27;t work well.<p>How does sapling let me take a long list of commits and break them into larger but more manageable chunks?<p>git add -p allows me to add chunks easily and create commits, git commit --fixup allows me to mark a commit as fixing a previous commit, and with git rebase -i --autosquash I get to easily take those fixup commits and meld them into the previous commits.<p>Also reviewing a stack of patches is annoying in many cases as I care more about the end result vs each individual commit. But that may just be my experience talking in open source where I am working on smaller but better well defined projects vs a large mono-repo where there may be a lot of changes across many disparate parts of the code base that make it difficult to look at the &quot;whole&quot; vs a patch that is more localized.

To use a similar featureset but in the same Git repository you normally use, you can try my <a href="https:&#x2F;&#x2F;github.com&#x2F;arxanas&#x2F;git-branchless" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;arxanas&#x2F;git-branchless</a>. Then, you can use your usual staging workflows if desired, or use regular Git commands directly.<p>Its design is inspired by Sapling, and, in fact, it uses some of the same code, such as the segmented changelog implementation. Possibly some of its ideas made their way back to Meta, such as interactive undo?<p>Jujutsu also supports colocated Git repositories: <a href="https:&#x2F;&#x2F;github.com&#x2F;martinvonz&#x2F;jj" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;martinvonz&#x2F;jj</a>. It also has the working-copy-as-a-commit idea and conflicts are stored in commits (so rebases always succeed). I think it&#x27;s a step forward compared to git&#x2F;hg&#x2F;sl.

Nobody commented on the web interface yet which I think it&#x27;s one of our coolest features: <a href="https:&#x2F;&#x2F;sapling-scm.com&#x2F;docs&#x2F;addons&#x2F;isl" rel="nofollow">https:&#x2F;&#x2F;sapling-scm.com&#x2F;docs&#x2F;addons&#x2F;isl</a>

I’ve been using FB’s mercurial fork for years, wishing for all that time that I could have the joy of the fb-hg CLI while remaining compatible with github because that’s where 99+% of the code lives - from my brief experimentation, sapling appears to be that. I look forward to never using the git CLI again :D

Its interesting how these threads about Git simultaneously have<p>(a) People arguing git is fine, and shouldn&#x27;t be simplified<p>(b) People arguing about the right way to use git, and flame wars about best git workflows<p>I mean most people simply see (b) and conclude &quot;this is a huge hassle, I don&#x27;t want to annoy some git-workflow-purist, I&#x27;m just going to walk on eggshells on this tool and hope I don&#x27;t break anything&quot;<p>It&#x27;s as much a social problem around conventions, and lack of opinions in the tool itself, then anything about the underlying technology (which is rock solid IMO)

Hi Hacker News! Author of the Sapling blog post here. I&#x27;m happy to answer any questions you might have.

As a Meta employee for almost 4 years what I will say is I was skeptical at first coming from git, but the sapling system works very well in practice in my experience. I still use git for everything outside of work, but I may consider sapling now.

It’s hard to overstate how much better this workflow is UX-wise than the git(hub) default. I’m super excited to see it open sourced.

What is the argument against having a staging area? The Git staging area is crucial in my mind.

<a href="https:&#x2F;&#x2F;sapling-scm.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;sapling-scm.com&#x2F;</a><p><a href="https:&#x2F;&#x2F;github.com&#x2F;facebook&#x2F;sapling" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;facebook&#x2F;sapling</a>

Stack of commits seems to be similar to what one would call a patch queue if one is using Git.<p>The fact that they have concepts like unamend suggests that they have thought about this in a way more turtles all the way down way than the Git designers. A versioning for your history changes—why, of course.

Originally started as an extension to Mercurial, but grew into its own SCM with a cross-platform virtual filesystem in C++ and a distributed server in Rust.

The interactive tool looks amazing. I do interactive rebases quite often and a drag-drop setup is wonderful<p>However, I don&#x27;t understand why I would want 1 PR per commit. I feel like that&#x27;s a non-starter for me.<p>Is the idea that no one should use branches - so there&#x27;s only 3 points of interest: HEAD, main, and origin&#x2F;main? And then is the idea that it&#x27;s only 1 commit per feature to merge?<p>So I would work on something, make a PR, continue working on something else without making any git checkouts and then make a new PR?

&gt; There is no staging area.<p>That&#x27;s actually a deal breaker to me. Effectively using Git&#x27;s staging area has become so integral to the way I work with repositories that I don&#x27;t think I can ever go back to the old style.

The biggest disappointment here is surely a missed opportunity to shoehorn a git and sap joke into this release.<p>The utility should obviously be called `sap&#x27; and not `sl&#x27;.

the number of projects that require the scaling factor of something like this is very small. git with lfs scales very well for most repositories. That said the actual flow of git is pretty raw. There are other pretty solid projects out there that support undo commands into git.<p>Stacked PRs are a blessing and a curse - still not convinced they are the correct way to build software as a team.

Command name conflicts with the `sl` utility that has existed for decades.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;mtoyoda&#x2F;sl" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;mtoyoda&#x2F;sl</a>

Would the team consider discussing the architecture of this system? Seems like a whole lot of Rust was used. I&#x27;m sure the team has a lot to share.

This serves a very weird niche. Reading through the docs, this seems just as complex to operate as git, but designed with less decentralized operations in mind. Why not just use mercurial if you want to use mercurial? Why invent this... monstrosity? Because GitHub pull requests are terrible?<p>None of this makes any sense to me.<p>&gt; Local branch names are optional.<p>As are they in git, just hang out with a detached HEAD.<p>&gt; There is no staging area.<p>Practically the entire world sadly invokes `git commit -a` anyways and you still have to add untracked files.<p>Neat project but I don&#x27;t get what this is solving for.

Not sure if anyone has tried this yet... but the example tutorial does not work.<p><pre><code> $ sl clone https:&#x2F;&#x2F;github.com&#x2F;facebook&#x2F;sapling $ cd sapling $ sl @ fafe18a24 23 minutes ago ricglz remote&#x2F;main │ migrate packer to new CLI framework ~ </code></pre> From [0] under &quot;Cloning your first repo&quot;. I get the following:<p><pre><code> ~&#x2F;sapling (main)&gt; sl status abort: &#x27;&#x2F;full&#x2F;path&#x2F;sapling&#x27; is not inside a repository, but this command requires a repository! (use &#x27;cd&#x27; to go to a directory inside a repository and try again) </code></pre> Hopefully this does not assume we are authenticating with GH just to clone and see sl operating?<p>[0] <a href="https:&#x2F;&#x2F;sapling-scm.com&#x2F;docs&#x2F;introduction&#x2F;getting-started&#x2F;" rel="nofollow">https:&#x2F;&#x2F;sapling-scm.com&#x2F;docs&#x2F;introduction&#x2F;getting-started&#x2F;</a>

Neat! I hope this is a step in the right direction towards and not-so-bespoke SCM.<p>I do wonder:<p>1) How it handles large (binary) files. This is a major pain point when using git and even the standard solution (git-lfs) leaves *a lot* to be desired.<p>2) How does server hosting currently work? I didn’t see any mention and am assuming it’s not an option currently? (two dependencies of Sapling are currently closed source)

Could this be a replacement for git-annex? I&#x27;m using git-annex for a while, but its slow and has some quirks. I would love to use version control on my whole home dir and sync different computers with it.<p><a href="https:&#x2F;&#x2F;git-annex.branchable.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;git-annex.branchable.com&#x2F;</a>

OpenBSD&#x27;s Game of Trees is also an alternative that&#x27;s git compatible, in case that hasn&#x27;t been mentioned.

It&#x27;s interesting to see more people embracing the patch-stack workflow! For those interested in using the patch-stack workflow, but not ready to change to sapling, git patch stack would be worth checking out.<p><a href="https:&#x2F;&#x2F;git-ps.sh&#x2F;" rel="nofollow">https:&#x2F;&#x2F;git-ps.sh&#x2F;</a>

Interesting execution. I&#x27;m not totally sold that Sapling is somehow forcing smaller&#x2F;(more understandable) commits. Running Sapling restack with the manual step of an `amend` doesn&#x27;t sound too different than running `git rebase -i` and moving the commits around. ReviewStack is interesting, but nothing new. It seems like it&#x27;s removing the need to click through the commits page in GH by exposing it in a dropdown. IMO, the real improvement to our workflows will come from using better diff tools to make reviews more intuitive. I am biased of course :) (full disclosure: I work on DiffLens <a href="https:&#x2F;&#x2F;marketplace.visualstudio.com&#x2F;items?itemName=DiffLens.difflens" rel="nofollow">https:&#x2F;&#x2F;marketplace.visualstudio.com&#x2F;items?itemName=DiffLens...</a> )

I am a bit lost. Most of the discussions seem to focus on micromanagement of commits in your local HEAD branch.<p>I agree that the Git commands are pretty primitive (aka low-level). But eventually you can learn the good patterns and deal with that.<p>For me, the big question is how to manage a monorepo (with zillion of branches) so you can express which set of branches are relevant to your current concern at time T:<p>- focusing on the dev of a given set of features,<p>- frozing them into a delivery,<p>- pushing a stable monorepo+that frozen delivery to your validation platform,<p>- once validated, integrating that frozen delivery to one of the master branches of the monorepo,<p>- management of the many master branches corresponding to each subparts of the monorepo into a supermaster branch<p>Does this tool (or Mercurial in general) help with all that mono-repository branch management ?

Does it support commit signing? I spent a while reading the website and couldn&#x27;t find anything suggesting it does. Lack of that is a showstopper for me (and frankly, should be a showstopper for anyone).

Their CLI is going to interfere with the other `sl` command: <a href="https:&#x2F;&#x2F;github.com&#x2F;mtoyoda&#x2F;sl" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;mtoyoda&#x2F;sl</a>

Package conflict on &#x2F;usr&#x2F;bin&#x2F;sl between sapling and sl.

I wonder what the folks at graphite.dev think about this announcement.

This won’t go anywhere even if its 20% better than git. To replace git’s network effects, you need to be 10x better.<p>How I think that will happen is using CRDTs against an AST to remove most merge conflicts.

Cloned my repo with &#x27;sl clone <i>url</i>&#x27;, cd&#x27;ed to it, then &#x27;sl status&#x27; and it doesn&#x27;t recognize it as a repository. So much for git killer

The UI sounds much better than git. (but what can be worse than git in the first place?!) It&#x27;s solving (or trying to solve) many common griefs of git. I don&#x27;t like Meta, but I find myself enjoying the design itself.<p>I especially like the idea of stack. It&#x27;s not something git can&#x27;t do, but someone should&#x27;ve spent quite some time on tons of trial-and-error to nail the workflow. It&#x27;s certainly a well aged project - a decade old! Kudos to that.

Nooooooooooo.<p>Whatever is to come of my cute animations!<p>[Think of the trains!](<a href="https:&#x2F;&#x2F;github.com&#x2F;mtoyoda&#x2F;sl" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;mtoyoda&#x2F;sl</a>)

I&#x27;m not interested in a simplification of git, sorry.<p>Git&#x27;s major value proposition is that they <i>added moving parts until the system worked great</i>. If you don&#x27;t want named branches, staging, or any other piece of the ideology, then subversion is a fine choice.<p>But most folks moved on from svn for reasons

What exactly does “git compatible” mean? I may have missed it, but didn&#x27;t see it skimming the post.

Interesting choice of name for the command. Clashes with the treasured &#x27;steam locomotive&#x27;!

I find it interesting that this is open sourced a few days after 11K were laid off.<p>Was bulk of the team behind this laid off wherein it made sense to open source it to involve the community to take it forward rather than paid resources?<p>To be clear: I&#x27;m NOT criticizing them open sourcing this.

&gt; When used with our Sapling-compatible server and virtual file system (we hope to open-source these in the future)<p>Sorry, I just can&#x27;t take an &quot;open-source&quot; project seriously that uses &quot;we hope to open-source these in the future&quot; in its pitch.

Pijul: <a href="https:&#x2F;&#x2F;pijul.org&#x2F;model&#x2F;#implicit-branching" rel="nofollow">https:&#x2F;&#x2F;pijul.org&#x2F;model&#x2F;#implicit-branching</a>

Trying to use it on existing git repo doesn&#x27;t work... At least not out of the box, I wonder why is that? Makes it less fun to work with as you can&#x27;t easily switch

I&#x27;m a little confused, is it a client compatible with Git? So I can use this for a git repo?<p>Or is it a new DVCS, with its own repo type, for which I can use the git client for?

Does anyone know if this could work with pre-commits? I did some initial searching but haven&#x27;t found anything conclusive.

Nice. I&#x27;ve been pondering something like this for a while but lack the time (and frankly, expertise) to attempt it.

I&#x27;m confused. Can you use Git with this new client, or do I need the Sapling source control too?

&gt; There is no staging area.<p>I don&#x27;t actually want &quot;No&quot; staging area.<p>What I want is, once I &quot;add&quot; something, the file stays added.<p>Currently, I have `git st` alias setup :<p><pre><code> st = !git add -u &amp;&amp; git status </code></pre> This auto-updates the staging area for files that were previously staged.<p>So I get `git add` but also don&#x27;t have to re-add anything manually from there ...<p>Since I do `git st` quite frequently, this works out for me ...

I will for sure try this. Looks great!<p>I think the design of GIT still is a big risk for commercial companies.

How do you build this? The code structure looks different than a normal Rust project.

I guess github is kind of bound to git for hosting :-)

Looks like the typical FB thing to do. Latch on to some popular tech like git and try to sell it as innovative or &quot;better&quot; gathering the fanboys. After a few years the marketing hype will blow over and we will either have lots of misinformed newbies, who got into dev work on FB products. Just like we have today lots of web devs able to throw together any react widget you want, but unable to gradp when simple server side templating in any web framework would have been sufficient. Hammer. Nail.<p>I for one will remain skeptical. If they release it as free software, we can talk. Probably real innovation will happen elsewhere though, without the FB flavour to chew on.

Seems like it just the client component for now

&gt; Building the Sapling CLI requires Python 3.8, Rust, cmake, and OpenSSL for the main cli<p>Rust and C? that sounds like it is a pain to build, especially on Windows.

&gt; At Meta<p>Ah, dammit

Add Comment

Phabricator[0]: code review&#x2F;CI solution from Facebook. My company uses it, open development has since been halted by Facebook and we&#x27;re effectively on abandonware.<p>Flow[1]: JavaScript typing system from Facebook. My company uses it, open development has since been halted by Facebook so we&#x27;re effectively on abandonware.<p>EDIT: React: Javascript framework from Facebook, my company uses it, and while it has its warts it works pretty well all things considered and Facebook has continued to support and evolve it over time!<p>For all I know Sapling is fantastic and will be developed for years to come. But personally I can&#x27;t help but feel &quot;once burnt, twice shy&quot; (or in this case, twice burnt once shy). I&#x27;d be happy to be wrong here because ergonomics of Git are really frustrating in many places.<p>0: <a href="https:&#x2F;&#x2F;www.phacility.com&#x2F;phabricator&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.phacility.com&#x2F;phabricator&#x2F;</a> 1: <a href="https:&#x2F;&#x2F;flow.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;flow.org&#x2F;</a>

I&#x27;m kinda surprised by the excitement it gets. I&#x27;m still looking for a compelling explanation, why I (or anyone else) should even bother?<p>I am a git hater myself. I mean, git just sucks. It always did, and it always was much worse than Mercurial. When they could have be seen as competition, I was forcing Mercurial as much, as I could, but then GitHub became a thing, and after a very short struggle it became just hopeless. There still are folks who use fossil or something, but ultimately git became THE SCM. So, yeah, I hate you, GitHub, I hate you, Linus, but I fully admit that you&#x27;ve won. So… now I can actually admit it isn&#x27;t such a big deal.<p>Sure, it would be somewhat better if git never existed at all and we&#x27;d all just use a better SCM from the very beginning. But given it&#x27;s just not the case, what it the problem, really? It isn&#x27;t hard to learn git. I do know some people who are struggling with anything outside of simple pull-branch-add-commit-push workflow (usually performed via buttons in their IDE), but, honestly, I think they will be struggling with any other SCM just as much — it&#x27;s just the difference between caring to build a mental model of the tool you use, and simply memorizing a number of popular commands. The tool isn&#x27;t at fault here. So, really, git is kinda bad, but not <i>that</i> bad.<p>Monorepos? I mean, there were tools to work with them before, but does anyone outside of Google&#x2F;FB actually work with repos that git cannot handle? Is it really a good idea to have such repos? I mean, it&#x27;s nice that some tool <i>can</i> work with them, but is it actually important?<p>I mean, there is some new &quot;better&quot; SCM (often somewhat git-compatible) almost every year. But I&#x27;ve never actually seen anything that would make me push for that &quot;better&quot; SCM anywhere. Even for my personal projects. Git isn&#x27;t &quot;just git&quot; anymore, there are countless tools that integrate with it, we all know it by heart and have sets of &quot;best practices&quot;, how-to&#x27;s, personal workflows, helper-scripts, etc. There is a huge downside to start using anything besides git, so what is the upside that would compensate for it? I never see one.

FYI, as-shared at Meta:<p>&gt; First things first, please go to your phone and turn off wifi to avoid voter ring detection and upvote us on Hacker News!

This is simply unusable. If I type `sl`, I expect an animated choo-choo train to appear, not a newfangled Git client!<p>&#x2F;s :)

I just cannot understand how a CTO approves this type of project. Imagine running a company and some engineer comes in and and says they want to develop a new source control system. I don&#x27;t understand under what circumstances this is approved. Is it a pet project for a 10x engineer and it&#x27;s allowed just to keep them on board?<p>There are projects, like Apache Hadoop, that are open-sourced because they&#x27;re an open-source answer to an extremely powerful, successful, commercial product. Sapling is nothing like this. The reason it&#x27;s being open-sourced is because Meta considers it tech debt and I&#x27;m not surprised.

How I wish there was a company that did something similar to monstrosity Android development abd build tools are. Nonetheless it’s an excellent news. While I won’t call it a monstrosity Git was so untenable and obtuse that I only used it because everybody else used it.

Idk

Yet another tool from Facebook that maybe serves their internal needs well, but is totally useless to anyone else.

Did anybody ask for a new git? And if they did, of all the entities in the world, why would Facebook be the guys we trust with that? It&#x27;s already hard trusting Github.com.

Major pain point of monorepos: Merge-conflicts. When a merge-conflict happens YOU need to be expert and resolve all conflicts the right way, across the many unrelated domains mixed together.<p>How does sapling solve that? It can&#x27;t...<p>IMHO Sapling looks like &quot;Git for dummies&quot;. And Git teaches some pretty useful concepts, which are worth it.