from Hacker News

Ask HN: Git Alternatives – Sapling vs. Jj

by koch on 12/7/24, 5:57 PM with 64 comments

• by IshKebab on 12/10/24, 5:41 PM

  There's also Pijul. I have only had a brief play with Jujutsu and I haven't tried Sapling but from what I can see, Jujutsu is definitely the best option if you want to actually get stuff done while mostly maintaining Git compatibility.

  Pijul is definitely still in the research prototype phase, and definitely not Git compatible. I don't know how Git compatible Sapling is, but large parts of it are still labelled "Not yet supported publicly, OSS is buildable for unsupported experimentation." It also feels like a VCS that was designed for Facebook and then open sourced, so it is targeted at the use case of "massive company monorepo, and we have 10 guys that run the infra". That's great, because Git is bad at that use case, but it might not be what you want.

• by Zambyte on 12/10/24, 6:03 PM

  Jujutsu replaced git for me in February of this year, except for managing tags, which I reach for the git cli for in my colocated repositories. I find it is much easier for me to create a sensible set of revisions that linearly approach my desired state for the working directory, even if I did not linearly arrive there.

  I also use features of jj that are not available in git all the time, like rebase -s (rebase a tree from the root), split (turn one revision into two), absorb (cascade changes into a stack of revisions where the lines were last modified), etc.

  Given how stable git is as a repo format, I find it unlikely that I will ever go back.

• by neongreen on 12/10/24, 9:56 PM

  At work I’ve been using jj for the internal Standard Chartered monorepo (6.5 MLOC). I didn’t ask anyone, just installed and started using it. Git compatibility is a killer feature.

  (if anyone from SC is reading this -- search our wiki for "Jujutsu" and come say hi!)

  Pretty much a strictly better experience than git so far — I’m not going back. `jj undo` is something that I expect in every program now and get vaguely annoyed it's not there.

  Not having index/staging is great. Checking out another branch, switching to work on another thing, fixing a typo in an unrelated module, etc are all frictionless. "I'll insert a new commit five-commits-ago, do the refactoring there, and resolve conflicts" turns out to be much nicer than "I'll do the refactoring here and carefully stage it hunk-by-hunk". (I get distracted a lot -- maybe if you aren't tempted by shiny refactorings, this isn't a big deal for you.)

  The merge story is also great. I have a commit with multiple parents. I can add more parents to it, change parents, rebase it somewhere, move it around. I have no idea how "rebasing a merge" works in git, but I'm afraid to try. In jj I don't care.

  There are a few issues with jj that happen to not be a big deal for me, but I can imagine they could be a dealbreaker for someone else:

  - No submodules support (yet)

  - No LFS support (yet?)

  - Doesn't track renames (yet?)

  - When you do `git pull` with rebase, git skips duplicate commits -- this is great if something got rebased/amended on the remote. I was always suspicious that `git pull` just works even if I rebased the branch remotely, and now I know why it works. jj doesn't handle this yet. Not a big deal unless two people collaborate on a branch and want to do it the jj-way with rebases of everything.

• by mk12 on 12/10/24, 9:54 PM

  I just started a new job where I’m collaborating with the maintainers of mercurial, and was asking them about these alternative VCSs last night. It was interesting to learn that all these people are in contact with each other and there’s a lot of cross pollination of ideas. And for some newer ideas e.g. in jj and pijul, where just reading the website would have me 100% sold, they had more nuanced takes on the pros and cons. So I feel less confident in giving advice than I would have a few days ago. But if you need seamless git compatibility, I’ve personally found git-branchless to be the best solution for the requirements you listed as a thin layer over git. I also tried jj a while back and I liked it but I found being further removed from git made it harder to drop down into regular git when I needed to. In particular I had issues with jj log showing lots of irrelevant commits but that was probably because of our particular Gerrit setup and might have been fixed by now.

• by eawgewag on 12/10/24, 6:15 PM

  JJ is incredible. Highly recommend it. I can't put into words what a game changer it is for my workflow.

  The only thing I reach for for git now is `bisect` when I need to debug an oncall issue.

• by ghjfrdghibt on 12/10/24, 7:14 PM

  I like fossil. Much prefer it to git. No idea what stacked PRs are but it's compatible with git and way simpler in my opinion. Plus comes with some nice extras like tickets, wiki, UI.

• by barlog on 12/8/24, 12:57 AM

  [1]: <https://github.com/martinvonz/jj/blob/main/docs/sapling-comp...>

• by ksec on 12/10/24, 5:36 PM

  Off topic. I saw this thread the other day and thought it will be an interesting topic. But then it dropped off and disappeared. I doubled checked the topic was 2 days ago but now it reappeared as 2 hours ago. Anyone knows why?

• by mhh__ on 12/10/24, 6:19 PM

  I have been using `git-branchless` a lot and really liking it. It should be part of the main git project, consider it a halfway between git and switching to some other tool.

• by riedel on 12/10/24, 5:24 PM

  Lots of discussion on this jj post: https://news.ycombinator.com/item?id=36952796

• by xrd on 12/10/24, 6:36 PM

  A question: I prefer jumping into the command line for most of my git work. But, I'm intrigued by this discussion and wonder: how well do these tools work within an editor? I am using Zed, which IMHO has poor git support anyway. I'm curious if the experiences here are mostly from people who do not use their editor as their main point of contact with the code repository they are working on.

• by Lanedo on 12/10/24, 9:16 PM

  For a quick impression, the jj-fzf README has a number of screencasts that showcase tasks easily accomplished with jj (using fzf to preview the jj log and key bindings to invoke jj commands):

  https://github.com/tim-janik/jj-fzf?tab=readme-ov-file#split...

  (Another self-promotion)

• by drcongo on 12/10/24, 5:23 PM

  I tried jj recently based on a sub-thread here on HN, have to say I did really like it, but still came away feeling like it was going to take a lot to train the muscle memory away from git.

  Edit: Here's that sub-thread: https://news.ycombinator.com/item?id=42112574

• by HALtheWise on 12/10/24, 9:21 PM

  If you're looking for a polished way to manage a stacked-PRs workflow with git and GitHub, I highly recommend Revup. It was invented at Skydio when I worked there, and quickly developed a cult following among engineers there. I wouldn't describe it as simpler than default git, especially since you still mostly use git commands (like rebase -i) for lots of tasks, but for power users it provides a really nice workflow.

  https://github.com/Skydio/revup

• by arxanas on 12/10/24, 9:33 PM

  For me, the most interesting differentiating factor at this point is probably the GUI tooling for Sapling. Try out their "interactive smartlog" and see if it resonates with you.

• by SatvikBeri on 12/10/24, 8:52 PM

  I switched to jj about a month ago and love it.

  Broadly speaking, commits in git represent two conflicting ideas – a mechanical representation of the state of the codebase, and a logical series of changes for bisecting and human readability. It's possible to manage this in git, but painful.

  In jj, these two concepts are separated – you have Revisions which represent the mechanical state, and are saved every time you run any command, even `jj status`. And you have Changes, which represent the human readable stuff, and can be edited at any time. This makes it really easy to save lots of snapshots, while carefully crafting your Changes for a readable history.

  I was surprised at how easy it was to adapt to jj. It didn't feel like I had to learn a lot of stuff or a big new mental model, it turns out to just be pretty simple to craft the Changes at any point I please.

• by EddieRingle on 12/10/24, 6:03 PM

  > I am uninterested in `you can do that in git with [insert esoteric commands]`.

  Why? If the only requirements you specified are that you're looking for something that is compatible with Git but with better ergonomics, wouldn't something that wraps Git (whether that's via aliases or something more comprehensive) fit the bill?

• by Flux159 on 12/10/24, 8:06 PM

  I've been using Sapling along with the VSCode extension for ISL which mostly gets me a better workflow with diff stacks locally (Github isn't great dealing with stacks though).

  The only major limitation for me is git-lfs support so for certain repos I have to revert to git.

• by brudgers on 12/9/24, 7:40 PM

  Documentation, training, and relative ease of acquisition and installation are properties of the git ecosystem that are hard to replicate outside of an organization with a business case like Google.

  That's the setup for: Who are the intended users and in what context will they use it?

  If it's just you or you and your employees, selling no github can be straightforward. If it's your boss and some other teams, it's gonna be harder. Good luck.

• by johnisgood on 12/10/24, 7:04 PM

  Opinion on Darcs or Pijul?

• by aseipp on 12/10/24, 6:18 PM

  I've used both quite a bit, first Sapling and then Jujutsu, and now I exclusively use Jujutsu and am one of the developers. I previously used Git almost every day for ~15 years. Frankly, I think you'll be very happy with either of them; they are pretty much straight upgrades from Git in most ways. Some notes (random, non-exhaustive):

  Both of them are heavily Mercurial inspired; Sapling is a heavily evolved fork of Mercurial, while Jujutsu was strongly inspired by many of its concepts but shares no code (the two main developers, Yuya Nishihara and Martin von Zweigbergk, are former heavy hitting Mercurial developers.) They support features like revsets, filesets, have a notion of "changeset evolution" built into their internal models, and more.

  These features actually make it possible to do things in an "open ended way" that would be difficult or not-possible to do in Git; something like finding all commits with 'description(foo) & author(aseipp)' for instance is not something I'm sure you can do in Git in a one-off way, as a counterexample to the "just run this command in Git to do that!" argument.

  Both of them have a significantly simpler conceptual model because they replace concepts like "stashes" or "the staging area" with commits. To be clear: you can do all the things you like with Git, but with less conceptual overhead. There are fewer "nouns", and consequently fewer "verbs" you need to use and memorize.

  They also don't tend to muddle a bunch of stuff together under one name; rebase is just rebase, not "rebase and edit commit message and reorder and throw away commits and merge commits and ..." like in Git. Or consider `git revert` and the dozen options that make it work on this-or-that. This and the previous point mean their UX is also much smaller than Git, a bit more clean and well separated, etc.

  Jujutsu has an even further simplified model because it doesn't even have a concept of things like "the working copy." Everything is a commit. This has a large list of downstream consequences on things like performance (jj rebase is vastly more efficient than git rebase), internal design choices, etc but the takeaway is that you have an even simpler cognitive model. The flipside, I think, is that Jujutsu might take slightly longer to "internalize."

  Both of them have the ability to expose the `.git` directory next to their own VCS directories (.sl and .jj) so your existing tools like showing status lines in the editor gutter can work. Jujutsu calls this "colocation", and Sapling calls it "dotgit" mode. Sapling's "dotgit" mode is still experimental; Jujutsu's colocation mode is well supported, and likely to become the default in the near future.

  Both of them have 'undo' commands. Imagine that! A command that can undo your mistakes! Users are almost always universally filled with joy when they discover this feature.

  Both make workflows like stacking or rebasing a lot easier, conceptually, so you will probably be happier with either. Sapling has ReviewStack so you can do stacked reviews a bit more clearly on GitHub. For Jujutsu we don't integrate with ReviewStack, or Reviewable/Graphite (yet), so you are still at the mercy of Github's review tools, which are a bit weak when it comes to interdiffs/stacked PRs.

  Sapling has a command called "interactive sapling" or "isl" which is a web-browser based GUI that you can use to drag and drop, reorganize, split, restack commits with ease. isl is an incredible tool, it is easy to use even for newcomers, and I consider it a major advantage over Jujutsu!

  Jujutsu has the notion of "first class conflicts" which make most forms of conflict resolution far easier. It's a bit difficult to explain but think of `git rerere` combined with `git rebase --update-refs`, but on steroids. I consider this to be a major advantage over Sapling.

  Sapling is the VCS of choice at Meta, and they are working on making the scalable server-side components available too. Jujutsu is designated to (hopefully) become the true successor to 'fig' at Google, which I suspect you're familiar with. Maybe this matters to you as a former Googler, but maybe not. (Note: I do not and have never worked at Google, but Martin does and is the leader of this effort.)

  Jujutsu actually exposes a set of APIs so you could in theory use it with other backends; that is how the Piper/CitC integration at Google works, and people have floated ideas like a Mercurial backend, for instance. In theory it is extensible, but this might not matter to you.

  Jujutsu is a pure Rust codebase, having been written from scratch, while Sapling has a much longer history; it is a mix of Python and Rust. I personally think this makes it much easier to contribute to Jujutsu, and it was one of the reasons I switched because I personally tend to write patches for tools I use. OTOH, Sapling is much more refined in some ways. It is up to you if you think this matters.

  Compatibility-wise, I believe Sapling uses `git` commands underneath to drive a lot of its features, while Jujutsu instead uses libgit2/gitoxide for interop. IMO, libgit2 has caused us and users a few issues long-tail issues that are hard to resolve; things like Git Credential Manager or OpenSSH config support for instance don't work as well with libgit2, which causes annoying bugs. Other features like partial clones don't work (shallow clones do.) You can just use `git` commands to work around this, typically, but I think Sapling might handle some of these quite a bit better.

  In short, I think you'll probably be happy with either of them. If you have any questions about Jujutsu at least, you can open them on GitHub, Discord, IRC, etc.

• by optymizer on 12/10/24, 8:47 PM

  I learnt Sapling while at Meta. I was skeptical when someone said "it's better than git" but then I used it and I will in turn now say that it's indeed better than git. At the very least it doesn't yell at you for not being on a branch and losing code, but it has easy commands for working with a source tree and working with diff stacks. I haven't used it outside Meta's infrastructure though.

• by findjashua on 12/10/24, 9:11 PM

  Shameless self-promotion: https://pypi.org/project/stacksmith/

• by keybored on 12/10/24, 7:44 PM

  > Having worked at Google I have unfortunately been exposed to what is possible when in comes to version control systems.

  Do you also drink your tea by sticking your pinky out?