LWN: Comments on "Meta's Sapling source-code management system"

Sapling source-code management system - no staging area?

jthill — Mon, 11 Nov 2024 18:58:58 +0000

Okay, this might be such an extreme necro it qualifies as actually weird but trying to find words for a reply to this has been niggling at my hindbrain all this time. That acknowledged,

Git is: a dag of snapshots plus annotated tags in the object db; local refs; and an index for tracking work on (often constructing new) snapshots. That's it. Everything else, everything else, is in whatever's-useful-in-your-work territory.

There's software design that starts with some perceived ideal/need and jumps straight to abstractions which are then explained and implemented, this is the root of the "implementation details don't matter" view of software, the "abstract principle first" sort of design that views any behavior not covered by the abstraction as aberrant, egregious.

Then there's software design that starts with basically a data structure and asks "what use can be made of it", it might start out as a design for a perceived need but abstractions are just ways of talking about the effects you can get.

What I'm saying is: Git's the second kind. Anything you can do with a dag of snapshots and re-hanging local labels, you can do with Git. The people who want definitive and elegant abstractions tend to express distaste for this, they'll call Git's UI a leaky abstraction and get more pejorative from there. And I think that's where they're entirely missing the point. Git's a tool, a data structure plus commands to work with it. The Git interface uses abstractions to talk about the useful things you can do, not to define what's proper.

Sapling source-code management system - no staging area?

mathstuf — Tue, 06 Dec 2022 15:54:00 +0000

I'd be interested in more formal mechanisms to replace what I'm using the index for in one project[1] where the index is used to skip actually checking out files to disk that don't need to be there for index operations while still leaving a place for conflict files and other file-based operations to occur. But without such a mechanism, the index is *very* useful to me.

[1]https://gitlab.kitware.com/utils/rust-git-workarea

Meta's Sapling source-code management system

mathstuf — Tue, 29 Nov 2022 13:59:58 +0000

Hmm. We use topic branches for *all* development (there are a few exceptions; mainly automatic development version number bumps, but nothing manual). Branches for releases are `-s ours` merged into more recent branches (this preserves an "all history is reachable from HEAD" property and means we can trivially resurrect any old branch for maintenance as needed). But we also have strict vendoring rules and mangle everything to avoid conflicts with anything that could be loaded in the same process (such is life when you make SDK-like things, not end-user products).

Meta's Sapling source-code management system

scientes — Tue, 29 Nov 2022 12:25:08 +0000

> I'd be a bit sceptical of using Facebook stuff outside of FB.

Except ZSTD.

Meta's Sapling source-code management system

brooksmoses — Tue, 29 Nov 2022 03:37:48 +0000

Yup; in my experience the "branches are for bugfixes" comes up when you need to fast-track a very specific bugfix, and so you cherrypick it onto the release branch of the existing release and then make a new release from that branch.

No commit signing

zdzichu — Tue, 22 Nov 2022 13:23:57 +0000

My exploration of Sapling was cut short, at the first commit. There's no GPG signing implemented yet :(
There's an open issue #218 asking for that.

Sapling source-code management system - no staging area?

Wol — Mon, 21 Nov 2022 08:34:35 +0000

> Basically, SQL is a language with many dialects. No large application can ignore the characteristics of the specific implementation they're using.

This. Because Pick *expects* you to know the characteristics of the database, the reality is that they're all very similar. We did a major port between two different implementations once, and the bulk of the work was jsut *tweaking* the DataBASIC so it compiled on the new system. (That plus QA, of course.)

Now I'm working on yet another different implementation, I'm not noticing any real differences. The biggest, off the top of my head, is the lack of the SEQUENTIAL file type (a table optimised for sequential numeric keys). I guess the standard dynamic hash has improved ...

Cheers,
Wol

Sapling source-code management system - no staging area?

roc — Mon, 21 Nov 2022 06:30:31 +0000

This.

There is simply no reason for the staging area to exist. If it was more fungible than a commit, that would be an indication to make commits more fungible, not to introduce an entirely new concept.

Sapling source-code management system - no staging area?

kleptog — Sun, 20 Nov 2022 15:49:15 +0000

That's something lecturers like to tell you at university and what academics like to write about in papers. Out in the real world you need to know which database you're using because SQL doesn't standardise many important things. Like whether an empty string is NULL or not. Indexes are completely implementation specific. You need to know if the implementation you're using is smart enough to reorder left/inner/outer/semi/anti-joins or whether you have to figure it out yourself.

Basically, SQL is a language with many dialects. No large application can ignore the characteristics of the specific implementation they're using.

Sapling source-code management system - no staging area?

Wol — Sun, 20 Nov 2022 08:40:18 +0000

The point behind Relational, though, is that you're not supposed to know about the program - detailed behaviour especially ... and what happens if there are multiple implementations ...

Cheers,
Wol

Sapling source-code management system - no staging area?

NYKevin — Sun, 20 Nov 2022 01:15:10 +0000

> * git add -p is equivalent to hg commit -i

Rather, hg commit --secret -i, assuming you still want to work on it some more.

Sapling source-code management system - no staging area?

NYKevin — Sun, 20 Nov 2022 01:14:00 +0000

Just for clarity, here's the full equivalence:

When there staging area is empty:

* git commit does nothing, so it has no equivalent.
* git commit -a is equivalent to hg commit
* git add [file] is equivalent to hg commit --secret [file]
* git add -p is equivalent to hg commit -i
* git reset --mixed does nothing, so it has no equivalent.
* If a file is newly created or deleted, you have to run hg add/remove on it. hg forget will stop tracking a file without deleting it. This also applies to the nonempty case.

When the staging area is nonempty:

* git commit is equivalent to hg phase -d . (last argument is a dot and is the hg equivalent of HEAD)
* git commit -a is equivalent to hg phase -d . && hg amend (commands can be run in either order)
* git add [file] is equivalent to hg amend [file]
* git add -p is equivalent to hg amend -i
* git reset --mixed is equivalent to hg uncommit --no-keep
* Since the staging area has a description like any other commit, you might want to change it. hg amend -e will change the description, but also does a regular amend; you can pass additional arguments to tell it not to include any files in the amend, or make an alias for that if you need to do it frequently.

Bonus feature: You can stack multiple staging areas on top of each other, by using commit instead of amend. Git can't do that without using something like stash, which requires you to fiddle with an entirely different set of commands.

Sapling source-code management system - no staging area?

NYKevin — Sun, 20 Nov 2022 00:58:30 +0000

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

The program's behavior is the source of truth. The abstraction is what it is, no more and no less.

Sapling source-code management system - no staging area?

NYKevin — Sun, 20 Nov 2022 00:56:04 +0000

The MQ extension is informally deprecated, and probably would be formally deprecated if it didn't have a tiny sliver of use cases which changeset obsolescence does not cover (and which Git does not cover either, to my understanding).

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

You can do all of those things with a secret commit, too. hg commit -i will happily prompt you for the precise chunks you want, let you edit them, etc, in exactly the same way as git add -p. The only difference is the terminology.

Meta's Sapling source-code management system

ahornby — Sat, 19 Nov 2022 18:57:45 +0000

For a sneak peak at what the server and VFS are likely to be based on: https://github.com/facebook/sapling/tree/main/eden/mononoke and https://github.com/facebook/sapling/tree/main/eden/fs

Sapling source-code management system - no staging area?

Wol — Sat, 19 Nov 2022 15:21:30 +0000

> In general, Git's attitude seems to be that high-level concepts like commits and rebases should be understood directly in terms of their low-level on-disk representations as trees, refs, etc. Git's on-disk representation uses a staging area, so therefore you have a staging area as part of the UI.

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

Sapling source-code management system - no staging area?

kleptog — Sat, 19 Nov 2022 15:01:55 +0000

Whether git requires a staging area internally is irrelevant, I consider it one of Git's greatest innovations and contributions to the world of VCSs. The staging area is simply a "subset of the changes between the current commit and the working tree". Often when working on a piece of code I find and fix other unrelated issues I run across. And then afterwards use "git add -p" to select which chunks I want in which commit. Trying to do this with Mercurial with the MQ extension was an exercise in frustration.

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.

Meta's Sapling source-code management system

sionescu — Sat, 19 Nov 2022 04:00:16 +0000

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

That would be throwing the baby out with the bathwater. Having a single total view of the repo has so many benefits that if some devtool can't cope with the size, then it's time to blacklist or fix it.

Meta's Sapling source-code management system

paulj — Fri, 18 Nov 2022 14:15:23 +0000

Yeah, sorry, you're right. The fb mercurial repo got merged in, to a subdir at some point - in gitk that happens in the middle of the history, and I had looked at top and bottom. :)

The mercurial code is there at: https://github.com/facebook/sapling/tree/main/eden/scm/ed... - maybe in other places.

Meta's Sapling source-code management system

IanKelling — Fri, 18 Nov 2022 13:52:11 +0000

Yes, that repo you link to if you do git log --stat, and go to the end of the output, there are thousands of commits to mercurial starting in 2005. What history are you looking at? It isn't definitive, it will take a detailed analysis, but facebook should be the one clearly explaining whether mercurial copyrights are still a part of this codebase, that is another wrong they have done here. Also, you said "rewritten" as if that makes it no longer a fork but that in no way excludes it from being a fork of the same program https://en.wikipedia.org/wiki/Derivative_work.

Meta's Sapling source-code management system

mathstuf — Fri, 18 Nov 2022 01:09:32 +0000

Eh. We use submodules and I still don't like them. I don't think there are *better* solutions that are as easy to use when they are updated "often enough" (subtree extraction/merging works for "infrequent" updates). The lack of easy sharing between worktrees and local forks is painful as well when coupled with poor support for shallow cloning the things. My biggest gripe is `git archive` just punting instead of doing anything useful. `git-archive-all` is better, but still doesn't handle the cornercases that we end up hitting (custom attributes are only supported at the top-level; we can't export-ignore either because we need to query for other attributes).

The solutions exist, but are spread out, not easy to stitch together, or just end up being custom code.

Meta's Sapling source-code management system

bartoc — Thu, 17 Nov 2022 22:52:18 +0000

I broadly agree (also, note that if you have a multi-repo scheme like this you can use git namespaces to keep the separate heads, branches, and tags while using the same object store and thus possibly deduplicating more things).

However, I think repo is .... not that good. It's mostly submodules plus some features that are almost always not a good idea. I don't think this is really true of repo given its age and Gerrit integration, but a lot of these tools feel like someone reading that submodules were problematic somewhere and just reinventing them without really understanding them. Basically all the criticisms of submodules have easy solutions or are just misunderstandings about how git works.

Meta's Sapling source-code management system

khim — Thu, 17 Nov 2022 22:25:52 +0000

This is similar to crater run, I guess.

Only crater run ensures that compiler can be updated (and not other libraries) while in monorepo everything is supposed to work like that (but you can also update all the clients, which is the whole reason it's a monorepo).

Meta's Sapling source-code management system

NYKevin — Thu, 17 Nov 2022 22:06:47 +0000

> Branches are for bugfixes.

Not even. At least in my experience, branches are for releases. You branch at a point where the build is green, do any cherrypicks that you need, cut a release on the branch, and that's it. No merging. The branch just gets abandoned (maybe we GC it eventually?).

The corollary to this: If your code does not run at HEAD, that's your problem. You cannot make your own private branch where you use some ancient version of libfoo that nobody else is willing to support. When libfoo updates, everyone is expected to update with it, or else your code stops building (and, eventually, stops running in production). Depending on the size and reasonableness of the breakage, the people who maintain (and/or vendor) libfoo will probably be expected to help you transition to the new version, or even to do it for you, but you can't just say "we like the old version better" and expect that to end the discussion.

The corollary to the corollary: You really want to have good test coverage, because the libfoo maintainers can't be reasonably expected to find the breakage if the tests all pass (or if there are no tests).

Sapling source-code management system - no staging area?

NYKevin — Thu, 17 Nov 2022 17:54:54 +0000

> Pretending that that's some sort of abstract principle rather than for concrete benefit is rather spectacularly missing the point.

Ironically, this sentence is too abstract, and I have no idea what you are talking about.

Meta's Sapling source-code management system

paulj — Thu, 17 Nov 2022 16:45:36 +0000

Which code-base are you looking at?

I'm looking at https://github.com/facebook/sapling and - at a high-level anyway - I don't see anything from mercurial in the head/tip, nor in the history. I know internally that monnooke was a from-scratch rewrite. And the Eden object store and SCM backend isn't from mercurial either.

I could be confused, but can you be more explicit about what part of Sapling started out as mercurial code?

Meta's Sapling source-code management system

IanKelling — Thu, 17 Nov 2022 15:28:04 +0000

> I'm not sure this is a fork of the mercurial code-base.

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

Meta's Sapling source-code management system

ldearquer — Thu, 17 Nov 2022 15:05:01 +0000

Now that's two of us :)

Meta's Sapling source-code management system

khim — Thu, 17 Nov 2022 14:36:10 +0000

> Merging X first, and Y second does compile, but can't be integration-tested.

If that's a monorepo then there are no merging. Individual commits are merged, of course (you can not have few thousand people working on the same code and not have some conflicts) but features are never implemented in branches.

Branches are for bugfixes.

Android couldn't follow that model 100% because of organisational issues, but it tries.

> OK, so you have 40 ppl working on feature X, and 40 ppl working on feature Y.

That just means that 80 people are committing to the trunk, what's the problem?

Meta's Sapling source-code management system

pkolloch — Thu, 17 Nov 2022 14:07:08 +0000

Incremental integration with feature flags.

Meta's Sapling source-code management system

nysan — Thu, 17 Nov 2022 12:51:54 +0000

"The trick is simple: don't provide means to combine two versions. Period."

OK, so you have 40 ppl working on feature X, and 40 ppl working on feature Y.
In the end, you need to integrate and test X and Y together, since they are dependent.
Merging X first, and Y second does compile, but can't be integration-tested.

How would you do this, in case you only allow a single CM version in the monorepo ?

Meta's Sapling source-code management system

khim — Thu, 17 Nov 2022 12:20:57 +0000

> In the end, all monorepos end up into what clearcase used to be. A big configspec to select different versions from different subdirectories of the monorepo.

How much time this “end” needs? AFAIK Google's one haven't devolved into that.

The trick is simple: don't provide means to combine two versions. Period. If you need two versions of some third-party code for some reason then you just create two directories. Like Python2 vs Python3 difference was handled in the linux distros for years, too.

> And then comes a corporate merger, and now you have two monorepos. :-O

Why is that a problem? As long as you don't start weird automerger schemes and just treat code from another repo as “third party” and import code in the appropriate fashion everything works. Google does that with abseil AFAIK.

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

repo exist because Google needed something similar to monorepo but open-sourced. I deal with it on my $DAYJOB. It kinda-sorta works but is just so flaky, cumbersome and unreliable compared to normal monorepo.

Meta's Sapling source-code management system

paulj — Thu, 17 Nov 2022 10:47:31 +0000

Oh, and 'sl' was pretty cool and useful. I liked it.

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.

Meta's Sapling source-code management system

nysan — Thu, 17 Nov 2022 10:43:01 +0000

In the end, all monorepos end up into what clearcase used to be.
A big configspec to select different versions from different subdirectories of the monorepo. And then comes a corporate merger, and now you have two monorepos. :-O

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.

Meta's Sapling source-code management system

paulj — Thu, 17 Nov 2022 10:42:55 +0000

I'm not sure this is a fork of the mercurial code-base.

The internal history of this, as I understood it (a couple of years out of date, and not near any team responsible - just as a user), is that FB started with mercurial. They then had to heavily customise hg to make it work at the ever greater scales they had internally with more and more code and developers working on it. Until they had effectively completely rewritten the back-end to use a Facebook specific, distributed object store - that's the "eden" bit in the source code I think (maybe simplified / pared-down for external use, I don't know). The front-end hg tools I think were heavily modified too. Sl however is a from scratch rewrite. I think it started out as a wrapper around the hg tools, but grew into a standalone front-end. There was also an effort to reimplement the back-end in Rust, along with front-end tooling for that - I think that's the "Mononoke" bit in the code, IIRC.

Last I remember, I /think/ the developer workflow still had some odd cases where you needed to use the hg commands, but for nearly all stuff you could use sl for your daily work-flow.

I presume that progressed to the stage where the completely rewritten Facebook^WMeta front-end + backend, sl / mononoke, can do everything itseflf, and is feature complete - and hence this can be released as "sapling" (retro-fitted name).

Meta's Sapling source-code management system

nysan — Thu, 17 Nov 2022 10:34:07 +0000

Ugh,

monorepo is a bad idea for so many reasons.
https://gerrit.googlesource.com/git-repo anyone ?

Sapling source-code management system - no staging area?

jthill — Thu, 17 Nov 2022 05:16:04 +0000

Git's not abstract, it's concrete, that's true; it uses abstractions to help understand and describe what's possible, not to limit it. Pretending that that's some sort of abstract principle rather than for concrete benefit is rather spectacularly missing the point.

Meta's Sapling source-code management system

bartoc — Thu, 17 Nov 2022 03:56:39 +0000

(I work for Microsoft)

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

Sapling source-code management system - no staging area?

NYKevin — Thu, 17 Nov 2022 00:05:04 +0000

That's a Mercurialism. Sapling inherited it.

In general, Git's attitude seems to be that high-level concepts like commits and rebases should be understood directly in terms of their low-level on-disk representations as trees, refs, etc. Git's on-disk representation uses a staging area, so therefore you have a staging area as part of the UI. Mercurial does not do this. In Mercurial, the on-disk representation is considered an implementation detail, subject to revision at any time, and you are expected to understand commits as primitive objects. A staging area would be redundant to what Mercurial calls a "secret commit" (i.e. a commit that you don't intend to push, and that the tooling will prevent you from pushing accidentally), so Mercurial does not supply a staging area, even though there is some denormalization under the hood. This is a relatively small difference of opinion, but an important one.

Sapling source-code management system - no staging area?

sdalley — Wed, 16 Nov 2022 19:24:08 +0000

Hm, it doesn't have a staging area, and touts this as an advantage. I must say, losing this feature now that I've come to appreaciate it in git, really feels like a backward step...