Ask HN: Git Alternatives – Sapling vs. Jj

[koch]

Having worked at Google I have unfortunately been exposed to what is possible when in comes to version control systems. I have been looking for a git alternative that is just generally simpler, more ergonomic, and allows for things like stacked PRs while maintaining git compatibility, since everything is on github.

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

My main contenders right now are Sapling[0], a project from Meta, and jj[1]. I am wondering if anyone has experience with either, or definitely those who have tried both, what was your experience? They both have a lot of nice features.

[0] https://sapling-scm.com/ [1] https://github.com/martinvonz/jj/blob/main/docs/sapling-comparison.md

[IshKebab]

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.

[aseipp]

The command line interface for Sapling called `sl`, which is Git compatible, is fully supported by the team at Meta. You can file bugs and feature requests, etc, though the repository is a bit intimidating. It is only the non-Git server components (Mononoke, EdenFS) that are not yet really supported [1] but I think most people aren't really concerned with that, when writing a post like this.

For all intents and purposes, Sapling works very well, I think, and in some places it has a lot more polish, like the "isl" graphical interface, which makes things like rebasing and restacking incredibly intuitive even for new users. (I consider isl to be a significant advantage over Jujutsu, and I say that as a Jujutsu developer!)

[1] Though, Mononoke does support features like exporting Git repositories to remote hosts from the internal model; that's not really what people are looking for in a lot of cases though.

[WorldMaker]

Pijul's "upstream" (and git predecessor) darcs is still useful today. It doesn't see itself as a "research prototype" and has decades of experience in the real world. It isn't git compatible but does offer a fine fast-export to git in the worst case you need to switch.

Unfortunately some of those decades of experience with darcs are lessons in how it performs poorly in large repos or with large teams/lots of merge conflicts, but that still leaves darcs a good experience for small projects and "just getting stuff done".

[Zambyte]

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.

[neongreen]

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.

[jkachmar]

have you experienced particularly slow pushes with large repositories at all, and if so were you able to resolve them?

I did some profiling & it looks like the issue lies with `libgit2`, but I haven’t been able to replicate the issue outside of that work codebase[0].

[0]: https://github.com/martinvonz/jj/issues/1841#issuecomment-23...

[mk12]

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.

[eawgewag]

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.

[Zambyte]

I have never really made bisect a part of my workflow, but something I believe would work well with just jj is making two workspaces before and after the issue, and iteratively walking their working revisions toward each other. That has the advantage of being able to run both versions simultaneously easily.

[bsimpson]

This is a nice reminder for me to check it out.

I've liked Phabricator, and Google's internal variant of Mercurial in the past (and have always despised GitHub's PR=branch model). Sounds like Jujutsu might be right up my alley.

[ghjfrdghibt]

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.

[hinkley]

It comes up a lot in split repos or split deployments.

To make a change you need to deploy part of it here, then another part over there, and maybe fiddle with some settings in between.

So your story ends up with several PRs that have to land in a specific order or things break. Eg client calling a new endpoint that doesn’t exist yet.

We call these chains of dependent reviews “stacked” for reasons I’m not entirely clear on.

[keybored]

Stacked PRs is GitHub users (or Phabricator) reinventing commits as pull requests.

[barlog]

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

[ksec]

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?

[dijit]

Hackernews has a “second chance pool”, where the mods decide to reignite topics where they feel there was no enough deserved attention.

Or… it was just resubmitted.

[OJFord]

Do you mean the link stopped working, or just that it fell off the front page(s)? It was probably second-chance pooled, iirc that resets the submission date. Timing is a factor in submissions' success, they don't necessarily get the right eyeballs to get upvotes & attention before more else comes along.

[mhh__]

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.

[riwsky]

For what it’s worth, the main developer of git-branchless is also a `jj` contributor

[riedel]

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

[xrd]

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.

[ibejoeb]

I use jj and zed. More appropriately, I happen to use jj and I also happen use zed, and I never really think about them together. All repo-level work I do with the cli. The only thing I really care about in-editor is recency on a line level, and since jj uses git, zed has no problem showing line-level metadata. There is a slight difference because of jj's stage consolidation, but I don't find that to be a problem, since there's not much of a difference between a line in a staged file vs a line in the working tree.

[rk06]

I use git gui (git extensions) so I don't know bother with cli unless I have to

[eawgewag]

I'll use JJ through an integrated terminal in my editor

[Lanedo]

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)

[drcongo]

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

[HALtheWise]

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

[arxanas]

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.

[SatvikBeri]

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.

[EddieRingle]

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

[aseipp]

It's a fair question, but the answer is simple: because there are significant design choices in the UX and algorithms which are user visible, and percolate throughout the entire system design, which can't just be wrapped or alias'd away.

There is git-branchless, which is kind of like this[1][2] and is something like a half-way point between Git and Jujutsu/Sapling. However, it needs to be stated that git branchless does NOT just "wrap" existing things or alias them. It has significant engineering to add features, using a lot of code, because you can't "just" add things like revsets or 'undo' using wrappers or aliases, at least not in an efficient way.

Some examples from Jujutsu are that:

A) jj rebase is lightning fast compared to git rebase, because it works in memory. Git rebase touches disk for all operations, so it becomes slower the larger the repo, the more history, the bigger the files etc you have. You may spend significant IOPS moving large-ish files around, flushing the index to disk, and so forth; and you also cannot do things like rebase inside a bare repository (imagine you want a handy "Rebase branch on main" button in your GUI -- you need to have the whole working copy to do that!) jj rebase works entirely in memory so it never touches the disk for any files in the commits themselves. This is called "git move" in git-branchless, but requires significant code. Git itself is trying to solve this with a new "git replay" command, but it is extremely new and has some current limitations compared to, say, Jujutsu, IIRC. (But the fact they have to add a whole new command with significant code is a good example of how the algorithmic differences matter and can't be papered over.)

B) Revsets are a non-trivial addition to make the commit graph "queryable", but they add open ended features in a way that can't easily be recreated without them, because they are composable. For example, "list all commits authored by me that are not merged into main that can be rebased on main" is written as `all:mutable() & mine()`, but to recreate this level of flexibility you would need a dozen one-off features added to something like 'git log' -- but these revsets can work with many more commands than log! You can use the above revset to automatically rebase all your open branches at once for example, which is not possible in Git without shell scripting (what about Windows users?) and duct-taping stuff. But then where's the reuse?

C) Jujutsu has a notion of first-class conflicts, which can only be vaguely approximated with something like `git rerere` and `git rebase --update-refs`, but this isn't quite the same because for example you need to know details like purging the rerere cache if you get a conflict resolution wrong and want to undo it and start over, not to mention you can still easily screw things up mid-way with `git rebase` in a form that requires you to start over. These "catches" do not apply to Jujutsu and I have no idea where you would even begin if you wanted to add a feature like this.

So, the details matter a lot in practice for users, and delivering them a good experience is something that I think is way more difficult than just a bunch of opinionated commands. To be clear, if you like opinionated aliases and wrappers, that's OK! But there's a lot more underneath the surface if you scratch at it a bit.

[1] https://github.com/arxanas/git-branchless

[2] The main developer of git-branchless also is a Jujutsu contributor, so these ideas and the implementations aren't totally a coincidence!

[lawn]

You mean how jujutsu uses the same git repo and you can use jj while other people you collaborate use git?

Yeah they're doing that.

[Flux159]

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.

[brudgers]

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.

[aseipp]

Both Sapling and Jujutsu are compatible with Git repositories, and there are even settings to have the `.git` directory exposed so that all of your existing tools will be able to run Git commands, show hunk changes in the gutter, etc. For all intents and purposes, you can use them in place of or alongside Git, and none of your colleagues will really need to know. This is a significant advantage over competing non-Git systems, and one of the major selling points that incentivize people to even try it at all.

If it means anything, I have been using Git for 15 years and am one of the earliest GitHub users, and I have not regularly used Git for nearly anything, in any job, for over ~1.5 years now. (Disclosure: I am also one of the Jujutsu developers though, so take that for what it is.)

[Conscat]

Not to dissuade people from looking into alternatives, but the high quality integration that Git has with every single code editor in wide use today is a huge advantage over every other VCS imo. As far as I can tell, the closest to it in that regard is Subversion, but it's not all that close. One of my friends is getting into Plastic SCM, for fair reasons, but Plastic doesn't have a UI as fun as Magit.

[keybored]

Genuinely what’s the big deal? I used Git as a frontend to a Subversion remote because that’s what “IT” had. Any decent Git contender (read: worthy early adopting) will have the same capability.

Right now both Git power users and Git anti-users (minimum care) cooperate on the same code. Some making fantastic Git histories (or yak shaving with rebase too hard) and some doing “backup for the dayy”.

Maybe one of them is even using Jujutsu behind the scenes. Who knows? Ahh, maybe that’s why he has forgotten that one switch to git-rebase that you need two times a quarter.

You don’t need any momentum or organization backing or people in your corner in order to start trying out a Git alternative.

[johnisgood]

Opinion on Darcs or Pijul?

[aseipp]

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.

[lostdog]

It sounds so nice! Sadly, $work uses git LFS, so neither is a possibility for me.

[optymizer]

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.

[findjashua]

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

[remram]

Can you say something about it rather than just dumping the link? :)

[keybored]

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