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.

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.

EdenFS builds (and probably runs?) from GitHub, but we have done no work to make it usable and hook it up to an existing checkout. It may not be much effort, and we're hoping to demonstrate that workflow in the future.

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.

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 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.

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.

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.

https://sapling-scm.com/docs/internals/internal-difference-h... briefly explains the Git support. Currently we keep trees and blobs in a git bare repo unchanged, but convert the commit graph to our format so we can run our own graph algorithms. In the future we might store trees and blobs differently too.

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.

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.

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.