Meta's Sapling source-code management system

The blog post says "You can now try its various features using Sapling’s built-in Git support to clone any of your existing repositories." and "Many of our scale features require using a Sapling-specific server and are therefore unavailable in our initial client release."

Note that in addition to the Sapling CLI, they're also releasing ReviewStack, an alternative user interface for reviewing GitHub pull requests. The code appears to be in the Sapling repo, and there's also a public instance of it at https://reviewstack.dev .

Yeah, the up-streamed stuff from gvfs/scalar is also pretty vastly improved over what was in the old fork. sparse index/worktree/clones are way better than gvfs because you don't need to worry about some random program enumerating the git repo (including getting file sizes) and causing gvfs to download everything. I had both TortoiseGit and WinDirStat do this, it's quite annoying.

Something not in git uptream that I would love to see is a way to automatically symlink/junction git submodules (the ones in .git/modules) to some central area, scalar (the from git-for-windows) does seem to _somehow_ do this, I think using the alternates mechanism and a shim clone/fetch command but it's not super clean. I would be happy just getting modules pointing to exactly the same initial remote pointing somewhere common, it would at least make it harder to end up with 10 different copies of LLVM's repo on my machine.

Oh, another pretty easy win (on linux, at least, but perhaps on windows and mac with a compatibility shim) would be teaching git-checkout-index to use copy_file_range when available. The first "chunk" of the (unpacked) git object doesn't match the first "chunk" of the checked-out file so it's kinda filesystem specific if this works. And ofc on windows even if you have a compat shim almost nobody can use it because ReFS/btrfs/zfs are not widely used (I think those are all the CoW filesystems with windows implementations).

Compare above with an google-repo XML file in a git repo, describing multiple sub-git-repos.

Its essentially the same thing. Monorepo is just way worse.

I'd be a bit sceptical of using Facebook stuff outside of FB. There are internal brownie points for releasing stuff as open-source perhaps, but there are few to none for taking the time to maintain open-source stuff. Also, the internal culture is to build everything from a mono-repo, and have no concern for backward compatibilities (other than the non-atomic roll outs of binaries/artifacts from a build from said mono-repo). So I'd hate to depend on FB code outside of FB. In particular, the FB C++ library (folly) maintainers explicitly are hostile to attempts to make life easier for maintaining code out of FBCode that depends on their stuff.

I downloaded the repo. It is a copy of the mercurial repo from 2005 onward until it forks.

The staging area is useful precisely *because it is not a commit*. You can add chunks, remove chunks, edit chunks in preparation for commit and only at the last moment do you actually make the commit. When making significant changes, it's not always immediately apparent which parts go where and having a separate staging area helps managing this.

I'm not sure I could go back to a VCS without a staging area. Secret commits seem like a straitjacket in comparison.

That has a MAJOR benefit. If your understanding of the abstraction is different from mine, there is no "source of truth" to put us right. With git, you just point to the on-disk structure and say "There!".

There is another MAJOR benefit. While I can't speak to the stats, higher Mathematics requires the ability of abstract thought. Somewhere I came across the "fact", that people acquire this ability about age 14, and maybe *less than half* the population EVER acquire it. In other words, you have to be above average to understand how Mercurial works? Even worse, there's no source of truth to tell you whether you're right?

(If you remember that long screed about Pick and Relational, we have exactly the same thing - Pick may be abstract but it is heavily defined in how it maps to disk structures. Relational is defined in mathematical tuples and how it works is "ignore that man behind the curtain. Things are so much easier to understand when they map to real-world concepts you can build on.)

Cheers,
Wol