sapling

As somebody who has actually been using Sapling (because it provides a much saner UI and mental model than git), the git compatibility of Sapling is at best so-so. It feels more like a stopgap solution while they're evolving their own backend (which I'm pretty sure they use internally, because git just doesn't scale to FB monorepo size and doesn't support their rebase-on-push operation). LFS flat-out doesn't work with Sapling. Force pushing after an amend or rebase is still cumbersome, because you need to explicitly specify (again) the branch you are pushing to. And I'm not sure how bad the file descriptor problem still is that you have (had?) with large repos or submodules [1]; there was a new release recently, but I haven't actually stress-tested that. [1] At least some of that may be due to file descriptor leaks: https://github.com/fac

Meta uses https://github.com/facebook/sapling see: https://engineering.fb.com/2022/11/15/open-source/sapling-so... It’s an extension from Mercurial as the blog post states.

Windows is coming out with their own 'Dev Drive': https://learn.microsoft.com/en-us/windows/dev-drive/ I'm very curious how it performs compared to EdenFS: https://github.com/facebook/sapling/blob/main/eden/fs/docs/O...

Hey fellow Xeta. The number of secondary repos was/is declining by merging them into poly-monorepos. For example, opsfiles was/is moving to fbcode. With good D/VCS tools that can checkout code efficiently, review processes, and CICD testing, there's no real reason to avoid monorepos. Btw, the FB "hg" was semi-opensourced as sapling. Eden and mononoke still haven't been FOSSed. And, like many Meta dev tool FOSS projects, they don't just build and work OOTB and often have hard-coded Meta-isms like references to internal paths. https://github.com/facebook/sapling

> git-lfs, as in the binary, CLI application is the only (open) implementation in existence. There is nothing else. There’s at lease one in sapling and Mononoke. https://github.com/facebook/sapling/tree/main/eden/mononoke/...

> I haven't seen a virtual filesystem overlaid on top of a monorepo before, do you have any examples of what that looks like? https://github.com/facebook/sapling

Most (all?) of these are open source and can be used outside of Meta infra. https://github.com/facebook/sapling

Some of the recent tool started to come out to fix Git unfriendly UX. Meta's Sapling (1) is definitely one of them. But there is also `jj` (2) and `git-branchless` (3). These tools target a smaller set of workflow where there is 1 main branch inside a big repo and everything else are short-lived branch/topic that could be treated as ephemeral stack of patches, constantly being uproot / rebase on top of the main branch to derive final result. If that's the workflow you use daily, then you should give these tools a try. (1): https://github.com/facebook/sapling (2): https://github.com/martinvonz/jj/ (3): https://github.com/arxanas/git-branchless

I was reading on & on, going, yeah sounds great, but when are you going to mention that it runs on Mercurial, which just puts such massive distance between FB & the rest of the planet? They do mention that it supports virtual file systems through Sapling, which now encompasses their long known EdenFS. I'd like to know more but right off the bat Sapling says it is: > Sapling SCM is a cross-platform, highly scalable, Git-compatible source control system. Git compatible eh? Thats a lot less foreboding. (It is however a total abstraction over git with it's own distinct cli tools.) I hope there are some good up to date resources on Sapling/EdenFS. I have heard some really interesting things about code kind of auto getting shipped up to the mothership & built/linted proactively, it just at commit points, which always sounded neat, and there se