33 ms·

Sapling: A new source control system with Git-compatible client

• bolinfest 4y ago
  Originally started as an extension to Mercurial, but grew into its own SCM with a cross-platform virtual filesystem in C++ and a distributed server in Rust.
• feep 4y ago
  https://sapling-scm.com/ https://sapling-scm.com/ https://github.com/facebook/sapling https://github.com/facebook/sapling
• ianlevesque 4y ago
  It’s hard to overstate how much better this workflow is UX-wise than the git(hub) default. I’m super excited to see it open sourced.
• elischleifer 4y ago
  the number of projects that require the scaling factor of something like this is very small. git with lfs scales very well for most repositories. That said the actual flow of git is pretty raw. There are other pretty solid projects out there that support undo commands into git. Stacked PRs are a blessing and a curse - still not convinced they are the correct way to build software as a team.
  • benreesman 4y ago
    Eh, it’s pretty hard to make a case that you don’t want stacked diff sometimes. 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?
  • IshKebab 4y ago
    Public projects, sure. But plenty of companies have very large codebases that would benefit from this. Even if Git can handle it it can get very slow with largish repos.
• victoryanus 4y ago
• Shish2k 4y ago
  I’ve been using FB’s mercurial fork for years, wishing for all that time that I could have the joy of the fb-hg CLI while remaining compatible with github because that’s where 99+% of the code lives - from my brief experimentation, sapling appears to be that. I look forward to never using the git CLI again :D
  • feep 4y ago
    I felt the same joy on reading the overview. Cleans up the git workflow so nicely. ...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 https://sapling-scm.com/docs/git/intro#pull-requests Haven’t tried it yet, looking forward to it.
    • jcranmer 4y ago
      Reading the documentation quickly, it looks like you can generate a standard pull request, it's just that the PR may not conform to expectations if there are multiple commits. 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".
    • Shish2k 4y ago
      I actually just created my first PR from a sapling repo now - not sure why it’s not documented, but you can push your local development branch to a remote server, and in the case of github, you even get the “it looks like you’ve just pushed a local branch, would you like to turn this branch into a PR?” prompt, and it appears indistinguishable from a branch created with the Git CLI.
      • aseipp 4y ago
        The message generated with the hyperlink for creating a PR is actually done server-side, you can customize any git server to do this, more or less. So yes, it should behave approximately the same assuming you can just do the basic push interactions.
• nailer 4y ago
  This won’t go anywhere even if its 20% better than git. To replace git’s network effects, you need to be 10x better. How I think that will happen is using CRDTs against an AST to remove most merge conflicts.
  • ajkjk 4y ago
    I think a lot of people see this and think "I'm switching as soon as possible". It might be the 10x you need (although IMO 2x would do). People are SUPER over dealing with using Git on large repos.
  • noahchumsky 4y ago
    You may find https://pijul.org/ https://pijul.org/ interesting.
    • softjobs 4y ago
      And https://github.com/martinvonz/jj https://github.com/martinvonz/jj.
      • pmeunier 4y ago
        Because it is based on Git, jj is not a CRDT, it seems to be a better merge algorithm (even though the details on their algorithms are scarce). When I say "not a CRDT" I'm obviously talking about HEAD not being a CRDT, a Git repo is append-only, so the history of a Git repo actually is a CRDT (but that's not what the comment above meant).
        • martinvonz 4y ago
          I think the more important thing is that jj (and hg and git) don't use the AST at all, at least not yet. Does Pijul?
  • justinsaccount 4y ago
    Does network effect even apply if it's compatible with existing git repositories?
• ripa 4y ago
  What is the argument against having a staging area? The Git staging area is crucial in my mind.
  • mitrandir77 4y ago
    It's simply not necessary to have that feature. Sapling encourages regularly committing and amending commits rather than staging changes. It's also easy to commit / amend part of your work by selecting the lines to include in nice curses interface (--interactive).
    • ripa 4y ago
      I guess each to their own. I want to stage my commit with regular commands, and then have the staging area work with (diff, add/remove etc). I don't care for an interactive tool, IMHO I prefer using commands that are repeatable and learnable instead of stepping through some interactive workflow all the time.
    • lijogdfljk 4y ago
      I agree it's not necessary, but i like having it because it lets me separate what's going to be added before i actually commit. I still commit small, frequent. But i like `git add -p` to skip debug lines, hardcoded conditions, etc. I don't want to mistakenly auto commit a whole pile of lines and then have to remove debugs/hacks/etc from things i've committed. Stage + Unstaged is my working area, and the two live together quite nicely to me personally. I could live without it, definitely.. but i'm not sure i'd want to.
      • arxanas 4y ago
        In those cases, I find it best to either 1) use the interactive commit tool to not commit debug junk, or 2) put the debug junk in its own commit, which I'll later discard (and, plus, that means you can't accidentally include it in a real commit).
        • sa1 4y ago
• chungy 4y ago
  > There is no staging area. 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.
  • masklinn 4y ago
    Meh. If it has mercurial's revsets instead of gitrevisions(7) I'm game, I'll happily give up the staging if I don't need to open that manpage ever again. 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)"
    • chungy 4y ago
      Is it really that confusing for Git? I had basically that entire manpage memorized early on (even before the manpage existed....)
      • masklinn 4y ago
        > Is it really that confusing for Git? Complete shit is what it is. It's awkward, messy, inconsistent, and hard to compose.
        • IshKebab 4y ago
          The CLI and nomenclature for the staging area (what should be called "draft commit") is awful, but the actual concept is very easy to understand. I seriously doubt anyone who uses a sane interface to Git (e.g. a GUI) has any trouble with clicking + to add changes to the draft commit before committing it. Most GUI tools let you automatically add all changes before committing anyway so you don't have to know anything about it if you don't want to. They just needed to name things better (what is a "soft reset" again?).
          • jcranmer 4y ago
            The main problem I have with the staging area is that it amounts to being something that's like a commit except for, you know, not actually being a commit, and therefore things that normally work on commits don't necessarily work on the staging area. A better fix would be to make the staging area an actual commit, and then reframe everything as easy ways to edit the latest commit. (This meshes well with adding features like Mercurial's phases or changeset evolution that make commit editing somewhat safer).
• 1attice 4y ago
  I'm not interested in a simplification of git, sorry. 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
  • 1attice 4y ago
    Despite the greytexting of this comment, I'm still really interested in the discussion around it -- and I'm really curious to hear from people that have the opposite experience. 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.
    • arxanas 4y ago
      In my opinion, Git added too many moving parts in a poorly-designed way. Commits, the staging area, and stashes all implement the same sort of idea, but interact poorly and considerably complicate workflows. Having them is better than not having them, but Git would have been better off if they consolidated into a single idea and concentrated their efforts on that. If you can remove a concept from Git and still support the same workflows equally well, then surely that concept was unnecessary. (Whether the staging area is actually better served by other concepts is a matter of judgment.)
      • 1attice 4y ago
        Interesting -- I have the opposite impression, and we're both just simply staring at the same pile of distinctions and disagreeing on whether it 'resembles' the workload. I imagine this will be settled by git steamrolling sapling in the market, but I wonder if there's a faster (and less network-effected) way to adjudicate? Both your position and mine seem lodged in a taste/touch/feel context, which seems like a data-poor place to make good decisions. On the other hand, I'd say that absent sufficient data, one should pick the most flexible tool, which I'll bet in this context is the one with the most moving parts, i.e. git.
• softwaredoug 4y ago
  Its interesting how these threads about Git simultaneously have (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)
  • indymike 4y ago
    I remember when git was new, and the subversion crowd didn't jump on. Same discussion, different subjects. Git is/was awesome... but there is certainly room for improvement.
    • juped 4y ago
      Subversion? You mean that unimpressive flash-in-the-pan CVS clone?
      • int_19h 4y ago
        As I recall, the Big Deal with CVS-to-SVN migration was that many teams learned to creatively exploit the fact that CVS does versioning on a file-by-file basis. As late as 2008, I had to work in an environment where checking out different versions for different parts of the company's CVS monorepo was required to get anything to build.
  • 0cf8612b2e1e 4y ago
    I would argue that camp a) is more diehard than your description. Some people will argue to their death how perfect a tool git is and it would be impossible to operate without a tool that exposed so much low level power. I use git begrudgingly because that’s where the world is, but I long for an improvement in this space.
  • tikhonj 4y ago
• fhd2 4y ago
  Not a big fan of FB as a company, but I think their open source work is pretty impressive. Various other large companies have the problem of giant monorepos that they constantly need to onboard new developers to, but I can't think of anyone other than FB who consistently released their solutions. 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.
  • bogwog 4y ago
    Facebook has a lot of interesting open source projects, but they tend to abandon them. As far as oss goes, I think Google is the best. As long as you don't mind dealing with 3 different custom build systems within the same codebase, their projects usually have dedicated teams maintaining them. ...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?
    • loudmax 4y ago
      Fortunately, zstd seems to be in active development: https://github.com/facebook/zstd https://github.com/facebook/zstd 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.
      • 0cf8612b2e1e 4y ago
        This is probably a naive take, but I think of compression software as something that can be “done”. Unlikely to be a lot of code churn required for such a project to be relevant for a very long time.
        • unmole 4y ago
          Except for the fact that zstd has seen steady development and improved performance.
• davidpfarrell 4y ago
  > There is no staging area. 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 This auto-updates the staging area for files that were previously staged. 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 ...
  • ArchOversight 4y ago
    This would break the workflow of using the staging area to break a larger change into smaller commits. git add -p Allows you to select hunks of changes and stage them for committing...
    • shagie 4y ago
      For GP's use case, its "added some stuff, want to stage the stuff I modified since then to those files"... which I feel is a perfectly normal workflow. There's nothing saying that one can't add chunks to the staging area and then immediately commit it without invoking that alias afterwards (since it is a very deliberate "add these things" rather than "adding a bunch of things and keep adding."
    • tome 4y ago
      > git add -p git commit -p achieves the same, but avoids explicitly using the staging area.
  • masklinn 4y ago
    That seems like the worst possible use of the staging there is, it creates overhead and complicates diffing for no value whatsoever. 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.
    • krick 4y ago
      Not really. I'm not sure I want it to behave the way GP suggests, but I definitely want to have staging, and `git commit -a` is basically an equivalent of having no staging. The reasons for that are: 1. In the vast majority of cases there are multiple files I want to commit together. Usually I change them multiple times during the process. 2. It almost always starts with some debugging in a couple of other files, and I often want to keep that debugging for a couple of next commits, but `git checkout HEAD` these files in the end. 3. For me, the most popular way of using git rebase → edit (which I do reasonably often) is splitting a commit into 2 by separating files. This is easy enough by just changing a status of a file from "staged" to "modified" (I even have `git unstage` alias for that) and commiting. So I kinda get why GP wants what he wants. This isn't crazy. Now, that being said, I personally have absolutely no problems with how git does that now: I've figured out a workflow that solves these problems for me, and everything is ok now. This workflow is basically making many dozens of tiny commits to a branch without even bothering to name them properly, and then just doing `git rebase -i` many-many times while working on a single branch. So I just commit the code I don't intend to keep with a label "drop that", and drop these commits when I'm done. And other commits usually are heavily reordered and squashed into 3-5 larger commits that make some sense on a higher level (like 500 LOC of refactoring first, and then 1 LOC of an actual bug-fix, which usually makes much more sense than just 500 LOC of a bugfix, that solve the problem somehow, but it's absolutely not obvious how exactly). I rarely can figure out that separation before I'm done. In fact, I often fix the problem first, then refactor, then roll-back the fix just to add it again in a separate commit in the end (if the refactoring and the fix affect the same file, which also is often the case).
• jedberg 4y ago
  In the argument of monorepo vs not, the usual argument goes like this: - 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.
  • jupp0r 4y ago
    Mostly people who have this argument don't have a code base large enough to run into actual limitations of git. They run CI with wonky java implementations of git and/or have giant amounts of binaries in their repos. Actually having Gigabytes of source code is pretty rare.
    • pianoben 4y ago
      Or, they run in to limits with Github and mistake them for git limitations...
    • colonwqbang 4y ago
      It depends on the size of the company. The Linux kernel has about 1500 active developers. This is a lot, but many companies also exist that reach this size. 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.
    • maccard 4y ago
      > and/or have giant amounts of binaries in their repos. 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?"
• arxanas 4y ago
  To use a similar featureset but in the same Git repository you normally use, you can try my https://github.com/arxanas/git-branchless https://github.com/arxanas/git-branchless. Then, you can use your usual staging workflows if desired, or use regular Git commands directly. 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 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.
  • kbd 4y ago
    I'm glad you mentioned Jujutsu. Given that it's also a git-compatible SCM my first thought upon seeing this post was how Sapling and Jujutsu compare.
    • martinvonz 4y ago
      I think those two things that arxanas mentioned are the biggest differences (i.e. working-copy-as-commit and conflicts in commits). I haven't used Sapling, but I suspect Jujutsu has better support for moving commits (and parts of commits) around without touching the working copy. 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_L4bQ9NMcYOp1isn17kTC_M/edit#slide=id.g152b1fb8869_0_1432 https://docs.google.com/presentation/d/1F8j9_UOOSGUN9MvHxPZX..., recording: https://youtu.be/bx_LGilOuE4 https://youtu.be/bx_LGilOuE4).
      • martinvonz 4y ago
        Oh, in the context of Sapling, I should say that Jujutsu runs the equivalent of `sl restack` after every command. Thanks to first-class conflicts, that always works.
• dkasper 4y ago
  As a Meta employee for almost 4 years what I will say is I was skeptical at first coming from git, but the sapling system works very well in practice in my experience. I still use git for everything outside of work, but I may consider sapling now.
  • kridsdale2 4y ago
    I'm ex-Meta and now at Google and while they have 'hg' as a wrapper around their fig system, it's lacking so many of the Sapling features I am sad and frustrated occasionally.
  • optymizer 4y ago
    Can confirm. I like sapling better than git. Who needs branches? Why stress about detached heads? Working with a stack of commits is a breeze too. absorb split histedit uncommit unamend revert metaedit Once you use them, it's hard to go back.
• ArchOversight 4y ago
  I use the staging area to allow me to more easily break larger changes into smaller commits. I am usually all over the place while writing/refactoring code and making commits as I go along doesn't work well. 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.
  • arxanas 4y ago
    Instead of `git add -p`, you would use `sl commit -i` (whose interface I much prefer). To amend into a previous commit, I prefer to switch to it and then just use `sl amend` (+ `sl restack` if necessary), but you can also use `sl fold` IIRC. Instead of `git rebase -i`, you can use `sl histedit` (not a direct replacement for autosquashing, but worth mentioning). 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).
    • ArchOversight 4y ago
      If I switch to a previous commit to amend it, then I would temporarily lose all the other changes I made, and means I can't easily run tests on that particular commit to validate nothing else broke. 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 https://sapling-scm.com/docs/commands/fold This doesn't seem analogous to git rebase --autosquash which merges the mixup into the old commit.
• Dowwie 4y ago
  Would the team consider discussing the architecture of this system? Seems like a whole lot of Rust was used. I'm sure the team has a lot to share.
  • quark12 4y ago
    Yes. Right now we are adding more documents about how internal components (like the commit graph) work. We hope others in the industry find them useful. Feel free to ask questions in GitHub too.
• yumraj 4y ago
  I find it interesting that this is open sourced a few days after 11K were laid off. 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.
  • ak67 4y ago
    The open sourcing schedule was completely unrelated to the layoffs. 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.
  • boberoni 4y ago
    I doubt that the FB people involved with the layoffs are the same FB people who decided to open source the Sapling project. Many FB engineering managers were not aware that the layoffs were being planned. Moreover, it takes up-front planning and design decisions (by more than just a few days) for a private company to open source their internal projects.
• sequoia 4y ago
  Phabricator[0]: code review/CI solution from Facebook. My company uses it, open development has since been halted by Facebook and we're effectively on abandonware. 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/ https://www.phacility.com/phabricator/ 1: https://flow.org/ https://flow.org/
  • smeenai 4y ago
    Disclaimer: I work at Facebook. 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.
    • mitrandir77 4y ago
      Phabricator was opensourced by Facebook. But most of it life as an opensource product is was actively maintained by Phacility.
    • tomelliott 4y ago
      Pretty sure that isn’t true. If memory serves, Evan open sourced Phabricator at Facebook back in 2010 or 2011, then quit to work on it full time. Shortly after (months, years?) the internal version of Phabricator diverged from the now not FB managed or stewarded OSS one. However I think it is fair to say, assuming my memory is correct, that Phabricator was open sourced by Facebook at a very different time, before the company really committed to supporting open source projects. At that time it was more ‘if an individual engineer wanted to then go for it’ rather than there being any formal process or consideration of longer term commitments. That changed fairly shortly afterwards with the creation of the OSS team. I remember someone transitioning to the newly formed team and moving from Dublin to London to do so in ~2012, as we became housemates :)
• eisbaw 4y ago
  Major pain point of monorepos: Merge-conflicts. When a merge-conflict happens YOU need to be expert and resolve all conflicts the right way, across the many unrelated domains mixed together. 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.
  • matthews2 4y ago
    If you get a merge conflict in a piece of code, you must have touched that code. And if you were capable enough to modify the code to begin with, you should be able to solve a merge conflict around it.
  • mitrandir77 4y ago
    I don't see why merge conflicts would be a pain specific to monorepos. The merge conflict arises when you and some other person modify the same parts of the same file. No matter the repo size the correct solution here is figuring out the intention of the other person by reading their change or talking to them and deciding how to combine it with your change. The only reason which may make merge conflicts happen slightly more often in monorepo (vs constellation of small repos) is that not having the repo cloned locally is an obstacle to make the change. So some folks won't bother contributing repo that they'd have to clone first and instead they'd file a bug to the owners.
• conradludgate 4y ago
  The interactive tool looks amazing. I do interactive rebases quite often and a drag-drop setup is wonderful 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?
  • arxanas 4y ago
    Generally, you "stack" your commits/PRs and review them in small units (which I think is what you mean by working on something else without making any Git checkouts). 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).
  • juped 4y ago
    No, stacking is a (partial) workaround for Github "pull requests" being bad, by reimplementing the ordinary Git way to submit changes (one email per commit, reviewable inline. look at any patch thread at https://public-inbox.org/git/ https://public-inbox.org/git/). Doing this doesn't really make them good, but it makes them at least reviewable.
• msarnoff 4y ago
  Command name conflicts with the `sl` utility that has existed for decades. https://github.com/mtoyoda/sl https://github.com/mtoyoda/sl
  • thijser 4y ago
    "It's just a joke command, and not useful at all." with the last release 8 years ago. I understand that Meta didn't mind conflicting with that.
    • IshKebab 4y ago
      Doesn't matter. If anyone used a name at any point in time before you can never use it again. Apparently.
  • ajkjk 4y ago
    Seems fine.
  • Cedricgc 4y ago
    I'm sure Meta will rename their project to accommodate the choo-choo train
  • Kwpolska 4y ago
    I would be more concerned about the ease of mistyping `ls` as `sl`, especially if you tried to list a directory whose name is a destructive Sapling command.
• CPUTranslator 4y ago
  Neat! I hope this is a step in the right direction towards and not-so-bespoke SCM. 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)
• andrewmcwatters 4y ago
  The biggest disappointment here is surely a missed opportunity to shoehorn a git and sap joke into this release. The utility should obviously be called `sap' and not `sl'.
  • mzr4141 4y ago
    `sl` is in the home row ;)
  • thiht 4y ago
    > git and sap joke Non native here, could you explain? I know git is a slur and sap is the "tree blood", but are there other meanings I'm missing?
    • Maxious 4y ago
      alternative meaning "a foolish gullible person" https://www.merriam-webster.com/dictionary/sap https://www.merriam-webster.com/dictionary/sap
      • thiht 4y ago
        Thanks!
• durham_meta 4y ago
  Hi Hacker News! Author of the Sapling blog post here. I'm happy to answer any questions you might have.
  • thijser 4y ago
    The GitHub repo says that Mononoke and EdenFS is "not yet supported publicly". The code seems to be all in the open source repository though, what does the "not supported" mean here?
    • durham_meta 4y ago
      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.
      • wocram 4y ago
        'one day' is not very reassuring! Improved UX is nice and all, but why would anyone migrate without getting killer performance features like the virtual file system?
        • durham_meta 4y ago
          Sorry! 'one day' is the best I can do for now. We'd love to do it sooner, just gotta find the time. We think, and many of our internal users agree, that the UX alone is a worth while upgrade. Since the majority of Git repos don't actually need the performance of a virtual filesystem, the UX is the main sell for them anyway. At the very least maybe it will inspire some UX improvements in Git.
          • wocram 4y ago
            I don't doubt the UX is better, but internal users are a captive audience. I imagine most developers will not think twice about what vcs they are using unless their organization makes the change.
• stevage 4y ago
  Thank god. I have been waiting ten years (https://www.google.com/url?q=https://stevebennett.me/2012/02/24/10-things-i-hate-about-git 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.
  • bergheim 4y ago
    Admittedly this might not help since it is not CLI, but spend some time this weekend with Emacs and magit. You don't have to use emacs for anything else, just the magit client. It will transform your git experience.
    • stevage 4y ago
      I did something similar for years with Sublime and Gitsavvy. But I couldn't stop Sublime updating itself from time to time, and it kept breaking Gitsavvy, and it got really tedious to try to fix it.
  • waynesonfire 4y ago
    • somehnguy 4y ago
      Lol. Orrr we could just do things sensibly in the first place.
      • sixstringtheory 4y ago
        I always chuckle when things like “sensible”, “user-friendly” or “sane” get thrown around as if they are anything more than that person’s opinion. When are developers going to learn that they actually have to learn and familiarize themselves with preexisting systems, instead of endlessly reinventing them, and that there is no such thing as the perfect system?
• noamelf 4y ago
  Trying to use it on existing git repo doesn't work... At least not out of the box, I wonder why is that? Makes it less fun to work with as you can't easily switch
  • Shish2k 4y ago
    It needs its own client-side data, but it will work with existing git servers - so switching is as hard as running “(git|sl) clone https://github.com/… https://github.com/…"
• jordigh 4y ago
  Ah, there it is. I was wondering when this would happen. 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.
  • layer8 4y ago
    > I disagreed with the things that made Facebook fork off in the first place. Could you elaborate on what these things are and why you disagree with them?
    • ravi-delia 4y ago
      Presumably the things listed in the second paragraph (Phabricator, node hashes)
  • IshKebab 4y ago
    I was going to say that they already had started their own successor to Mercurial called Eden, but it seems like Sapling is just a renaming of Eden. Maybe anyway. It's a bit unclear.
• avgcorrection 4y ago
  Stack of commits seems to be similar to what one would call a patch queue if one is using Git. 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.
  • alwillis 4y ago
    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. You can thank the Mercurial developers for these concepts.
• difflens 4y ago
  Interesting execution. I'm not totally sold that Sapling is somehow forcing smaller/(more understandable) commits. Running Sapling restack with the manual step of an `amend` doesn't sound too different than running `git rebase -i` and moving the commits around. ReviewStack is interesting, but nothing new. It seems like it's removing the need to click through the commits page in GH by exposing it in a dropdown. IMO, the real improvement to our workflows will come from using better diff tools to make reviews more intuitive. I am biased of course :) (full disclosure: I work on DiffLens https://marketplace.visualstudio.com/items?itemName=DiffLens.difflens https://marketplace.visualstudio.com/items?itemName=DiffLens... )
• hgomersall 4y ago
  Does it support commit signing? I spent a while reading the website and couldn't find anything suggesting it does. Lack of that is a showstopper for me (and frankly, should be a showstopper for anyone).
  • alwillis 4y ago
    Yes: sl help sign
  • juped 4y ago
    Please stop signing commits
    • sixstringtheory 4y ago
      This is a new one for me. Why is it bad to sign commits?
  • elric 4y ago
    There is a distinct lack of decent identity management/security in all of the version control systems I've used. It's a hard problem to solve, especially in a distributed/decentralized system (like git). Signing git-style commits is problematic in the face of merge conflicts or rebasing. A patch-style system (like Pijul) probably makes this easier: if everything is a patch, every patch can be signed atomically. 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.
    • hgomersall 4y ago
      I don't see why the git way is problematic. It means someone is verifiably taking responsibility for all changes. That applies to conflicts and reading as much as normal commits. Edit: I'm not saying there's not a better way, just that I don't understand the problem with git.
• yuvadam 4y ago
  Yet another tool from Facebook that maybe serves their internal needs well, but is totally useless to anyone else.
  • deleted 4y ago
    [deleted]
• procrastinatus 4y ago
  I wonder what the folks at graphite.dev think about this announcement.
  • fragmede 4y ago
    they seem more focused on the code review part of the process, while this is more of a platform level change.
• loeg 4y ago
  FYI, as-shared at Meta: > First things first, please go to your phone and turn off wifi to avoid voter ring detection and upvote us on Hacker News!
  • alexb_ 4y ago
    Do you have any actual evidence of this, or is it a baseless accusation?
    • camdat 4y ago
      It's an internal post. Can confirm.
    • loeg 4y ago
      I didn't make it up, if that's what you're asking. Any Meta employee can confirm: fb.workplace.com/groups/scm.fyi/posts/2705323112933543
  • dilap 4y ago
    Good example of the "naughtiness" pg so prizes.
  • deleted 4y ago
    [deleted]
  • lenses2 4y ago
    Because people on the internal network are behind the same ip address(es)... This makes perfect sense to mention that while showcasing work. I'm not sure what are you insinuating.
• tkanarsky 4y ago
  This is simply unusable. If I type `sl`, I expect an animated choo-choo train to appear, not a newfangled Git client! /s :)
  • deleted 4y ago
    [deleted]
• mitrandir77 4y ago
  Nobody commented on the web interface yet which I think it's one of our coolest features: https://sapling-scm.com/docs/addons/isl https://sapling-scm.com/docs/addons/isl
  • stoicjumbotron 4y ago
    Woah! This really is cool!
  • kyrra 4y ago
    I'm sort of amazed that git and mercurial haven't built something like that yet. Makes me a little sad that Facebook created a new scm instead of expanding mercurial to include features like this.
    • alwillis 4y ago
      Facebook did contribute a lot to Mercurial back in the day; maybe not so much today. Yes, this would be awesome for Mercurial.
    • charcircuit 4y ago
      Sapling is a fork of Mercurial. It isn't a completely new scm.
    • ezst 4y ago
      just type `hg serve` and that will spin-up a web UI like this one: https://www.mercurial-scm.org/repo/hg/graph/tip https://www.mercurial-scm.org/repo/hg/graph/tip , seems to have been included since 2005 :)
      • kyrra 4y ago
        I don't think you can do commits from hg serve, can you?
        • ezst 4y ago
          I'm not aware that you can
• Sk012 4y ago
  Add Comment
• otikik 4y ago
  > At Meta Ah, dammit
• svnpenn 4y ago
  > Building the Sapling CLI requires Python 3.8, Rust, cmake, and OpenSSL for the main cli Rust and C? that sounds like it is a pain to build, especially on Windows.
• eukara 4y ago
  OpenBSD's Game of Trees is also an alternative that's git compatible, in case that hasn't been mentioned.
• chaxor 4y ago
  Nooooooooooo. Whatever is to come of my cute animations! [Think of the trains!](https://github.com/mtoyoda/sl https://github.com/mtoyoda/sl)
  • ultra_nick 4y ago
    Noooo!
  • emmelaich 4y ago
    Yep, you'd think `sp` would be a better choice.
    • computerfriend 4y ago
      "sap" would be ideal, as it's also in keeping with the theme of using mildly offensive names.
  • deleted 4y ago
    [deleted]
  • haunter 4y ago
    No markdown links on HN (thank god)
• emmelaich 4y ago
  Interesting choice of name for the command. Clashes with the treasured 'steam locomotive'!
• waynesonfire 4y ago
  I just cannot understand how a CTO approves this type of project. Imagine running a company and some engineer comes in and and says they want to develop a new source control system. I don't understand under what circumstances this is approved. Is it a pet project for a 10x engineer and it's allowed just to keep them on board? 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.
  • hu3 4y ago
    > The reason it's being open-sourced, unsurprisingly, is because Meta considers it tech debt. I understand the sentiment and my suspicion is similar. Do you have a source?
  • Macha 4y ago
    I think projects like this happen at two extremes of company size. Small companies, where the team is a few engineers empowered to do whatever without having to justify to "adult supervision", and megacorps where there is actually a team, with engineers assigned, who's job is something super specific like "manage our source control"
  • reissbaker 4y ago
    The simple reason is that Mercurial and git were way too slow for large repos, and FB wanted a monorepo for productivity reasons. It's cheaper to fund this project than reduce engineering productivity by even 1% at the scale of FB. 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.
    • astrange 4y ago
      Just as "inventing your own source control system" is a hobby, "being a very large engineering organization" is a hobby. FB and Google started with infinite money spigots and used it to hire a lot of people who make a lot of commits; if you laid them off, or if you canceled half the remaining Google products they haven't already canceled, not all that much would change.
• dcow 4y ago
  What exactly does “git compatible” mean? I may have missed it, but didn't see it skimming the post.
  • arxanas 4y ago
    You can push and pull directly from Git repositories, without resorting to some kind of tedious intermediate conversion step. Note that they don't support co-locating in the same repository at present, i.e. running both `sl` and `git` commands in the same directory.
  • MrWiffles 4y ago
    I’d like more detail on this too. I’m interpreting this to mean that anything you can do with git, you can do with sl, but I wonder what limitations exist for that. There have got to be some, somewhere along the way. Even just edge cases! Is it as simple as swapping ‘sl’ for ‘git’ in your terminal and workflow and nothing else changes? Surely not…
    • guytv 4y ago
      You `clone` your git repository into Sapling. You can then only use the sapling tooling (CLI) until you `push` to GitHub. You can't use `sl` and `git` or git GUI/ IDE plugins on the `sl` clone.
• rco8786 4y ago
  Nice. I've been pondering something like this for a while but lack the time (and frankly, expertise) to attempt it.
• crossroadsguy 4y ago
  How I wish there was a company that did something similar to monstrosity Android development abd build tools are. Nonetheless it’s an excellent news. While I won’t call it a monstrosity Git was so untenable and obtuse that I only used it because everybody else used it.
  • deleted 4y ago
    [deleted]
• LoganDark 4y ago
  > When used with our Sapling-compatible server and virtual file system (we hope to open-source these in the future) 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.
  • charcircuit 4y ago
    The source is already available in the eden/mononoke and eden/fs directories and are licensed under the GPLv2.
    • LoganDark 4y ago
      Hm? GPLv2 sounds like open-source to me - unless the OSI hasn't approved GPLv2 (they did[0] approve GPLv3). Is the article simply out of date? [0]: https://opensource.org/node/193 https://opensource.org/node/193
• krick 4y ago
  I'm kinda surprised by the excitement it gets. I'm still looking for a compelling explanation, why I (or anyone else) should even bother? 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.
  • WookieRushing 4y ago
    Its like Fish shell vs Bash shell. 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.
• didibus 4y ago
  I'm a little confused, is it a client compatible with Git? So I can use this for a git repo? Or is it a new DVCS, with its own repo type, for which I can use the git client for?
• lolive 4y ago
  I am a bit lost. Most of the discussions seem to focus on micromanagement of commits in your local HEAD branch. 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 ?
  • neandrake 4y ago
    I've worked with Mercurial repos for 10+ years and only recently we've been migrating some of the smaller repos to Git primarily due to better supported tooling. Mercurial has done a great job in specific workflows especially with phases (which not everyone adopts) -- by default they disallow modifying public commits but allow modifying draft commits. I don't believe Git really has a similar concept, or at least not integrated at the same level. I recently read about `git push --force-if-includes` which seems like it's trying to address similar situations but mostly guessing based on comparing changesets present between two repos. 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.
  • arxanas 4y ago
    Generally speaking, they simply don't use multiple branches on the central server. See https://trunkbaseddevelopment.com/ https://trunkbaseddevelopment.com/
• didip 4y ago
  How do you build this? The code structure looks different than a normal Rust project.
• xyzzy_plugh 4y ago
  This serves a very weird niche. Reading through the docs, this seems just as complex to operate as git, but designed with less decentralized operations in mind. Why not just use mercurial if you want to use mercurial? Why invent this... monstrosity? Because GitHub pull requests are terrible? 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.
  • arxanas 4y ago
    A lot of the important work is on back-end scaling for a centralized repository. Example: the segmented changelog allows answering merge-base queries in ~O(log n) time and very quickly in practice; these queries need to happen all the time as part of handling merges on the server-side. You get the front-end, a streamlined interface derived from Mercurial, for "free" as part of the open-sourcing.
    • xyzzy_plugh 4y ago
      But this centralized repository isn't available yet, so I cannot evaluate it. And the problems you describe aren't really relevant outside a monorepo or low-volume repositories, of which the vast majority of open source code falls in. I much prefer the ability to clone an entire repository and be able to make changes in a distributed manner. If this is for companies who aspire to have Google or Meta scale problems then this sure is a weird way to advertise it.
  • deleted 4y ago
    [deleted]
  • sfink 4y ago
    > Why not just use mercurial if you want to use mercurial? Why invent this... monstrosity? 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.
• jaja_00hck 4y ago
  Idk
• zelphirkalt 4y ago
  Looks like the typical FB thing to do. Latch on to some popular tech like git and try to sell it as innovative or "better" gathering the fanboys. After a few years the marketing hype will blow over and we will either have lots of misinformed newbies, who got into dev work on FB products. Just like we have today lots of web devs able to throw together any react widget you want, but unable to gradp when simple server side templating in any web framework would have been sufficient. Hammer. Nail. 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.
• ackatz 4y ago
  Does anyone know if this could work with pre-commits? I did some initial searching but haven't found anything conclusive.
• GoOnThenDoTell 4y ago
  Seems like it just the client component for now
• Ransom_ 4y ago
  It's interesting to see more people embracing the patch-stack workflow! For those interested in using the patch-stack workflow, but not ready to change to sapling, git patch stack would be worth checking out. https://git-ps.sh/ https://git-ps.sh/
• devd00d 4y ago
  Did anybody ask for a new git? And if they did, of all the entities in the world, why would Facebook be the guys we trust with that? It's already hard trusting Github.com.
• jbverschoor 4y ago
  I guess github is kind of bound to git for hosting :-)
• crest 4y ago
  Package conflict on /usr/bin/sl between sapling and sl.
• esjeon 4y ago
  The UI sounds much better than git. (but what can be worse than git in the first place?!) It's solving (or trying to solve) many common griefs of git. I don't like Meta, but I find myself enjoying the design itself. 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.
• overlisted 4y ago
  Their CLI is going to interfere with the other `sl` command: https://github.com/mtoyoda/sl https://github.com/mtoyoda/sl
• apex_sloth 4y ago
  Could this be a replacement for git-annex? I'm using git-annex for a while, but its slow and has some quirks. I would love to use version control on my whole home dir and sync different computers with it. https://git-annex.branchable.com/ https://git-annex.branchable.com/
• natovan 4y ago
  Cloned my repo with 'sl clone url', cd'ed to it, then 'sl status' and it doesn't recognize it as a repository. So much for git killer
• pgt 4y ago
  Pijul: https://pijul.org/model/#implicit-branching https://pijul.org/model/#implicit-branching
• AtNightWeCode 4y ago
  I will for sure try this. Looks great! I think the design of GIT still is a big risk for commercial companies.
• eatbitseveryday 4y ago
  Not sure if anyone has tried this yet... but the example tutorial does not work. $ sl clone https://github.com/facebook/sapling $ cd sapling $ sl @ fafe18a24 23 minutes ago ricglz remote/main │ migrate packer to new CLI framework ~ From [0] under "Cloning your first repo". I get the following: ~/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) Hopefully this does not assume we are authenticating with GH just to clone and see sl operating? [0] https://sapling-scm.com/docs/introduction/getting-started/ https://sapling-scm.com/docs/introduction/getting-started/
• throwoutway 4y ago
  I'm confused. Can you use Git with this new client, or do I need the Sapling source control too?