> At Meta
Ah, dammit
Sapling: A new source control system with Git-compatible client
201–210 of 543 posts
Re: Sapling: A new source control system with Git-compatible client
#202Thank god. 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 dis…
Quoted post unavailable.
GitHub’s success was in part due to it making Git interface’s bareable. Imagine an UX so bad it generates a whole industry.
Re: Sapling: A new source control system with Git-compatible client
#203Ah, 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 fro…
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.
From the build instructions for sapling: "It can be built by running make oss in the eden/scm directory"
Re: Sapling: A new source control system with Git-compatible client
#204To use a similar featureset but in the same Git repository you normally use, you can try my 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, suc…
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.
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..., recording: https://youtu.be/bx_LGilOuE4).
Re: Sapling: A new source control system with Git-compatible client
#205Hi Hacker News! Author of the Sapling blog post here. I'm happy to answer any questions you might have.
Looks like you are using clap v2? Feel free to ping me for help on moving to v3 then v4. I expect the rate of breaking changes to be slowing down and to be smaller in scope (from the users perspective) so now is a good time. Id love to hear how we can make clap better fit cases like this and how we can help in improving the UX of applications.
Re: Sapling: A new source control system with Git-compatible client
#206This 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.
If they deliver the virtual filesystem and server, this will be 10x better for large companies and large organized FOSS teams, who very often hit Git's pain points with relative ease, and the compatibility with Git from the client side means it has very easy onboarding for new users to get their feet wet. I've struggled with all these to varying degrees at almost every job and (non-solo) FOSS project I've been in; I've long wished for something like what's described here many, many times.
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.
Re: Sapling: A new source control system with Git-compatible client
#207Earlier quoted context omitted.
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.
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'r…
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.
Re: Sapling: A new source control system with Git-compatible client
#208> 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.
Re: Sapling: A new source control system with Git-compatible client
#209Thank god. 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 dis…
Forget the CLI. VSCode implements a ton of git features as commands, which can be bound to any keybindings. For me this is way faster than CLI, as I don’t even need to leave my text editor - I have it set up chorded, so AltG followed by P,U,C,Y, will push (actually sync), pull, commit, undo, respectively. Two keystrokes beats any CLI interaction I’ve seen. (Disclaimer used to make VSCode)
because doing a commit with one keystroke is a good thing? i think it isn't - i like to consider things, rather than program like a hyperactive cockroach
Re: Sapling: A new source control system with Git-compatible client
#210Thank god. 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 dis…
before building a new git, there just could be a new git command, i do not know like, undo for example.
just they build one for switch.
i hope they build a migrate one, where you can switch to new/other hashing standards.