durham_meta

Yea, that's on our list to fix. The homebrew packaging was the last package to be done, and we were busy tidying up other things in the lead up to launch.

Because we haven't released the server yet, the open source client currently only really supports git right now, so sl init --git is the only way to init a local repo for now. Perhaps we could make that message clearer.

I'll take a look at the help later to see what we're missing here.

You could personally clone a git repo with Sapling and no one would know the difference. When using Sapling with a git repo, clone, push, and pull all use the actual git binary under the hood, so the server just sees git speaking to it.

You cannot just start using sl in a git repo. You need to make a Sapling clone of it.

But you can make a Sapling clone of your local git repository, so you don't have to clone from the server again and you would get all your local work from your git repo. That might be the easiest way to try Sapling, so you don't have to delete your git checkout at all.

Sorry! 'one day' is the best I can do for now. We'd love to do it sooner, just gotta find the time.

We think, and many of our internal users agree, that the UX alone is a worth while upgrade. Since the majority of Git repos don't actually need the performance of a virtual filesystem, the UX is the main sell for them anyway. At the very least maybe it will inspire some UX improvements in Git.

Technically the mercurial pre and post hooks are mostly still there, but I'm not certain we want to support them long term. The existing hook design has some problems.

I'd be curious about your use case, since we don't actually use hooks internally all that much.

Unfortunately we can't really talk too much about that at this point. I can say a lot of effort has gone in on the server side to optimize commit throughput though.

One example we mention in the blog post is that when you push, it doesn't actually need to be a fast-foward push (using Git terminology) to succeed. Our server can rebase the commit on top of the destination bookmark for you (with some limitations, like not merging file contents). This allows many people to push, and not have to race to rebase. Then we have substantial optimizations around the critical section of final-rebase-then-move-branch-forward, which yields pretty good throughput.

Unfortunately you can't use Sapling with Mercurial repositories. There are too many differences at this point.

This does not use hg-git under the hood. Sapling's internal structure differs from Mercurial in substantial ways, and we've built some cleaner layering that allowed us to shim Git in under our storage layer. This also means that we read and write directly to the git repo, instead of duplicating and importing all the data like hg-git did. This has some nice benefits, like the hashes you see in the output are actually Git hashes.

We're somewhat limited by what version of clap is available in our internal monorepo. We try to keep things reasonably up-to-date though, so I'm sure we'll upgrade at some point.

I believe we actually only use clap for some side binaries, not for the main sl executable. We have a custom parser for that (https://github.com/facebook/sapling/tree/main/eden/scm/lib/c...), to match the preexisting hg parse behavior. Unfortunately I'm not familiar enough with clap or why we didn't go with clap in the first place to say what we would need to use clap for the main binary.

You should be able to `sl clone ...` your git repo into a Sapling clone and use it that way, even if the repository is not on Github. I haven't personally tried whether cloning like `sl clone /path/to/some/repo` works, but it should since we're actually using the actual git binary under the hood for clone, pull, and push.

Unfortunately you can't run git commands directly right now, since there is no .git directory at the root of the repo. Under the hood there is a .git directory hidden away somewhere under the .sl directory, but we consider that an implementation detail and are likely to change how we store the actual git data in the future. So we don't support people running git commands in there.

The code is available to see, but they don't necessarily build in an external environment yet and even if they did we aren't ready to support them being used externally. Hopefully we can support them one day, but for now we're just starting with the client.

Sapling originated from the Mercurial open source project, which was largely Python (at the time). To make things faster and more maintainable, we started rewriting portions of it in Rust, and going through a binding layer to interact with Python. Critical pieces like the storage layer, parts of the wire protocol, and various others are all in Rust at this point, while a lot of the high level business logic remains in Python. We'll continue to shift more to Rust over time though, especially since pure-Rust Sapling commands feel way more snappy and pleasant to use.

Good memory! Internally Eden eventually became synonymous with our virtual filesystem, so we decided it was better to choose a new name to avoid that confusion.

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