Facebook used to be involved with the Mercurial community, but it was difficult to work with them. They always wanted to do things their way, had their own intentions, and started to demand that the Mercurial project work the way that Facebook wanted. For example, they demanded that we start using Phabricator and started slowly removing sequential revisions from Mercurial in favour of always using node hashes everywhere, arguing that for their gigantic repos, sequential revisions were so big as to be useless.
Eventually the disagreements were too great, and Facebook just stopped publicly talking about Mercurial.
I figured they would emerge a few years later with their fork of it. They love doing this. HipHop VM for PHP, Apache Hive, MyRock; these are examples of Facebook forking off their development in private and then later emerging with some thing they built on top of it.
The Mercurial project is surprisingly still chugging along, and there are still those of us who actually use Mercurial. I doubt I'll switch over to Sapling, because I disagreed with the things that made Facebook fork off in the first place. But if others like Sapling and this manages to put the slightest dent into the git monoculture, I'm happy for the change and innovation. I really hope that git is not the final word in version control. I want to see more ideas be spread and that people can see that there can be a world beyond git.
For example, I use Mercurial’s absorb command [1] and was pleased to see it in Sapling.
Overall this looks promising.
[1]: https://gregoryszorc.com/blog/2018/11/05/absorbing-commit-ch...
Hard to discover and remember but once you do it usually works smoothly.
https://lobste.rs/s/nws1uj/help_us_name_new_mercurial_featur...
Yes, I read the manual for git, but I never needed to for Mercurial.
I wish it had won the DVCS wars.
Git is a twisty maze of operations combined under poor names (e.g. git reset) with dozens of obscure options (e.g. man git-log) and broken abstractions (e.g. what is HEAD and why does Git emit a warning whenever I check out a tag?). I often feel so sad that the entire software industry has fallen to Stockholm syndrome under Git — we think these contortions are normal, when in fact they are arcane.
> The Sapling CLI, sl, was originally based on Mercurial, and shares various aspects of the UI and features of Mercurial.
common problem in open source. any project that gets big enough effectively stops anyone from wanting to work on an alternative, or use an alternative, due to the momentum of the large project.
deviating from it makes it harder to collaborate or be productive because the big project does everything (though often poorly), everyone knows it already, and no one wants to learn something new, and no one wants to work with the people using the weird thing.
same reason why it's hard to make a Facebook alternative.
Things really became one-sided after github started gamifying open-source contributions, and when a new generation who perhaps grew-up in a more competitive academic setting took it as an opportunity to make their resume more impressive.
We peer-pressured ourselves into collectively using a less-than-ideal tech because that was the price to pay to belong.
Seems to be a recurring pattern when people interact with open source communities. Why does it have to be like this? It's not just companies either...
Because motivated, high performing people need to have control over their own destiny. Because cookie-cutter solutions which work for 90% of use cases are often worse than something explicitly tuned for you.
People having specific needs, getting frustrated and then solving their problem is a feature of opensource code. Its not a bug. It is the engine of innovation and improvement. Forking means we can both get what we want, even if our needs are contradictory or we don't want to work together.
This happens with commercial offerings too - but its a mess. You can't just fork the code without paying (or sometimes at all). And every fork is private, so work is duplicated and collective learning doesn't happen. Expensive consulting-ware might be the best case outcome.
The ability of motivated people to fork projects and have their own spin on things is one of the biggest strengths of opensource. May the best forks win.
I'm certainly in that camp; and it pains me every time I have to use the hggit extension to convert a mercurial repo to git in order to work with everyone else...
Could you elaborate on what these things are and why you disagree with them?
I have been waiting ten years (https://www.google.com/url?q=https://stevebennett.me/2012/02...) for someone to develop a better CLI for git, someone with the scale and clout to do it well and gain mindshare. It's not that useful to learn a new workflow if no one you ever work with will be familiar with it.
This looks incredible. A simple command to uncommit or unamend makes you further realise what a disaster the Git CLI is.
So yes, in short I agree.
Put my stuff from the last commit back into working directory?
Very unintuitive (soft?) and I’ve just memorized this for the past 10 years.
just they build one for switch.
i hope they build a migrate one, where you can switch to new/other hashing standards.
(Disclaimer used to make VSCode)
Harder with an amend due to having to get the difference of commits within the reflog, sure.
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.
`abort: please use 'sl init --git .' for a better experience`
What's going on here? I couldn't find info in the `sl init --help --verbose` output or in the Sapling website.
I'll take a look at the help later to see what we're missing here.
My impression from the blog post is that I can use sapling and have everything "look" git-like from the remote repo's point of view.
In order to work with Git repositories is this essentially the Mercurial client using hg-git on a converted repo under the hood?
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.
I'd be curious about your use case, since we don't actually use hooks internally all that much.
https://sapling-scm.com/docs/introduction/installation/#maco...
The "download via curl and then install with homebrew" method struck me as unusual
Were there problems getting Homebrew bottle building/publishing work as you needed?
Sure, most people are probably fine with Git once they learned it and if they only work with small to mid sized code bases (like me). But I'm still happy Sapling is out there, I might use it or learn from it if I ever run into the problems it solves.
...and yes, I realize it's weird to say this considering Google is known for abandoning things. Maybe it's just coincidence that I've run into more abandonware from FB than Google?
Better than Microsoft? I don't think I've ever been able to talk to a human at Google, whereas with Microsoft, I get feedback very quickly on issues and pull requests. Does Google even interact with people with open source? For example, I am using Skia via SkiaSharp, and the only place I know of to go for Skia help and issues is their Google Groups page, a website out of the 2000s. And very few seem to actually monitor the group. I'm not even really sure what Google does in open source. Even the things that are released to the public, like Skia, are well known to come with a huge amount of internal baggage.
Whereas Microsoft has dozens of active projects on GitHub where you can talk directly with the people working on it at Microsoft.
As far as I can tell, most of zstd's development is still by Facebook employees, though not all of it. I tend to think zstd has enough traction that development would continue even if FB were to abandon the project.
This is my naive understanding. A for profit company open sources a project that they have been using and developing internally. The have built a philosophy and understanding of the project as they use and develop it. Most of their action regarding the project is that they must use it and they usually don't have any other options.
Because the foundation is already laid the solution for its shortcoming is having just an understanding of them. Then you open source the project knowing that you have developed the project to it's completion.
Now comes the OSS community. Either we request features that goes against the project philosophy or we don't want to get involved because we don't need to compromise and acknowledge the shortcomings because we have options.
A good solution can be open sourcing projects that the org thinks isn't complete and needs further development without compromising security, philosophy and usability. Because if you have a list of things you need, you can ask the OSS community to fix those things rather then be critical of the foundation and philosophy.
Whatever is cool at Google IO XYWX is already abandoned by the time we reach into Google IO XYWX + 1.
If it comes to stuff I actually want to _use_, I avoid projects backed by a single or a few companies - like Sapling. So from that angle, I'm not particularly impressed either.
Flow[1]: JavaScript typing system from Facebook. My company uses it, open development has since been halted by Facebook so we're effectively on abandonware.
EDIT: React: Javascript framework from Facebook, my company uses it, and while it has its warts it works pretty well all things considered and Facebook has continued to support and evolve it over time!
For all I know Sapling is fantastic and will be developed for years to come. But personally I can't help but feel "once burnt, twice shy" (or in this case, twice burnt once shy). I'd be happy to be wrong here because ergonomics of Git are really frustrating in many places.
0: https://www.phacility.com/phabricator/ 1: https://flow.org/
Your thought process is completely fair, but just to clarify: Phabricator was never open-sourced by Facebook. The main engineer behind Phabricator (Evan Priestley) left Facebook to create Phacility and open-source Phabricator; that was never a Facebook product.
React[0]: JavaScript front-end web framework from Facebook. For good or ill, the most widely-used web framework in the world.
Not to say that Facebook will maintain Sapling, but React does stand as proof that they're not incapable of carrying an open source project to the finish line.
Overall, I'm glad they do these things, though since it is better to have this code accessible than absent. Good on them!
How does sapling let me take a long list of commits and break them into larger but more manageable chunks?
git add -p allows me to add chunks easily and create commits, git commit --fixup allows me to mark a commit as fixing a previous commit, and with git rebase -i --autosquash I get to easily take those fixup commits and meld them into the previous commits.
Also reviewing a stack of patches is annoying in many cases as I care more about the end result vs each individual commit. But that may just be my experience talking in open source where I am working on smaller but better well defined projects vs a large mono-repo where there may be a lot of changes across many disparate parts of the code base that make it difficult to look at the "whole" vs a patch that is more localized.
To split a single commit, you can use `sl split`, which is quite difficult in Git. (I miss that feature in Git quite a lot.) You can also use the `sl absorb` command to automagically merge local changes into the previous patches where they seem to belong (roughly speaking, commute changes backwards until they would cause a merge conflict, but it's a little smarter about avoiding certain merge conflicts).
It sounds like I would need to:
- switch - amend the commit - restack? - switch back to the HEAD?
Fold based upon the documentation seems to move older commits into the current commit? vs the other way around? https://sapling-scm.com/docs/commands/fold
This doesn't seem analogous to git rebase --autosquash which merges the mixup into the old commit.
your workflow resembles mine so I'm in the obligation of mentioning https://github.com/jesseduffield/lazygit which allows you to stage individual lines among other features. https://www.youtube.com/watch?v=CPLdltN7wgE
Sure, but you can use `git commit -p` to get the same benefits without explicitly using the staging area.
I also use this workflow. Lots of detached HEAD mode, using the index to commit things piecemeal, then rebase as needed, until I'm finally done.
- It's too hard to scale for a large monorepo!
- Google does it just fine!
- But I don't have access to Google's tools!
So kudos to Meta for both solving the problem and making it available to others. It will be interesting to see how useable it is outside of Meta. I know for example that while Netflix open sourced a lot of tools, most of them weren't useable unless you ran all of them together. So far Meta has been good at avoiding that, so hopefully that remains the case.
A few years ago they had a Virtual File System extension for Git. Now it's a public fork of Git that is intended for large repositories (several hundreds of GB). It adds a `git scalar` command, see https://github.com/microsoft/git/blob/HEAD/contrib/scalar/do...
Firstly, it's not "giant amounts of binaries" it's "a very small amount of binaries". A few GB is enough to cause significant problems.
Secondly, This _is_ an issue with git. If my project requires binary files, git should handle it. How should we handle logos in a mobile app, branding images on a website, audio files for background? That's before you get to the question of "how does a video game store the source version of a 100GB worth of compressed assets?"
I think another thing that matters is how you store branches/code under review. In Linux, each team/person has their own repo. The main "Linus" repo has mostly the finished code. In a company it is much more common for everyone to store their unfinished code centrally. Perhaps this also accounts for some increase in size.
(a) People arguing git is fine, and shouldn't be simplified
(b) People arguing about the right way to use git, and flame wars about best git workflows
I mean most people simply see (b) and conclude "this is a huge hassle, I don't want to annoy some git-workflow-purist, I'm just going to walk on eggshells on this tool and hope I don't break anything"
It's as much a social problem around conventions, and lack of opinions in the tool itself, then anything about the underlying technology (which is rock solid IMO)
I use git begrudgingly because that’s where the world is, but I long for an improvement in this space.
Git has a lot of incidental complexity and unforced design problems, but the fact that it's inherently flexible is not one.
(c) Git is a disaster that has destroyed source control for 15+ years and the industry is unable to recover from due to Stockholm syndrome
It’s impossible to discuss source control without people coming out of the woodwork to shit on git. It doesn’t work right. It’s too hard. SVN was better. Mercurial should have won. Blah blah blah.
Git isn’t perfect. And the command line has improved (I don’t care much, I use a GUI).
But the number of people who seem to insist that because it doesn’t work for them or they don’t personally like it it’s horrible and everyone should abandon it is crazy.
And it makes trying to read/participate in discussions like this painful.
Is git sometimes obtuse? Sure, but it's fast and incredibly powerful. My everyday commands are easy to use, and if I need something special I go to the documentation - just like any other SCM.
Its design is inspired by Sapling, and, in fact, it uses some of the same code, such as the segmented changelog implementation. Possibly some of its ideas made their way back to Meta, such as interactive undo?
Jujutsu also supports colocated Git repositories: https://github.com/martinvonz/jj. It also has the working-copy-as-a-commit idea and conflicts are stored in commits (so rebases always succeed). I think it's a step forward compared to git/hg/sl.
What do you mean? Can't you use Sapling in the same Git repository you normally use? The first sentence is "Sapling is a new Git-compatible source control client". Is there something they're not telling us?
EDIT: Looks like it calls out to the git executable occasionally (https://news.ycombinator.com/item?id=33615576) and presumably works on the git object model under the hood, but you can't use `git` on a repo checked out using `sl` nor vice versa. It's a stretch to call it Git-compatible but I guess not completely wrong.
EDIT2: Here's a good summary https://news.ycombinator.com/item?id=33617689
git-branchless is only an extension to Git, so it naturally operates in the Git repository. Jujutsu has a mode to create the `.jj` directory alongside the `.git` directory and co-locate them, which I find very convenient in practice. (Originally, Jujutsu only supported Git compatibility in the same way as Sapling, via pushes and pulls, but they added co-location later.)
> Looks like it calls out to the git executable occasionally
I believe Jujutsu never calls out to Git, and that all of its `jj git` interop commands are implemented via direct bindings to libgit2. This is less fragile in many ways, but it can also mean that `jj git` interop might be missing some new feature from Git. Fortunately, you can oftentimes just run the Git command directly in the repository when co-locating.
> presumably works on the git object model under the hood
There's no guarantee of this: the Mercurial (and therefore possibly Sapling?) revlog model is a little different from the Git object model, as I understand it. But it doesn't really matter, as long as it interoperates seamlessly. For now, I believe they do literally have a `.git` directory somewhere under the `.sl` directory, but they reserve the right to change that.
Sapling, on the other hand, has much better support very large repositories, since they've spent a lot of time on that over the years. We're going to copy some of Sapling's solutions to Jujutsu soon, since we're working on integrating it with Google's monorepo (slides: https://docs.google.com/presentation/d/1F8j9_UOOSGUN9MvHxPZX..., recording: https://youtu.be/bx_LGilOuE4).
Is this pushed to the remote when running as a git porcelain?
How I think that will happen is using CRDTs against an AST to remove most merge conflicts.
No joke, this might solve every major pain point I've had in mid-size-to-large teams in both the FOSS and proprietary world if it can deliver on what it says here, not to mention many issues with monorepo migration, work sharing, subproject management, etc. Many of these problems are very real but mostly ignored or we've decided to live with them.
Git is great, I'm one of the earliest GitHub users there is. I was also an early user of Darcs (which formed the theoretical basis for later competitors like Pijul -- so I'm not unfamiliar with radically different approaches), have a lot of experience with all kinds of administrative Git tasks for large repos; there's still plenty of room to fill gaps with new blood.
Nobody is trying to replace git; that’s not a stated goal. Plus git is so entrenched, it’s not going anywhere anytime soon.
However, few companies have more gigantic code bases than Facebook, which not that long ago, had their entire monorepo [1] in Mercurial, which had certain advantages over Git at the time.
So if there’s an organization that knows the pinpoints of version control, I’d put Facebook on that list. They’ve been working on approving version control at scale for more than 8 years.
As long as it’s git-compatible, the git true believers will have nothing to worry about.
[1]: https://engineering.fb.com/2014/01/07/core-data/scaling-merc...
People are SUPER over dealing with using Git on large repos.
https://www.mercurial-scm.org/repo/hg/graph/tip
, seems to have been included since 2005 :)
Yes, this would be awesome for Mercurial.
...until I got to pull requests (Granted, that is github, not git). But it looks like you cannot generate a standard pull request with it.
https://sapling-scm.com/docs/git/intro#pull-requests
Haven’t tried it yet, looking forward to it.
Of course, when it comes to github PRs, there are so many different "styles" of pull request, I'm not even sure which one should be considered "standard".
That's actually a deal breaker to me. Effectively using Git's staging area has become so integral to the way I work with repositories that I don't think I can ever go back to the old style.
edit: yep, so long git
check if a given commit is included in a bookmarked release:
sl log -r "a21ccf and ancestor(release_1.9)"you can always just use another commit as a staging area, I figure, and it'll make all the commands simpler and more intuitive so it wins in my book.
We develop HighFlux[1] which also gets rid of the staging area. It simplifies your mental model of what's going on a lot.
Because everything you save is automatically committed, switching to a different task/branch is also always instant without needing stash.
Because what you're testing locally is what you're committing, I also never have CI failures anymore (with the staging area I frequently had unexpected interactions with unstaged changes and sometimes even accidentally forgotten added files).
There are projects, like Apache Hadoop, that are open-sourced because they're an open-source answer to an extremely powerful, successful, commercial product. Sapling is nothing like this. The reason it's being open-sourced is because Meta considers it tech debt and I'm not surprised.
Google did exactly the same thing, but hasn't open-sourced their tools.
Projects to drive incremental productivity make not a lot of sense for small companies, but become immensely valuable at very large companies. A 1% improvement if you have an engineering staff of even just 10k is worth 100 engineers, and FB is much larger than 10k.
Under the circumstance that no existing source control system can handle a monorepo as large as Google's or FB's. The custom source control system is not a hobby. It is vital to both companies.
I understand the sentiment and my suspicion is similar. Do you have a source?
I'd really like to see a DCVS with better signing support and with some form of access control (on the remote), so every change can be traced back to the author, and so that some parts of a repo can only be modified by specific authors. Git hooks (on the remote) can sort of achieve the latter, but it's a bit of a pain.
sl help signWhatever is to come of my cute animations!
[Think of the trains!](https://github.com/mtoyoda/sl)
> First things first, please go to your phone and turn off wifi to avoid voter ring detection and upvote us on Hacker News!
absorb split histedit uncommit unamend revert metaedit
Once you use them, it's hard to go back.
It's also easy to commit / amend part of your work by selecting the lines to include in nice curses interface (--interactive).
However, I don't understand why I would want 1 PR per commit. I feel like that's a non-starter for me.
Is the idea that no one should use branches - so there's only 3 points of interest: HEAD, main, and origin/main? And then is the idea that it's only 1 commit per feature to merge?
So I would work on something, make a PR, continue working on something else without making any git checkouts and then make a new PR?
But you can certainly create new "branches" of development which aren't stacked on top of each other. They just don't have to have names. You can consider them to be "anonymous" branches.
The main advantage of 1 commit per PR is to review and commit smaller changes (a single commit at a time).
Doing this doesn't really make them good, but it makes them at least reviewable.
The utility should obviously be called `sap' and not `sl'.
Stacked PRs are a blessing and a curse - still not convinced they are the correct way to build software as a team.
Obviously life is simpler if all your work is sufficiently non-intersecting that you can send separate diffs/PRs and e.g. rebase them separately, but if you have Big Feature X and you still want small, single thesis diffs, where else do you turn?
None of this makes any sense to me.
> Local branch names are optional.
As are they in git, just hang out with a detached HEAD.
> There is no staging area.
Practically the entire world sadly invokes `git commit -a` anyways and you still have to add untracked files.
Neat project but I don't get what this is solving for.
But this is mercurial. Or rather, it's mercurial rebased on top of the git data store, and it's a fork with breaking changes so it has a different name.
I do agree that the requirement to be online gives me pause. But I guess I don't know how much of a problem that would be in practice, since there's a mystery subset of functionality that works disconnected.
> Neat project but I don't get what this is solving for.
For us external people, it seems like it's mostly for using the hg interface with a github-hosted repo. The internal reason appears to be scalability to massive monorepos. Since I much prefer the hg interface to the git interface, I'm good with both of those motivations.
I agree that the Git commands are pretty primitive (aka low-level). But eventually you can learn the good patterns and deal with that.
For me, the big question is how to manage a monorepo (with zillion of branches) so you can express which set of branches are relevant to your current concern at time T:
- focusing on the dev of a given set of features,
- frozing them into a delivery,
- pushing a stable monorepo+that frozen delivery to your validation platform,
- once validated, integrating that frozen delivery to one of the master branches of the monorepo,
- management of the many master branches corresponding to each subparts of the monorepo into a supermaster branch
Does this tool (or Mercurial in general) help with all that mono-repository branch management ?
To your question about what/how Mercurial helps I'm guessing it's related to this, or other workflows enabled by Mercurial's Evolve/Topic features. It sounds like Sapling has adopted Evolve/Topics and making them functional on Git repositories though I'm not sure what it's doing under the hood.
Git's major value proposition is that they added moving parts until the system worked great. If you don't want named branches, staging, or any other piece of the ideology, then subversion is a fine choice.
But most folks moved on from svn for reasons
Moving from SVN to git felt like liberation because there were suddenly idiomatic ways of expressing states that were sort of smushed together by SVN -- stuff like, "I have some changes in my branch I want to line up for commit" which, became the handy one-word concept, "staging".
The before-times were marked by a lack of these fine distinctions. While they existed in fact, they were obscured in-system.
Like a map, any tool should 'resemble' the sphere of human activity it potentiates, and git resembles our diverse workflows better because it has so many asinine distinctions.
This was always its strength, and indeed, likely the reason the platform is called 'git' in the first place, as 'smarmy git' (English idiom for 'smartass') implies an insufferable drawer-of-distinctions.
And like a smarmy git, it's easier to complain about git than it is to replace it.
Was bulk of the team behind this laid off wherein it made sense to open source it to involve the community to take it forward rather than paid resources?
To be clear: I'm NOT criticizing them open sourcing this.
The team working on Sapling has been planning this release for a very long time and will continue working on Sapling to support our internal engineering efforts.
I don't actually want "No" staging area.
What I want is, once I "add" something, the file stays added.
Currently, I have `git st` alias setup :
st = !git add -u && git status
So I get `git add` but also don't have to re-add anything manually from there ...
Since I do `git st` quite frequently, this works out for me ...
If you want that behaviour, you can just `git commit -a` when you create your commit, then you only have to "git add" brand new unknown files.
git add -p
Allows you to select hunks of changes and stage them for committing...
I am a git hater myself. I mean, git just sucks. It always did, and it always was much worse than Mercurial. When they could have be seen as competition, I was forcing Mercurial as much, as I could, but then GitHub became a thing, and after a very short struggle it became just hopeless. There still are folks who use fossil or something, but ultimately git became THE SCM. So, yeah, I hate you, GitHub, I hate you, Linus, but I fully admit that you've won. So… now I can actually admit it isn't such a big deal.
Sure, it would be somewhat better if git never existed at all and we'd all just use a better SCM from the very beginning. But given it's just not the case, what it the problem, really? It isn't hard to learn git. I do know some people who are struggling with anything outside of simple pull-branch-add-commit-push workflow (usually performed via buttons in their IDE), but, honestly, I think they will be struggling with any other SCM just as much — it's just the difference between caring to build a mental model of the tool you use, and simply memorizing a number of popular commands. The tool isn't at fault here. So, really, git is kinda bad, but not that bad.
Monorepos? I mean, there were tools to work with them before, but does anyone outside of Google/FB actually work with repos that git cannot handle? Is it really a good idea to have such repos? I mean, it's nice that some tool can work with them, but is it actually important?
I mean, there is some new "better" SCM (often somewhat git-compatible) almost every year. But I've never actually seen anything that would make me push for that "better" SCM anywhere. Even for my personal projects. Git isn't "just git" anymore, there are countless tools that integrate with it, we all know it by heart and have sets of "best practices", how-to's, personal workflows, helper-scripts, etc. There is a huge downside to start using anything besides git, so what is the upside that would compensate for it? I never see one.
Many companies/organizations won't hit the size/scale where this matters but there are certainly plenty of companies who have large repositories and contributors that would benefit from something like Sapling over Git/Mercurial. These tools start to become slow. Many addons have been created to ease the problem (LFS or Microsoft's VFSforGit, narrow/shallow checkouts, etc.) but they also add complications (LFS especially in my experience). Monorepos have their advantages [1], and even with disadvantages they exist and won't go away. It's more appealing to migrate a monorepo to a new tool that adds more benefits specific to monorepos than to break apart a monorepo into separate repos.
The architecture that's being moved into seems to be less decentralized which is what Git/Mercurial were initially pioneering. I believe Google has essentially also built their own server-side SCM [2] and made Git/Mercurial clients (or wrappers for a client). I believe Microsoft did something similar forking Git and/or making their own server-side SCM but I don't recall where I came across that.
[0] https://engineering.fb.com/2014/01/07/core-data/scaling-merc...
[1] https://trunkbaseddevelopment.com/monorepos/
[2] https://www.quora.com/Why-do-Google-employees-use-Piper-inst...
Bash has weird defaults so you end up googling for everything. In fish, it just works and you barely need to search for anything.
Sane defaults matter. With hg, I don't need to struggle to get it to do what I want, it just gets out of the way. With git, sure it works but like you said it has a bunch of ducktaped tools together that change the defaults or just generally make things easier.
Now hg is half the pattern here. The other half is stacked commits. Each commit should build and get reviewed separately. There isn't any waiting for reviews on each commit, they all get reviewed over time and you rebase any changes that are requested. With git this is amazingly painful and half my zshrc is about making this simple. With hg, it just works. Take a look at hg absorb or hg split, theyre features built on top that yeah can replicated in zsh scripts but its kind of nice when you can assume they just work. It means junior engineers don't spend hours trying to fight git with stacked diffs.
Sapling is trying to fight the network effect here by doing the classic built a compatible but legitly better front end. Compatible with github but sane defaults is a BIG thing.
The fact that they have concepts like unamend suggests that they have thought about this in a way more turtles all the way down way than the Git designers. A versioning for your history changes—why, of course.
You can thank the Mercurial developers for these concepts.
Sorry, I just can't take an "open-source" project seriously that uses "we hope to open-source these in the future" in its pitch.
$ sl clone https://github.com/facebook/sapling
$ cd sapling
$ sl
@ fafe18a24 23 minutes ago ricglz remote/main
│ migrate packer to new CLI framework
~
~/sapling (main)> sl status
abort: '/full/path/sapling' is not inside a repository, but this command requires a repository!
(use 'cd' to go to a directory inside a repository and try again)
[0] https://sapling-scm.com/docs/introduction/getting-started/
I do wonder:
1) How it handles large (binary) files. This is a major pain point when using git and even the standard solution (git-lfs) leaves *a lot* to be desired.
2) How does server hosting currently work? I didn’t see any mention and am assuming it’s not an option currently? (two dependencies of Sapling are currently closed source)
I especially like the idea of stack. It's not something git can't do, but someone should've spent quite some time on tons of trial-and-error to nail the workflow. It's certainly a well aged project - a decade old! Kudos to that.
Or is it a new DVCS, with its own repo type, for which I can use the git client for?
I think the design of GIT still is a big risk for commercial companies.
I for one will remain skeptical. If they release it as free software, we can talk. Probably real innovation will happen elsewhere though, without the FB flavour to chew on.
Rust and C? that sounds like it is a pain to build, especially on Windows.
Ah, dammit
/s :)
How does sapling solve that? It can't...
IMHO Sapling looks like "Git for dummies". And Git teaches some pretty useful concepts, which are worth it.