{"slug": "jujutsu", "name": "Jujutsu", "category": "git", "category_name": "Git and code hosting", "description": "Git-compatible version control system that treats the working copy as a commit.", "recommenders": 56, "commenters": 70, "warners": 1, "score": 52.365, "rising": 2.25, "first": "2025-11-03", "latest": "2026-10-25", "why": "HN commenters like Jujutsu for easy history editing with squash, split, rebase and undo, for treating the working copy as a commit instead of a staging area, and for working inside existing Git repos without coworkers having to switch.", "why_is_quote": false, "has_verdict": true, "sentiment": {"recommend": 63, "neutral": 12, "compare": 3, "warn": 1}, "spark": [1, 3, 2, 3, 3, 13, 4, 8, 10, 3, 12, 1], "listed": true, "loved": ["Git compatibility", "History editing"], "caveat": "GitHub team workflows", "short_quote": "I recently switched to Jujutsu (jj) and it made me realize that \u201cwhat comes after Git\u201d might already exist.", "icon": true, "domain": null, "github_repo": "github.com/jj-vcs/jj", "official_url": "https://github.com/jj-vcs/jj", "pricing": "open source", "aliases": ["Jujutsu", "jj", "jujutsu"], "verdict": [{"text": "HN commenters like Jujutsu for easy history editing with squash, split, rebase and undo,", "cites": [{"id": 792483760, "item_id": 49530235, "url": "https://news.ycombinator.com/item?id=49530235", "by": "dcre", "date": "2026-09-02", "stance": "recommend", "quote": "shuffling commits around with squash, split, and rebase is much better than git\u2019s interactive rebase", "excerpt": "A few advantages for me, even for the same 5 commands I use over and over: - undo - shuffling commits around with squash, split, and rebase is much better than git\u2019s interactive rebase - make commits without having to come up with a branch name (I might make three versions of the same change in parallel to see how they compare) I see git is working on adding some of this under the history command. The revset language", "context": "", "use_case": "version control", "switched_from": "Git", "story": "The creator of Jujutsu has joined ERSC"}, {"id": 792479792, "item_id": 49529987, "url": "https://news.ycombinator.com/item?id=49529987", "by": "y1n0", "date": "2026-09-01", "stance": "recommend", "quote": "JJ is just so low friction.", "excerpt": "I was a skeptic until a few months ago. It\u2019s my daily driver now. I\u2019ve got sizable amount of people committing to the same repo, many are not skilled with git. So I deal with weird crazy \u201chow did you ever get the repo into this state\u201d issues not infrequently. JJ is just so low friction. The seamless and painless shuffling of commits, working up and down the commit chain without explicit rebasing, unchanging change-id", "context": "works with a repo with many committers, many not skilled with git", "use_case": "version control for team repo", "switched_from": "Git", "story": "The creator of Jujutsu has joined ERSC"}, {"id": 785685328, "item_id": 49105333, "url": "https://news.ycombinator.com/item?id=49105333", "by": "BeetleB", "date": "2026-07-29", "stance": "recommend", "quote": "Whereas with jujutsu, after learning it once, I never looked up `split`.", "excerpt": "I've used git for many years and never remembered the command `git reset -p`. I'd have to look it up. Since that's a pain, I simply didn't. Whereas with jujutsu, after learning it once, I never looked up `split`. And it's not like I use `split` often. I can go weeks without it.", "context": "", "use_case": "version control, splitting changes", "switched_from": "Git", "story": "Staging patches with Git add -p"}, {"id": 784862241, "item_id": 49053890, "url": "https://news.ycombinator.com/item?id=49053890", "by": "jauntywundrkind", "date": "2026-07-25", "stance": "recommend", "quote": "moving to jj, it has lots of amazing tools starting with `jj edit` to go change the past safely & conveniently", "excerpt": "rebase interactive is so great, such a powerful tool. it's the one clear tool that i used all the time. moving to jj, it has lots of amazing tools starting with `jj edit` to go change the past safely & conveniently, with much less pain. but i miss the direct powerful data-driven experience of seeing the timeline in a text file, and picking what to do with it. sometimes. imo every dev should work to get some competenc", "context": "", "use_case": "version control", "switched_from": "Git", "story": "Git rebase -I is not that scary"}]}, {"text": " for treating the working copy as a commit instead of a staging area,", "cites": [{"id": 770797744, "item_id": 48174859, "url": "https://news.ycombinator.com/item?id=48174859", "by": "tekacs", "date": "2026-05-17", "stance": "recommend", "quote": "I use it in all my Git-underneath repos with `jj git init --colocate`", "excerpt": "https://github.com/jj-vcs/jj On the off chance that you haven't already had this suggested to you on HN, I would suggest taking a look at JJ. I use it in all my Git-underneath repos with `jj git init --colocate` (You can run that in a git repo and it will hybridize, or in a new folder and it will init and hybridize). It doesn't have the staging concept, treating the working copy as just another commit (@), and to boo", "context": "", "use_case": "version control on top of git", "switched_from": "", "story": "Mercurial, 20 years and counting: how are we still alive and kicking? [video]"}, {"id": 792838464, "item_id": 49552404, "url": "https://news.ycombinator.com/item?id=49552404", "by": "steveklabnik", "date": "2026-09-03", "stance": "recommend", "quote": "jj makes doing this easier because you represent the index as an unnamed commit, and everything just works", "excerpt": "I love the index, and often have \"uncommitted\" stuff lying around. jj makes doing this easier because you represent the index as an unnamed commit, and everything just works, as opposed to needing to manage the index vs committed changes with separate tools.", "context": "", "use_case": "version control", "switched_from": "", "story": "The creator of Jujutsu has joined ERSC"}, {"id": 778116544, "item_id": 48632284, "url": "https://news.ycombinator.com/item?id=48632284", "by": "LoganDark", "date": "2026-06-22", "stance": "recommend", "quote": "It's absolutely great for keeping a bunch of exploratory changes alive, quick prototyping, etc.", "excerpt": "Seconding Jujutsu! I've been working to add Jujutsu support to basically every open-source tool and framework I use, including the agentic ones [0]. While it doesn't work for everyone, I've found it can really work for some people. (like myself) It's absolutely great for keeping a bunch of exploratory changes alive, quick prototyping, etc. as I tend to do with basically every source I have on my machine. I don't have", "context": "", "use_case": "version control, exploratory changes", "switched_from": "Git", "story": "Git is forever. I'm building Oak anyways"}]}, {"text": " and for working inside existing Git repos without coworkers having to switch.", "cites": [{"id": 792432160, "item_id": 49527010, "url": "https://news.ycombinator.com/item?id=49527010", "by": "saghm", "date": "2026-09-01", "stance": "recommend", "quote": "I freely use it with git repos without any of my coworkers needing to use it as well", "excerpt": "My relatively ignorant take is that it's pretty similar to Mercurial, except that it's compatible with git repos, which is also the answer to why it might get more traction. At least from my standpoint, it also doesn't need to get traction, because I freely use it with git repos without any of my coworkers needing to use it as well (although they might! I have no idea, just like they probably don't know I use it)", "context": "", "use_case": "version control", "switched_from": "", "story": "The creator of Jujutsu has joined ERSC"}, {"id": 791142112, "item_id": 49446382, "url": "https://news.ycombinator.com/item?id=49446382", "by": "VulgarExigency", "date": "2026-08-26", "stance": "recommend", "quote": "jj can work with git as its storage, so all of its commits are git commits, so a jj-local and git-remote flow is fully supported. I use it", "excerpt": "jj can work with git as its storage, so all of its commits are git commits, so a jj-local and git-remote flow is fully supported. I use it, and as far as I know I'm the only one on my team doing so.", "context": "only one on team using it", "use_case": "version control with git remotes", "switched_from": "", "story": "Maiao: Gerrit-style code review workflow for GitHub, GitLab, Gitea, others"}, {"id": 794368144, "item_id": 49648009, "url": "https://news.ycombinator.com/item?id=49648009", "by": "dxdm", "date": "2026-09-10", "stance": "recommend", "quote": "jj is one of the few that convinced me. I started using it exclusively with existing git repos", "excerpt": "I don't want to stop you from providing your opinion, and looking back, I shouldn't have questioned it the way I did. I didn't consider, after my own experience switching from the time of CVS and then SVN to git, with the substantial liberation of workflow that it brought, that somebody would not have that experience, but maybe even an opposite one instead. To be honest, I still find that hard to imagine. That's sill", "context": "former CVS/SVN user; colleagues still use git", "use_case": "version control on git repos", "switched_from": "", "story": "Version control second coming"}, {"id": 773726768, "item_id": 48357923, "url": "https://news.ycombinator.com/item?id=48357923", "by": "mamcx", "date": "2026-06-01", "stance": "recommend", "quote": "THEN, I move to jujutsu.", "excerpt": "I use rerere when \"forced\" by team to use rebase. It not even work that much at the end (you can't control workflows outside yourself, that is why git ux is wrong: it desperately need total discipline). THEN, I move to jujutsu. Only has a few problems at start trying to use it as git, but after get the idea, all fine. BTW, this was with the same team and they never know, so JJ is in fact better: It survive OTHERS wor", "context": "", "use_case": "version control", "switched_from": "Git", "story": "Using Git's rerere feature to escape recurring conflict hell"}]}, {"text": " The most common caveat is friction with Git and GitHub, including team PR workflows, colocated-repo issues and missing submodule support.", "cites": [{"id": 764258320, "item_id": 47766145, "url": "https://news.ycombinator.com/item?id=47766145", "by": "kevin_nisbet", "date": "2026-04-14", "stance": "warn", "quote": "I really wanted to like JJ, it was handy for a few months when I used it. But for me in the end I reverted back to regular git.", "excerpt": "I really wanted to like JJ, it was handy for a few months when I used it. But for me in the end I reverted back to regular git. What triggered me to go back was I never got a really clean mental model for how to keep ontop of Github PRs, bring in changes from origin/main, and ended up really badly mangling a feature branch that multiple contributors were working on when we did want to pull it in. I'll probably try it", "context": "works in a team via GitHub PRs", "use_case": "version control with GitHub PRs", "switched_from": "", "story": "What is jj and why should I care?"}, {"id": 773893504, "item_id": 48368344, "url": "https://news.ycombinator.com/item?id=48368344", "by": "mos3abof", "date": "2026-06-02", "stance": "recommend", "quote": "I have been using jj (jujitsu-vcs) for a while now", "excerpt": "I have been using jj (jujitsu-vcs) for a while now, but dealing with Github has been a struggle, especially when working with other on the same repo. That was until I found \"jellycat\", which is a jellyfish inspired CLI for dealing with Github and jj! The tool's creator worked on Facebook's (sorry, Meta!) internal source control, which imho is one of the best ecosystems that I have ever seen. In fact, I was using sapl", "context": "", "use_case": "version control", "switched_from": "Sapling", "story": "Jellycat: a Rust CLI for Turning Jujutsu Changesets into GitHub PR Stacks"}, {"id": 782498320, "item_id": 48906145, "url": "https://news.ycombinator.com/item?id=48906145", "by": "klibertp", "date": "2026-07-14", "stance": "recommend", "quote": "If you can give `jj` a try on a greenfield, single-developer project, you probably should.", "excerpt": "IME, the only real pain point with JJ is Git integration. I love it, it's great in almost everything it does. Formalizing all the DSLs and using them consistently throughout the config and CLI is exactly how filesets, revsets, and templating should be implemented. The focus on exposing concepts as interfaces (without \"directly reflecting internals\"[1] in the UI) is only as good as the concepts themselves, and in JJ's", "context": "", "use_case": "version control", "switched_from": "", "story": "The Git history command deserves more attention"}, {"id": 781019488, "item_id": 48813718, "url": "https://news.ycombinator.com/item?id=48813718", "by": "1123581321", "date": "2026-07-06", "stance": "recommend", "quote": "I use it exclusively, but still in colocated mode", "excerpt": "I use it exclusively, but still in colocated mode so it\u2019s compatible with contributors who use git, and GitHub. I\u2019ve run into a few issues with colocated (had to fix staleness several times per year, for example) but compatibility overall hasn\u2019t blocked me.", "context": "", "use_case": "version control", "switched_from": "", "story": "Ask HN: Is anyone using Jujutsu version control (JJ) exclusively?"}, {"id": 792426704, "item_id": 49526669, "url": "https://news.ycombinator.com/item?id=49526669", "by": "KajMagnus", "date": "2026-09-01", "stance": "recommend", "quote": "But with jj, no stress: I can just check in the conflicts, and later, on the other laptop: check out the conflicts and continue resolving.", "excerpt": "> As a trivial counter example Git does not currently have a way to store conflicts inside commits[1], which is one of our major features. Yes, I like how jj does it! Did a big `git rebase -i` yesterday and I felt stressed up, almost a bit angry, when there were some conflicts and I wasn't sure if I'd resolve all of them before it was time to leave, and work more later from a different laptop. But with jj, no stress:", "context": "", "use_case": "version control", "switched_from": "Git", "story": "The creator of Jujutsu has joined ERSC"}]}], "praise": [{"label": "Git compatibility", "summary": "Commenters use it on existing Git repos and with GitHub, even when the rest of the team uses Git.", "quotes": [{"id": 792432160, "item_id": 49527010, "url": "https://news.ycombinator.com/item?id=49527010", "by": "saghm", "date": "2026-09-01", "stance": "recommend", "quote": "I freely use it with git repos without any of my coworkers needing to use it as well", "excerpt": "My relatively ignorant take is that it's pretty similar to Mercurial, except that it's compatible with git repos, which is also the answer to why it might get more traction. At least from my standpoint, it also doesn't need to get traction, because I freely use it with git repos without any of my coworkers needing to use it as well (although they might! I have no idea, just like they probably don't know I use it)", "context": "", "use_case": "version control", "switched_from": "", "story": "The creator of Jujutsu has joined ERSC"}, {"id": 791142112, "item_id": 49446382, "url": "https://news.ycombinator.com/item?id=49446382", "by": "VulgarExigency", "date": "2026-08-26", "stance": "recommend", "quote": "jj can work with git as its storage, so all of its commits are git commits, so a jj-local and git-remote flow is fully supported. I use it", "excerpt": "jj can work with git as its storage, so all of its commits are git commits, so a jj-local and git-remote flow is fully supported. I use it, and as far as I know I'm the only one on my team doing so.", "context": "only one on team using it", "use_case": "version control with git remotes", "switched_from": "", "story": "Maiao: Gerrit-style code review workflow for GitHub, GitLab, Gitea, others"}, {"id": 765508240, "item_id": 47844265, "url": "https://news.ycombinator.com/item?id=47844265", "by": "quicksnap", "date": "2026-04-20", "stance": "recommend", "quote": "It is so much better than git in every way.", "excerpt": "Trying out jj is super low-risk--since it uses git as a backend, you can test it out and bail back to git without any drawbacks other than a detached head state. And I hope you do. It is so much better than git in every way. It enables working with stacks and the aforementioned megamerges so easily, allowing me to continue working forward while smaller units of work are reviewed/merged. When I first tried to use jj, ", "context": "", "use_case": "version control with stacks", "switched_from": "Git", "story": "Jujutsu Megamerges for Fun and Profit"}]}, {"label": "History editing", "summary": "Squash, split, rebase and editing past commits are described as easier and safer than Git's interactive rebase.", "quotes": [{"id": 792483760, "item_id": 49530235, "url": "https://news.ycombinator.com/item?id=49530235", "by": "dcre", "date": "2026-09-02", "stance": "recommend", "quote": "shuffling commits around with squash, split, and rebase is much better than git\u2019s interactive rebase", "excerpt": "A few advantages for me, even for the same 5 commands I use over and over: - undo - shuffling commits around with squash, split, and rebase is much better than git\u2019s interactive rebase - make commits without having to come up with a branch name (I might make three versions of the same change in parallel to see how they compare) I see git is working on adding some of this under the history command. The revset language", "context": "", "use_case": "version control", "switched_from": "Git", "story": "The creator of Jujutsu has joined ERSC"}, {"id": 784862241, "item_id": 49053890, "url": "https://news.ycombinator.com/item?id=49053890", "by": "jauntywundrkind", "date": "2026-07-25", "stance": "recommend", "quote": "moving to jj, it has lots of amazing tools starting with `jj edit` to go change the past safely & conveniently", "excerpt": "rebase interactive is so great, such a powerful tool. it's the one clear tool that i used all the time. moving to jj, it has lots of amazing tools starting with `jj edit` to go change the past safely & conveniently, with much less pain. but i miss the direct powerful data-driven experience of seeing the timeline in a text file, and picking what to do with it. sometimes. imo every dev should work to get some competenc", "context": "", "use_case": "version control", "switched_from": "Git", "story": "Git rebase -I is not that scary"}, {"id": 803780144, "item_id": 50236259, "url": "https://news.ycombinator.com/item?id=50236259", "by": "saghm", "date": "2026-10-25", "stance": "recommend", "quote": "My favorite feature is the built-in distinction between what's mutable and what's immutable in my history.", "excerpt": "My favorite feature is the built-in distinction between what's mutable and what's immutable in my history. I can freely modify any commits I make locally without issue, since no one else would be able to depend on them, but if I push something or fetch it from a coworker, I have the safety of not needing to be careful when doing the equivalent of an amend or rebase because it will fail with an error telling me to use", "context": "", "use_case": "version control", "switched_from": "Git", "story": "JetBrains Thinkrail"}]}, {"label": "Mental model", "summary": "Users say its model of version control is more flexible and fits how they work better than Git's.", "quotes": [{"id": 792489184, "item_id": 49530574, "url": "https://news.ycombinator.com/item?id=49530574", "by": "cisrockandroll", "date": "2026-09-02", "stance": "recommend", "quote": "I love JJ\u2019s mental model. Its so much less opionated and lets me do what I want.", "excerpt": "Badass!!! Congrats. I love JJ\u2019s mental model. Its so much less opionated and lets me do what I want. Want to make 5 versions of the same commit? Easy. Need to push out a change asap without having to pre create a branch, stash your changes, yadayada. Jj just adapts. Once you start thinking in jj it becomes frustrating having think back to use GitHub as a code repo.", "context": "", "use_case": "version control", "switched_from": "", "story": "The creator of Jujutsu has joined ERSC"}, {"id": 782505136, "item_id": 48906571, "url": "https://news.ycombinator.com/item?id=48906571", "by": "steeleduncan", "date": "2026-07-14", "stance": "recommend", "quote": "I love JJ, and the mental model of source control it presents, and I will continue to use it.", "excerpt": "In princple JJ has non-Git backends, but the only backend they state as being production ready is the Git backend. JJ without the Git interop is more a concept than a reality right now. I love JJ, and the mental model of source control it presents, and I will continue to use it. However, still needing to \"drop down\" to Git every now and again to get something done makes it feel very much like a convenient wrapper on ", "context": "", "use_case": "version control", "switched_from": "Git", "story": "The Git history command deserves more attention"}, {"id": 772190288, "item_id": 48261893, "url": "https://news.ycombinator.com/item?id=48261893", "by": "nozzlegear", "date": "2026-05-24", "stance": "recommend", "quote": "I've completely switched over to jujutsu. The whole experience is more ergonomic in my opinion", "excerpt": "As a git rebase enjoyer, I've completely switched over to jujutsu. The whole experience is more ergonomic in my opinion, and the default workflow which I use (using `jj new` to create a new change that clearly delineates work on a different \"thing\" before I start working on it) fits my mental model much better than the traditional write-then-commit workflow we all grew up with.", "context": "git rebase enjoyer", "use_case": "version control", "switched_from": "Git", "story": "Defeating Git Rigour Fatigue with Jujutsu"}]}, {"label": "Stacks and megamerges", "summary": "Several open changes, stacked work and merges of multiple branches are easy to keep up to date.", "quotes": [{"id": 765508240, "item_id": 47844265, "url": "https://news.ycombinator.com/item?id=47844265", "by": "quicksnap", "date": "2026-04-20", "stance": "recommend", "quote": "It is so much better than git in every way.", "excerpt": "Trying out jj is super low-risk--since it uses git as a backend, you can test it out and bail back to git without any drawbacks other than a detached head state. And I hope you do. It is so much better than git in every way. It enables working with stacks and the aforementioned megamerges so easily, allowing me to continue working forward while smaller units of work are reviewed/merged. When I first tried to use jj, ", "context": "", "use_case": "version control with stacks", "switched_from": "Git", "story": "Jujutsu Megamerges for Fun and Profit"}, {"id": 785930512, "item_id": 49120657, "url": "https://news.ycombinator.com/item?id=49120657", "by": "sarthak-ag", "date": "2026-07-31", "stance": "recommend", "quote": "JJ is much more than that. One of the other features I use quite heavily is that, in JJ, you can essentially check out multiple branches at the same time", "excerpt": "Yes, and in fact, JJ is much more than that. One of the other features I use quite heavily is that, in JJ, you can essentially check out multiple branches at the same time by just creating a local merge. JJ will keep your local merge updated as you rebase the branches it builds on. I have written about it here: https://sarthakag.bearblog.dev/from-git-to-jj-jujutsu/", "context": "", "use_case": "version control, stacked branches", "switched_from": "Git", "story": "Stacked PRs are now live on GitHub"}, {"id": 764256352, "item_id": 47766022, "url": "https://news.ycombinator.com/item?id=47766022", "by": "jrockway", "date": "2026-04-14", "stance": "recommend", "quote": "It is truly a beautiful model.  Really a big mental health saver.", "excerpt": "jj is great and while it was an adjustment at first, I've never looked back. I feel like when you're working with other people, things never get reviewed and merged as quickly as you'd like. With jj, it's pretty low-cost to have a bunch of PRs open at once, and you can do something like `jj new <pr1> <pr2> <pr3>` to build stuff that requires all 3. This lets me do things like... not do a big refactoring in the same P", "context": "formerly at Google", "use_case": "stacked PRs, version control", "switched_from": "git", "story": "What is jj and why should I care?"}]}, {"label": "No staging, snapshots", "summary": "The working copy is snapshotted as a commit, so intermediate states and undo are always available.", "quotes": [{"id": 770797744, "item_id": 48174859, "url": "https://news.ycombinator.com/item?id=48174859", "by": "tekacs", "date": "2026-05-17", "stance": "recommend", "quote": "I use it in all my Git-underneath repos with `jj git init --colocate`", "excerpt": "https://github.com/jj-vcs/jj On the off chance that you haven't already had this suggested to you on HN, I would suggest taking a look at JJ. I use it in all my Git-underneath repos with `jj git init --colocate` (You can run that in a git repo and it will hybridize, or in a new folder and it will init and hybridize). It doesn't have the staging concept, treating the working copy as just another commit (@), and to boo", "context": "", "use_case": "version control on top of git", "switched_from": "", "story": "Mercurial, 20 years and counting: how are we still alive and kicking? [video]"}, {"id": 792838464, "item_id": 49552404, "url": "https://news.ycombinator.com/item?id=49552404", "by": "steveklabnik", "date": "2026-09-03", "stance": "recommend", "quote": "jj makes doing this easier because you represent the index as an unnamed commit, and everything just works", "excerpt": "I love the index, and often have \"uncommitted\" stuff lying around. jj makes doing this easier because you represent the index as an unnamed commit, and everything just works, as opposed to needing to manage the index vs committed changes with separate tools.", "context": "", "use_case": "version control", "switched_from": "", "story": "The creator of Jujutsu has joined ERSC"}, {"id": 754945616, "item_id": 47184101, "url": "https://news.ycombinator.com/item?id=47184101", "by": "mpalmer", "date": "2026-02-27", "stance": "recommend", "quote": "But with jj the filesystem tracking is built in, which is a huge advantage.", "excerpt": "This is so cool to have made yourself. How would you compare this to the functionality offered by jujutsu? I love the histogram, it was the first sort of thing I wanted out of jujutsu that its UI doesn't make very easy. But with jj the filesystem tracking is built in, which is a huge advantage.", "context": "", "use_case": "version control", "switched_from": "", "story": "Show HN: Unfucked (unf) \u2013 a filesystem flight recorder that snapshots every save"}]}, {"label": "AI agent workflows", "summary": "Auto-snapshots make it easy to compare and undo changes between coding-agent prompts.", "quotes": [{"id": 763415360, "item_id": 47713460, "url": "https://news.ycombinator.com/item?id=47713460", "by": "Meleagris", "date": "2026-04-09", "stance": "recommend", "quote": "I recently switched to Jujutsu (jj) and it made me realize that \u201cwhat comes after Git\u201d might already exist.", "excerpt": "I recently switched to Jujutsu (jj) and it made me realize that \u201cwhat comes after Git\u201d might already exist. It turns out the snapshot model is a perfect fit for AI-assisted development. I can iterate freely without thinking about commits or worrying about saving known-good versions. You can just mess around and make it presentable later, which Git never really let you do nicely. Plus there\u2019s essentially zero learning", "context": "", "use_case": "version control with AI-assisted development", "switched_from": "Git", "story": "We've raised $17M to build what comes after Git"}, {"id": 769047136, "item_id": 48065446, "url": "https://news.ycombinator.com/item?id=48065446", "by": "Zambyte", "date": "2026-05-08", "stance": "recommend", "quote": "I personally have a workflow when I use Jujutsu (jj) for git already", "excerpt": "People in this thread seem to be too focused on the agent creating a git log. This seems to be solving a different problem than that does. When you're interacting with agents, multiple prompts may reasonable culminate in a single commit. It may be useful to track or under things between commits - at the prompt level. I personally have a workflow when I use Jujutsu (jj) for git already, and this slotted in very nicely", "context": "", "use_case": "tracking agent prompt-level changes", "switched_from": "", "story": "Show HN: Git for AI Agents"}, {"id": 769202512, "item_id": 48075157, "url": "https://news.ycombinator.com/item?id=48075157", "by": "Zambyte", "date": "2026-05-09", "stance": "recommend", "quote": "I start by using jj new to create a new change where I want to start working.", "excerpt": "Sure. I was a bit loose with my vocab in my previous comment - I'm going to try to be more specific by using the terms as defined in the jj glossary[0] (particularly \"change\" vs \"commit\"). - I start by using jj new to create a new change where I want to start working. - I open codex, and prompt it to do something. - Roughly every prompt, I will naturally check the cumulative diff using jj diff. - If I want to check t", "context": "", "use_case": "version control with AI agents", "switched_from": "", "story": "Show HN: Git for AI Agents"}]}], "caveats": [{"label": "GitHub team workflows", "summary": "Some found it hard to keep up with GitHub PRs and shared branches, and one user went back to Git.", "quotes": [{"id": 764258320, "item_id": 47766145, "url": "https://news.ycombinator.com/item?id=47766145", "by": "kevin_nisbet", "date": "2026-04-14", "stance": "warn", "quote": "I really wanted to like JJ, it was handy for a few months when I used it. But for me in the end I reverted back to regular git.", "excerpt": "I really wanted to like JJ, it was handy for a few months when I used it. But for me in the end I reverted back to regular git. What triggered me to go back was I never got a really clean mental model for how to keep ontop of Github PRs, bring in changes from origin/main, and ended up really badly mangling a feature branch that multiple contributors were working on when we did want to pull it in. I'll probably try it", "context": "works in a team via GitHub PRs", "use_case": "version control with GitHub PRs", "switched_from": "", "story": "What is jj and why should I care?"}, {"id": 773893504, "item_id": 48368344, "url": "https://news.ycombinator.com/item?id=48368344", "by": "mos3abof", "date": "2026-06-02", "stance": "recommend", "quote": "I have been using jj (jujitsu-vcs) for a while now", "excerpt": "I have been using jj (jujitsu-vcs) for a while now, but dealing with Github has been a struggle, especially when working with other on the same repo. That was until I found \"jellycat\", which is a jellyfish inspired CLI for dealing with Github and jj! The tool's creator worked on Facebook's (sorry, Meta!) internal source control, which imho is one of the best ecosystems that I have ever seen. In fact, I was using sapl", "context": "", "use_case": "version control", "switched_from": "Sapling", "story": "Jellycat: a Rust CLI for Turning Jujutsu Changesets into GitHub PR Stacks"}, {"id": 785994416, "item_id": 49124651, "url": "https://news.ycombinator.com/item?id=49124651", "by": "Shish2k", "date": "2026-07-31", "stance": "recommend", "quote": "I love JJ and stacked diffs with Gerrit and Phabricator", "excerpt": "I am confused - I love JJ and stacked diffs with Gerrit and Phabricator, but trying to port that same \"each commit gets reviewed individually, and things don't break when a half-reviewed stack gets rebased\" workflow to GitHub has been a nightmare, how does JJ help?", "context": "", "use_case": "stacked diffs", "switched_from": "", "story": "Stacked PRs are now live on GitHub"}]}, {"label": "Git interop friction", "summary": "Users still sometimes need to drop down to Git, and colocated repos can go stale.", "quotes": [{"id": 782498320, "item_id": 48906145, "url": "https://news.ycombinator.com/item?id=48906145", "by": "klibertp", "date": "2026-07-14", "stance": "recommend", "quote": "If you can give `jj` a try on a greenfield, single-developer project, you probably should.", "excerpt": "IME, the only real pain point with JJ is Git integration. I love it, it's great in almost everything it does. Formalizing all the DSLs and using them consistently throughout the config and CLI is exactly how filesets, revsets, and templating should be implemented. The focus on exposing concepts as interfaces (without \"directly reflecting internals\"[1] in the UI) is only as good as the concepts themselves, and in JJ's", "context": "", "use_case": "version control", "switched_from": "", "story": "The Git history command deserves more attention"}, {"id": 782505136, "item_id": 48906571, "url": "https://news.ycombinator.com/item?id=48906571", "by": "steeleduncan", "date": "2026-07-14", "stance": "recommend", "quote": "I love JJ, and the mental model of source control it presents, and I will continue to use it.", "excerpt": "In princple JJ has non-Git backends, but the only backend they state as being production ready is the Git backend. JJ without the Git interop is more a concept than a reality right now. I love JJ, and the mental model of source control it presents, and I will continue to use it. However, still needing to \"drop down\" to Git every now and again to get something done makes it feel very much like a convenient wrapper on ", "context": "", "use_case": "version control", "switched_from": "Git", "story": "The Git history command deserves more attention"}, {"id": 781019488, "item_id": 48813718, "url": "https://news.ycombinator.com/item?id=48813718", "by": "1123581321", "date": "2026-07-06", "stance": "recommend", "quote": "I use it exclusively, but still in colocated mode", "excerpt": "I use it exclusively, but still in colocated mode so it\u2019s compatible with contributors who use git, and GitHub. I\u2019ve run into a few issues with colocated (had to fix staleness several times per year, for example) but compatibility overall hasn\u2019t blocked me.", "context": "", "use_case": "version control", "switched_from": "", "story": "Ask HN: Is anyone using Jujutsu version control (JJ) exclusively?"}]}, {"label": "Submodules and LFS", "summary": "Git submodules and LFS are not supported.", "quotes": [{"id": 792426704, "item_id": 49526669, "url": "https://news.ycombinator.com/item?id=49526669", "by": "KajMagnus", "date": "2026-09-01", "stance": "recommend", "quote": "But with jj, no stress: I can just check in the conflicts, and later, on the other laptop: check out the conflicts and continue resolving.", "excerpt": "> As a trivial counter example Git does not currently have a way to store conflicts inside commits[1], which is one of our major features. Yes, I like how jj does it! Did a big `git rebase -i` yesterday and I felt stressed up, almost a bit angry, when there were some conflicts and I wasn't sure if I'd resolve all of them before it was time to leave, and work more later from a different laptop. But with jj, no stress:", "context": "", "use_case": "version control", "switched_from": "Git", "story": "The creator of Jujutsu has joined ERSC"}, {"id": 792462560, "item_id": 49528910, "url": "https://news.ycombinator.com/item?id=49528910", "by": "minraws", "date": "2026-09-01", "stance": "recommend", "quote": "since you can use jj in a git repo you can commit git stuff via git like submodules and then enjoy the world of jj", "excerpt": "1. Reflog is very ref specific that is it tracks head. JJ has op and evo logs that do that + a bunch more they track everything about the repo every possible action. It's hard to explain with going into technical depth but you can read up on it. 2. Yeah submodules aren't supported but since you can use jj in a git repo you can commit git stuff via git like submodules and then enjoy the world of jj. Since submodule in", "context": "", "use_case": "version control", "switched_from": "", "story": "The creator of Jujutsu has joined ERSC"}, {"id": 778116544, "item_id": 48632284, "url": "https://news.ycombinator.com/item?id=48632284", "by": "LoganDark", "date": "2026-06-22", "stance": "recommend", "quote": "It's absolutely great for keeping a bunch of exploratory changes alive, quick prototyping, etc.", "excerpt": "Seconding Jujutsu! I've been working to add Jujutsu support to basically every open-source tool and framework I use, including the agentic ones [0]. While it doesn't work for everyone, I've found it can really work for some people. (like myself) It's absolutely great for keeping a bunch of exploratory changes alive, quick prototyping, etc. as I tend to do with basically every source I have on my machine. I don't have", "context": "", "use_case": "version control, exploratory changes", "switched_from": "Git", "story": "Git is forever. I'm building Oak anyways"}]}, {"label": "Learning curve", "summary": "Some users needed an adjustment period, for example getting used to changes being picked up automatically.", "quotes": [{"id": 803780144, "item_id": 50236259, "url": "https://news.ycombinator.com/item?id=50236259", "by": "saghm", "date": "2026-10-25", "stance": "recommend", "quote": "My favorite feature is the built-in distinction between what's mutable and what's immutable in my history.", "excerpt": "My favorite feature is the built-in distinction between what's mutable and what's immutable in my history. I can freely modify any commits I make locally without issue, since no one else would be able to depend on them, but if I push something or fetch it from a coworker, I have the safety of not needing to be careful when doing the equivalent of an amend or rebase because it will fail with an error telling me to use", "context": "", "use_case": "version control", "switched_from": "Git", "story": "JetBrains Thinkrail"}, {"id": 764256352, "item_id": 47766022, "url": "https://news.ycombinator.com/item?id=47766022", "by": "jrockway", "date": "2026-04-14", "stance": "recommend", "quote": "It is truly a beautiful model.  Really a big mental health saver.", "excerpt": "jj is great and while it was an adjustment at first, I've never looked back. I feel like when you're working with other people, things never get reviewed and merged as quickly as you'd like. With jj, it's pretty low-cost to have a bunch of PRs open at once, and you can do something like `jj new <pr1> <pr2> <pr3>` to build stuff that requires all 3. This lets me do things like... not do a big refactoring in the same P", "context": "formerly at Google", "use_case": "stacked PRs, version control", "switched_from": "git", "story": "What is jj and why should I care?"}, {"id": 773726768, "item_id": 48357923, "url": "https://news.ycombinator.com/item?id=48357923", "by": "mamcx", "date": "2026-06-01", "stance": "recommend", "quote": "THEN, I move to jujutsu.", "excerpt": "I use rerere when \"forced\" by team to use rebase. It not even work that much at the end (you can't control workflows outside yourself, that is why git ux is wrong: it desperately need total discipline). THEN, I move to jujutsu. Only has a few problems at start trying to use it as git, but after get the idea, all fine. BTW, this was with the same team and they never know, so JJ is in fact better: It survive OTHERS wor", "context": "", "use_case": "version control", "switched_from": "Git", "story": "Using Git's rerere feature to escape recurring conflict hell"}]}, {"label": "Tool support", "summary": "Editor and agent tooling support lags behind Git's support.", "quotes": [{"id": 776265969, "item_id": 48516623, "url": "https://news.ycombinator.com/item?id=48516623", "by": "dagss", "date": "2026-06-13", "stance": "recommend", "quote": "jj seems promising", "excerpt": "What are people's workflows these days? As I use claude more and more I've started using git worktrees, one branch per worktree per PR, with possibly multiple agents working in each worktree at the same time on different aspects. And I manually instruct those agents. Like Emdash/Cursor/Zed. Sometimes I review code locally, sometimes agents push and I review in GitHub, no clear system yet. (jj seems promising, but Zed", "context": "", "use_case": "version control", "switched_from": "", "story": "Show HN: Paca \u2013 Lightweight Jira alternative for human-AI collaboration"}, {"id": 778256160, "item_id": 48641010, "url": "https://news.ycombinator.com/item?id=48641010", "by": "dbt00", "date": "2026-06-22", "stance": "recommend", "quote": "I use a new VCS already (jj, highly recommended)", "excerpt": "I use a new VCS already (jj, highly recommended) and Claude forgets to use it all the time despite many obvious instructions in many places.", "context": "", "use_case": "version control", "switched_from": "", "story": "Git is forever. I'm building Oak anyways"}]}], "who": [{"by": "dxdm", "context": "former CVS/SVN user; colleagues still use git", "url": "https://news.ycombinator.com/item?id=49648009", "date": "2026-09-10"}, {"by": "y1n0", "context": "leads a team using git", "url": "https://news.ycombinator.com/item?id=49570853", "date": "2026-09-04"}, {"by": "VulgarExigency", "context": "only one on team using it", "url": "https://news.ycombinator.com/item?id=49446382", "date": "2026-08-26"}, {"by": "giodamelio", "context": "maintains personal patches to devtools", "url": "https://news.ycombinator.com/item?id=49203920", "date": "2026-08-06"}, {"by": "neprotivo", "context": "uses coding agents heavily", "url": "https://news.ycombinator.com/item?id=48720490", "date": "2026-06-29"}, {"by": "nozzlegear", "context": "git rebase enjoyer", "url": "https://news.ycombinator.com/item?id=48261893", "date": "2026-05-24"}, {"by": "tcoff91", "context": "jj user", "url": "https://news.ycombinator.com/item?id=48166695", "date": "2026-05-17"}, {"by": "uhhhd", "context": "hobbyist and professional developer", "url": "https://news.ycombinator.com/item?id=47842983", "date": "2026-04-20"}, {"by": "sam_goody", "context": "prefers GUIs", "url": "https://news.ycombinator.com/item?id=47767503", "date": "2026-04-14"}, {"by": "jrockway", "context": "formerly at Google", "url": "https://news.ycombinator.com/item?id=47766022", "date": "2026-04-14"}, {"by": "abound", "context": "uses at work", "url": "https://news.ycombinator.com/item?id=47400376", "date": "2026-03-16"}, {"by": "chriswarbo", "context": "still learning jj", "url": "https://news.ycombinator.com/item?id=47326710", "date": "2026-03-10"}], "tags": ["for Git users", "for rebase-heavy workflows", "for stacked changes", "for AI coding agents", "for terminal users"], "use_cases": ["version control", "fuse subtree experiment", "version control on git repos", "rebasing, conflicts, clean mrs", "version control for team repo", "version control with git remotes"], "compared": [{"slug": "git", "name": "Git", "co": 65, "switched_from": 26, "switched_to": 0}, {"slug": "magit", "name": "Magit", "co": 4, "switched_from": 1, "switched_to": 0}, {"slug": "lazygit", "name": "lazygit", "co": 3, "switched_from": 1, "switched_to": 0}, {"slug": "jjui", "name": "jjui", "co": 5, "switched_from": 0, "switched_to": 0}, {"slug": "mercurial", "name": "Mercurial", "co": 5, "switched_from": 0, "switched_to": 0}, {"slug": "graphite", "name": "Graphite", "co": 2, "switched_from": 1, "switched_to": 0}, {"slug": "fossil", "name": "Fossil", "co": 3, "switched_from": 0, "switched_to": 0}], "makers": [], "threads": [{"url": "https://news.ycombinator.com/item?id=49525297", "title": "The creator of Jujutsu has joined ERSC", "mentions": 12}, {"url": "https://news.ycombinator.com/item?id=47763759", "title": "What is jj and why should I care?", "mentions": 9}, {"url": "https://news.ycombinator.com/item?id=48631726", "title": "Git is forever. I'm building Oak anyways", "mentions": 4}, {"url": "https://news.ycombinator.com/item?id=47841129", "title": "Jujutsu Megamerges for Fun and Profit", "mentions": 4}, {"url": "https://news.ycombinator.com/item?id=49112232", "title": "Stacked PRs are now live on GitHub", "mentions": 3}, {"url": "https://news.ycombinator.com/item?id=48901010", "title": "The Git history command deserves more attention", "mentions": 3}], "sentiment_by_month": {"2025-11": {"neutral": 1, "recommend": 1}, "2025-12": {"recommend": 3, "neutral": 2}, "2026-01": {"compare": 1, "recommend": 2}, "2026-02": {"recommend": 3}, "2026-03": {"recommend": 3}, "2026-04": {"recommend": 13, "neutral": 2, "warn": 1, "compare": 1}, "2026-05": {"neutral": 1, "recommend": 4, "compare": 1}, "2026-06": {"recommend": 8, "neutral": 2}, "2026-07": {"recommend": 10, "neutral": 1}, "2026-08": {"neutral": 1, "recommend": 3}, "2026-09": {"recommend": 12, "neutral": 1}, "2026-10": {"neutral": 1, "recommend": 1}}, "quotes": [{"id": 803780144, "item_id": 50236259, "url": "https://news.ycombinator.com/item?id=50236259", "by": "saghm", "date": "2026-10-25", "stance": "recommend", "quote": "My favorite feature is the built-in distinction between what's mutable and what's immutable in my history.", "excerpt": "My favorite feature is the built-in distinction between what's mutable and what's immutable in my history. I can freely modify any commits I make locally without issue, since no one else would be able to depend on them, but if I push something or fetch it from a coworker, I have the safety of not needing to be careful when doing the equivalent of an amend or rebase because it will fail with an error telling me to use", "context": "", "use_case": "version control", "switched_from": "Git", "story": "JetBrains Thinkrail"}, {"id": 801217954, "item_id": 50076122, "url": "https://news.ycombinator.com/item?id=50076122", "by": "jauntywundrkind", "date": "2026-10-13", "stance": "neutral", "quote": "I threw together my own jujutsu powered FUSE subtree project", "excerpt": "Related, I've always wanted to see someone other than Meta run EdenFS, to hear more reports of what it's like. Feels like there's massive overlap. [Edit: I've chatted with Astra Pro some on this too now, https://chatgpt.com/share/6ace7be6-68f8-83ea-ad68-0f9d14448318 ]. https://github.com/facebook/sapling/blob/main/eden/fs/docs/Overview.md It's designed for container running, but ArtifactFS has some similarity in prin", "context": "", "use_case": "FUSE subtree experiment", "switched_from": "", "story": "Redesigning source control at Anthropic"}, {"id": 796973248, "item_id": 49810828, "url": "https://news.ycombinator.com/item?id=49810828", "by": "Ferret7446", "date": "2026-09-23", "stance": "neutral", "quote": "Having switched to jj I don't really agree.", "excerpt": "Having switched to jj I don't really agree. Everything I do is basically the same as with branches, just that I get randomly generated tip names rather than naming them myself, which is both slightly convenient and slightly annoying", "context": "", "use_case": "version control", "switched_from": "Git", "story": "Looking forward to Git 2.56 \u2013 and 3.0"}, {"id": 794473888, "item_id": 49654618, "url": "https://news.ycombinator.com/item?id=49654618", "by": "zrg", "date": "2026-09-11", "stance": "recommend", "quote": "I'm currently very much on the jujutsu train as the author also mentioned, i do recommend y'all give it a try", "excerpt": "I'm currently very much on the jujutsu train as the author also mentioned, i do recommend y'all give it a try", "context": "", "use_case": "version control", "switched_from": "", "story": "Working with Git Worktrees in Magit"}, {"id": 794368144, "item_id": 49648009, "url": "https://news.ycombinator.com/item?id=49648009", "by": "dxdm", "date": "2026-09-10", "stance": "recommend", "quote": "jj is one of the few that convinced me. I started using it exclusively with existing git repos", "excerpt": "I don't want to stop you from providing your opinion, and looking back, I shouldn't have questioned it the way I did. I didn't consider, after my own experience switching from the time of CVS and then SVN to git, with the substantial liberation of workflow that it brought, that somebody would not have that experience, but maybe even an opposite one instead. To be honest, I still find that hard to imagine. That's sill", "context": "former CVS/SVN user; colleagues still use git", "use_case": "version control on git repos", "switched_from": "", "story": "Version control second coming"}, {"id": 793133648, "item_id": 49570853, "url": "https://news.ycombinator.com/item?id=49570853", "by": "y1n0", "date": "2026-09-04", "stance": "recommend", "quote": "But JJ is the most pain-free vcs evolution I've seen.", "excerpt": "CLI is preferred from my point of view if only because it's the supported standard interface. VSCode's version control interface is reasonably close to a standard, and I love the tree view there. But generally I don't want to use random third party things because they either aren't consistent (i.e. now I have to learn what joe schmoe thinks a version control interface should be), or don't stick around long enough. Bu", "context": "leads a team using git", "use_case": "rebasing, conflicts, clean MRs", "switched_from": "Git", "story": "The creator of Jujutsu has joined ERSC"}, {"id": 792838464, "item_id": 49552404, "url": "https://news.ycombinator.com/item?id=49552404", "by": "steveklabnik", "date": "2026-09-03", "stance": "recommend", "quote": "jj makes doing this easier because you represent the index as an unnamed commit, and everything just works", "excerpt": "I love the index, and often have \"uncommitted\" stuff lying around. jj makes doing this easier because you represent the index as an unnamed commit, and everything just works, as opposed to needing to manage the index vs committed changes with separate tools.", "context": "", "use_case": "version control", "switched_from": "", "story": "The creator of Jujutsu has joined ERSC"}, {"id": 792708273, "item_id": 49544267, "url": "https://news.ycombinator.com/item?id=49544267", "by": "saghm", "date": "2026-09-03", "stance": "neutral", "quote": "exact same as what I was saying about jj", "excerpt": "> I\u2019m also using magit (after a tour in various GUI) but for me it is to git what vi is to ex. Direct interaction instead of a command prompt. I'm not sure I understand how \"I use a specific text editor with a specialized interface into git that's superior\" is a counterargument to the first-party tool having horrible UX. That seems basically the exact same as what I was saying about jj, except via emacs instead of a ", "context": "", "use_case": "version control", "switched_from": "", "story": "The creator of Jujutsu has joined ERSC"}, {"id": 792550064, "item_id": 49534379, "url": "https://news.ycombinator.com/item?id=49534379", "by": "ashkankiani", "date": "2026-09-02", "stance": "recommend", "quote": "I pretty much only use jj now, and it was really good even just with the CLI.", "excerpt": "I pretty much only use jj now, and it was really good even just with the CLI. But adding jjui changed the story entirely. I now rarely use jj without just booting up jjui first. It will be good to see what jj will look like with more funded dev work, but I'm always a little worried about financial incentives mixing with the tools I use for the long term. I guess the saving grace is that I don't really need more upgra", "context": "", "use_case": "version control", "switched_from": "", "story": "The creator of Jujutsu has joined ERSC"}, {"id": 792489184, "item_id": 49530574, "url": "https://news.ycombinator.com/item?id=49530574", "by": "cisrockandroll", "date": "2026-09-02", "stance": "recommend", "quote": "I love JJ\u2019s mental model. Its so much less opionated and lets me do what I want.", "excerpt": "Badass!!! Congrats. I love JJ\u2019s mental model. Its so much less opionated and lets me do what I want. Want to make 5 versions of the same commit? Easy. Need to push out a change asap without having to pre create a branch, stash your changes, yadayada. Jj just adapts. Once you start thinking in jj it becomes frustrating having think back to use GitHub as a code repo.", "context": "", "use_case": "version control", "switched_from": "", "story": "The creator of Jujutsu has joined ERSC"}, {"id": 792483760, "item_id": 49530235, "url": "https://news.ycombinator.com/item?id=49530235", "by": "dcre", "date": "2026-09-02", "stance": "recommend", "quote": "shuffling commits around with squash, split, and rebase is much better than git\u2019s interactive rebase", "excerpt": "A few advantages for me, even for the same 5 commands I use over and over: - undo - shuffling commits around with squash, split, and rebase is much better than git\u2019s interactive rebase - make commits without having to come up with a branch name (I might make three versions of the same change in parallel to see how they compare) I see git is working on adding some of this under the history command. The revset language", "context": "", "use_case": "version control", "switched_from": "Git", "story": "The creator of Jujutsu has joined ERSC"}, {"id": 792479792, "item_id": 49529987, "url": "https://news.ycombinator.com/item?id=49529987", "by": "y1n0", "date": "2026-09-01", "stance": "recommend", "quote": "JJ is just so low friction.", "excerpt": "I was a skeptic until a few months ago. It\u2019s my daily driver now. I\u2019ve got sizable amount of people committing to the same repo, many are not skilled with git. So I deal with weird crazy \u201chow did you ever get the repo into this state\u201d issues not infrequently. JJ is just so low friction. The seamless and painless shuffling of commits, working up and down the commit chain without explicit rebasing, unchanging change-id", "context": "works with a repo with many committers, many not skilled with git", "use_case": "version control for team repo", "switched_from": "Git", "story": "The creator of Jujutsu has joined ERSC"}, {"id": 792462560, "item_id": 49528910, "url": "https://news.ycombinator.com/item?id=49528910", "by": "minraws", "date": "2026-09-01", "stance": "recommend", "quote": "since you can use jj in a git repo you can commit git stuff via git like submodules and then enjoy the world of jj", "excerpt": "1. Reflog is very ref specific that is it tracks head. JJ has op and evo logs that do that + a bunch more they track everything about the repo every possible action. It's hard to explain with going into technical depth but you can read up on it. 2. Yeah submodules aren't supported but since you can use jj in a git repo you can commit git stuff via git like submodules and then enjoy the world of jj. Since submodule in", "context": "", "use_case": "version control", "switched_from": "", "story": "The creator of Jujutsu has joined ERSC"}, {"id": 792432160, "item_id": 49527010, "url": "https://news.ycombinator.com/item?id=49527010", "by": "saghm", "date": "2026-09-01", "stance": "recommend", "quote": "I freely use it with git repos without any of my coworkers needing to use it as well", "excerpt": "My relatively ignorant take is that it's pretty similar to Mercurial, except that it's compatible with git repos, which is also the answer to why it might get more traction. At least from my standpoint, it also doesn't need to get traction, because I freely use it with git repos without any of my coworkers needing to use it as well (although they might! I have no idea, just like they probably don't know I use it)", "context": "", "use_case": "version control", "switched_from": "", "story": "The creator of Jujutsu has joined ERSC"}, {"id": 792426704, "item_id": 49526669, "url": "https://news.ycombinator.com/item?id=49526669", "by": "KajMagnus", "date": "2026-09-01", "stance": "recommend", "quote": "But with jj, no stress: I can just check in the conflicts, and later, on the other laptop: check out the conflicts and continue resolving.", "excerpt": "> As a trivial counter example Git does not currently have a way to store conflicts inside commits[1], which is one of our major features. Yes, I like how jj does it! Did a big `git rebase -i` yesterday and I felt stressed up, almost a bit angry, when there were some conflicts and I wasn't sure if I'd resolve all of them before it was time to leave, and work more later from a different laptop. But with jj, no stress:", "context": "", "use_case": "version control", "switched_from": "Git", "story": "The creator of Jujutsu has joined ERSC"}, {"id": 792425360, "item_id": 49526585, "url": "https://news.ycombinator.com/item?id=49526585", "by": "skipants", "date": "2026-09-01", "stance": "recommend", "quote": "I also use jj as my daily driver now. I like it a lot.", "excerpt": "the person you responded to has been a user since 2019. why do you think they artificially push it? I also use jj as my daily driver now. I like it a lot. I have no skin in the game either.", "context": "", "use_case": "version control", "switched_from": "", "story": "The creator of Jujutsu has joined ERSC"}, {"id": 792422480, "item_id": 49526405, "url": "https://news.ycombinator.com/item?id=49526405", "by": "sbuttgereit", "date": "2026-09-01", "stance": "recommend", "quote": "I prefer the JJ model of version control much more than Git's.", "excerpt": "\"Can do\" and \"can do easily\" or \"can do with minimal friction\" aren't the same. I use JJ locally and for those that call it a \"porcelain\" or a \"git UI\" are missing a lot. Sure you can use it that way, but what I've found is that it facilitates (and perhaps encourages) a pretty different workflow than I'd use with just plain Git. I could pull off what I do in JJ in just plain Git... but it wouldn't at all feel natural", "context": "", "use_case": "version control", "switched_from": "", "story": "The creator of Jujutsu has joined ERSC"}, {"id": 791626705, "item_id": 49476669, "url": "https://news.ycombinator.com/item?id=49476669", "by": "LoganDark", "date": "2026-08-28", "stance": "recommend", "quote": "my preferred version control system (jj)", "excerpt": "Just because it doesn't materially impact task success rates does not mean it's not useful. I use that file to give my agent information about the environment (operating system, architecture, command-line utilities I have installed), as well as how to do certain things (such as using `uv` for running Python when needed). I want my agent to work how I do, so I also tell it things like my preferred version control syst", "context": "", "use_case": "version control", "switched_from": "", "story": "Your AGENTS.md file doesn't do anything"}, {"id": 791142112, "item_id": 49446382, "url": "https://news.ycombinator.com/item?id=49446382", "by": "VulgarExigency", "date": "2026-08-26", "stance": "recommend", "quote": "jj can work with git as its storage, so all of its commits are git commits, so a jj-local and git-remote flow is fully supported. I use it", "excerpt": "jj can work with git as its storage, so all of its commits are git commits, so a jj-local and git-remote flow is fully supported. I use it, and as far as I know I'm the only one on my team doing so.", "context": "only one on team using it", "use_case": "version control with git remotes", "switched_from": "", "story": "Maiao: Gerrit-style code review workflow for GitHub, GitLab, Gitea, others"}, {"id": 789369872, "item_id": 49335617, "url": "https://news.ycombinator.com/item?id=49335617", "by": "AndrewHampton", "date": "2026-08-17", "stance": "recommend", "quote": "I love jj", "excerpt": "I love jj and am a fan of the ideas of AT protocol, so tangled has been on my radar for a while. Last I checked though, it sounded like it was much better suited for open source code, not private repositories. Is that still the case?", "context": "", "use_case": "version control", "switched_from": "", "story": "Ask HN: Alternatives to GitHub"}, {"id": 787281456, "item_id": 49205091, "url": "https://news.ycombinator.com/item?id=49205091", "by": "giodamelio", "date": "2026-08-06", "stance": "recommend", "quote": "which Jujutsu makes so damn easy via megamerges", "excerpt": "It's not anywhere near making PR ready (and never will be) but here is the branch [1]. I make no promises on it's functionality, and I only periodically rebase Herdr's latest over it. I have been using the jj change for awhile though with no issues. So YMMV. You can also see the combined output of all my changes at [2], which Jujutsu makes so damn easy via megamerges. 1: https://github.com/giodamelio/herdr/tree/jj-wo", "context": "", "use_case": "version control", "switched_from": "", "story": "Herdr is joining Y Combinator. The runtime stays open"}, {"id": 787262721, "item_id": 49203920, "url": "https://news.ycombinator.com/item?id=49203920", "by": "giodamelio", "date": "2026-08-06", "stance": "neutral", "quote": "add jj workspace support", "excerpt": "It's super important to me. I use Herdr every day and I maintain a whole stack of changes. From minor comfort tweaks that are just preference, to several larger changes like add jj workspace support and a WIP web based view (powered by xterm.js). This is not the only project like this too. Many of my devtools are piling up changes. I try to upstream changes where it makes sense, but many times they are either very be", "context": "maintains personal patches to devtools", "use_case": "version control in Herdr", "switched_from": "Git", "story": "Herdr is joining Y Combinator. The runtime stays open"}, {"id": 785994416, "item_id": 49124651, "url": "https://news.ycombinator.com/item?id=49124651", "by": "Shish2k", "date": "2026-07-31", "stance": "recommend", "quote": "I love JJ and stacked diffs with Gerrit and Phabricator", "excerpt": "I am confused - I love JJ and stacked diffs with Gerrit and Phabricator, but trying to port that same \"each commit gets reviewed individually, and things don't break when a half-reviewed stack gets rebased\" workflow to GitHub has been a nightmare, how does JJ help?", "context": "", "use_case": "stacked diffs", "switched_from": "", "story": "Stacked PRs are now live on GitHub"}, {"id": 785930512, "item_id": 49120657, "url": "https://news.ycombinator.com/item?id=49120657", "by": "sarthak-ag", "date": "2026-07-31", "stance": "recommend", "quote": "JJ is much more than that. One of the other features I use quite heavily is that, in JJ, you can essentially check out multiple branches at the same time", "excerpt": "Yes, and in fact, JJ is much more than that. One of the other features I use quite heavily is that, in JJ, you can essentially check out multiple branches at the same time by just creating a local merge. JJ will keep your local merge updated as you rebase the branches it builds on. I have written about it here: https://sarthakag.bearblog.dev/from-git-to-jj-jujutsu/", "context": "", "use_case": "version control, stacked branches", "switched_from": "Git", "story": "Stacked PRs are now live on GitHub"}, {"id": 785930192, "item_id": 49120637, "url": "https://news.ycombinator.com/item?id=49120637", "by": "sarthak-ag", "date": "2026-07-31", "stance": "recommend", "quote": "If your workflow is rebase heavy, I strongly recommend ignoring this github feature and using jj instead.", "excerpt": "If your workflow is rebase heavy, I strongly recommend ignoring this github feature and using jj instead. I have written about my experience here: https://sarthakag.bearblog.dev/from-git-to-jj-jujutsu/", "context": "", "use_case": "rebase-heavy version control", "switched_from": "Git", "story": "Stacked PRs are now live on GitHub"}, {"id": 785699488, "item_id": 49106218, "url": "https://news.ycombinator.com/item?id=49106218", "by": "grahamas", "date": "2026-07-29", "stance": "recommend", "quote": "it looks ideal for my workflow, but I\u2019d never heard of jj before right now", "excerpt": "What would be the gotchas of doing this? I just spent some time looking into it and it looks ideal for my workflow, but I\u2019d never heard of jj before right now. As far as I can tell the problems would be: 1. Worse-for-humans PR history (I currently use this for major feature checkpoints and human-involved sanity checks and review) 2. Maybe some tooling issues with IDEs? Looks like it\u2019s all there, but maybe getting it ", "context": "", "use_case": "version control for agent workflows", "switched_from": "", "story": "Show HN: A local merge queue for parallel Claude Code agents"}, {"id": 785685328, "item_id": 49105333, "url": "https://news.ycombinator.com/item?id=49105333", "by": "BeetleB", "date": "2026-07-29", "stance": "recommend", "quote": "Whereas with jujutsu, after learning it once, I never looked up `split`.", "excerpt": "I've used git for many years and never remembered the command `git reset -p`. I'd have to look it up. Since that's a pain, I simply didn't. Whereas with jujutsu, after learning it once, I never looked up `split`. And it's not like I use `split` often. I can go weeks without it.", "context": "", "use_case": "version control, splitting changes", "switched_from": "Git", "story": "Staging patches with Git add -p"}, {"id": 784862241, "item_id": 49053890, "url": "https://news.ycombinator.com/item?id=49053890", "by": "jauntywundrkind", "date": "2026-07-25", "stance": "recommend", "quote": "moving to jj, it has lots of amazing tools starting with `jj edit` to go change the past safely & conveniently", "excerpt": "rebase interactive is so great, such a powerful tool. it's the one clear tool that i used all the time. moving to jj, it has lots of amazing tools starting with `jj edit` to go change the past safely & conveniently, with much less pain. but i miss the direct powerful data-driven experience of seeing the timeline in a text file, and picking what to do with it. sometimes. imo every dev should work to get some competenc", "context": "", "use_case": "version control", "switched_from": "Git", "story": "Git rebase -I is not that scary"}, {"id": 782505136, "item_id": 48906571, "url": "https://news.ycombinator.com/item?id=48906571", "by": "steeleduncan", "date": "2026-07-14", "stance": "recommend", "quote": "I love JJ, and the mental model of source control it presents, and I will continue to use it.", "excerpt": "In princple JJ has non-Git backends, but the only backend they state as being production ready is the Git backend. JJ without the Git interop is more a concept than a reality right now. I love JJ, and the mental model of source control it presents, and I will continue to use it. However, still needing to \"drop down\" to Git every now and again to get something done makes it feel very much like a convenient wrapper on ", "context": "", "use_case": "version control", "switched_from": "Git", "story": "The Git history command deserves more attention"}, {"id": 782498320, "item_id": 48906145, "url": "https://news.ycombinator.com/item?id=48906145", "by": "klibertp", "date": "2026-07-14", "stance": "recommend", "quote": "If you can give `jj` a try on a greenfield, single-developer project, you probably should.", "excerpt": "IME, the only real pain point with JJ is Git integration. I love it, it's great in almost everything it does. Formalizing all the DSLs and using them consistently throughout the config and CLI is exactly how filesets, revsets, and templating should be implemented. The focus on exposing concepts as interfaces (without \"directly reflecting internals\"[1] in the UI) is only as good as the concepts themselves, and in JJ's", "context": "", "use_case": "version control", "switched_from": "", "story": "The Git history command deserves more attention"}, {"id": 782433792, "item_id": 48902112, "url": "https://news.ycombinator.com/item?id=48902112", "by": "chandlerswift", "date": "2026-07-13", "stance": "recommend", "quote": "I use the `jj` equivalents all the time.", "excerpt": "I've been theoretically a big fan of these commands; I use the `jj` equivalents all the time. The roadblock I've run into is that I as far as I can tell (from the man pages and the git source code) there's no way to get `git history` commands to sign commits they modify: $ git log --oneline --show-signature # look ma, I signed my commits! 3a1dd8f gpg: Signature made Mon 13 Jul 2026 10:45:50 PM CDT gpg: using RSA key ", "context": "", "use_case": "version control history editing", "switched_from": "", "story": "The Git history command deserves more attention"}, {"id": 781951665, "item_id": 48871979, "url": "https://news.ycombinator.com/item?id=48871979", "by": "xlii", "date": "2026-07-11", "stance": "recommend", "quote": "For Git I use Jujutsu (so I stopped using Magit long time ago)", "excerpt": "Obviously Kakoune is much simpler than Emacs, so face variability, very interactive UI is not there (though there'd be nothing preventing writing it, but I doubt anyone wants it enough). As for transition - I always was somewhat of an UNIX guy, so I replaced Swiper/Occur/Consult with delegating to shell. Kakoune has just enough utilities to create a on-keystroke-updated-buffer so I'm happy with that. In some language", "context": "", "use_case": "version control", "switched_from": "Magit", "story": "Good Tools Are Invisible"}, {"id": 781763904, "item_id": 48860244, "url": "https://news.ycombinator.com/item?id=48860244", "by": "galoisscobi", "date": "2026-07-10", "stance": "neutral", "quote": "I use jj vcs and now most of my time is spent reading the code", "excerpt": "I use jj vcs and now most of my time is spent reading the code, so I use diffview.nvim (https://github.com/sindrets/diffview.nvim) with some customizations for jj to read diffs. I also use the snacks picker/explorer to search for code.", "context": "", "use_case": "version control", "switched_from": "", "story": "How do you use Vim in the era of AI?"}, {"id": 781019488, "item_id": 48813718, "url": "https://news.ycombinator.com/item?id=48813718", "by": "1123581321", "date": "2026-07-06", "stance": "recommend", "quote": "I use it exclusively, but still in colocated mode", "excerpt": "I use it exclusively, but still in colocated mode so it\u2019s compatible with contributors who use git, and GitHub. I\u2019ve run into a few issues with colocated (had to fix staleness several times per year, for example) but compatibility overall hasn\u2019t blocked me.", "context": "", "use_case": "version control", "switched_from": "", "story": "Ask HN: Is anyone using Jujutsu version control (JJ) exclusively?"}, {"id": 779671696, "item_id": 48729481, "url": "https://news.ycombinator.com/item?id=48729481", "by": "nchmy", "date": "2026-06-30", "stance": "recommend", "quote": "Jj can do essentially anything git can.", "excerpt": "Glad you discovered that you were missing this. Jj can do essentially anything git can. Check out jjui - it makes it all that much more simple.", "context": "", "use_case": "version control", "switched_from": "", "story": "Evan's Jujutsu Tutorial"}, {"id": 779527840, "item_id": 48720490, "url": "https://news.ycombinator.com/item?id=48720490", "by": "neprotivo", "date": "2026-06-29", "stance": "recommend", "quote": "Jujutsu\u2019s features give us a compact solution based on filesets, revsets, and `git.private commits`.", "excerpt": "Hi HN, I wrote up a Jujutsu workflow that I came up with recently. I wanted to work on a public open-source repository while also versioning the private context files that influenced each public commit: specs, product notes, experiments, and agent instructions. I use coding agents heavily, which means the specs are often as important as the final code. I wanted a proper way to manage them without making them reachabl", "context": "uses coding agents heavily", "use_case": "split public and private files", "switched_from": "", "story": "Projection: A JJ Workflow for splitting public and private files"}, {"id": 778256160, "item_id": 48641010, "url": "https://news.ycombinator.com/item?id=48641010", "by": "dbt00", "date": "2026-06-22", "stance": "recommend", "quote": "I use a new VCS already (jj, highly recommended)", "excerpt": "I use a new VCS already (jj, highly recommended) and Claude forgets to use it all the time despite many obvious instructions in many places.", "context": "", "use_case": "version control", "switched_from": "", "story": "Git is forever. I'm building Oak anyways"}, {"id": 778219632, "item_id": 48638727, "url": "https://news.ycombinator.com/item?id=48638727", "by": "LoganDark", "date": "2026-06-22", "stance": "neutral", "quote": "I like to clone my repos without colocation, but then sometimes find that I need to re-colocate in order to `git submodule update`.", "excerpt": "Submodules are cursed, but I like to clone my repos without colocation, but then sometimes find that I need to re-colocate in order to `git submodule update`. Relatedly, when I use filesystem paths as remotes they need to be colocated or else it doesn't work, which is a little annoying!", "context": "", "use_case": "version control", "switched_from": "", "story": "Git is forever. I'm building Oak anyways"}, {"id": 778145616, "item_id": 48634101, "url": "https://news.ycombinator.com/item?id=48634101", "by": "zdgeier", "date": "2026-06-22", "stance": "recommend", "quote": "I love jj! Martin is really awesome and love his work.", "excerpt": "I love jj! Martin is really awesome and love his work. I know they're using a VFS backing inside Google for their monorepo, wonder if we'll get some of those cool features on the outside.", "context": "", "use_case": "version control", "switched_from": "", "story": "Git is forever. I'm building Oak anyways"}, {"id": 778116544, "item_id": 48632284, "url": "https://news.ycombinator.com/item?id=48632284", "by": "LoganDark", "date": "2026-06-22", "stance": "recommend", "quote": "It's absolutely great for keeping a bunch of exploratory changes alive, quick prototyping, etc.", "excerpt": "Seconding Jujutsu! I've been working to add Jujutsu support to basically every open-source tool and framework I use, including the agentic ones [0]. While it doesn't work for everyone, I've found it can really work for some people. (like myself) It's absolutely great for keeping a bunch of exploratory changes alive, quick prototyping, etc. as I tend to do with basically every source I have on my machine. I don't have", "context": "", "use_case": "version control, exploratory changes", "switched_from": "Git", "story": "Git is forever. I'm building Oak anyways"}, {"id": 773893504, "item_id": 48368344, "url": "https://news.ycombinator.com/item?id=48368344", "by": "mos3abof", "date": "2026-06-02", "stance": "recommend", "quote": "I have been using jj (jujitsu-vcs) for a while now", "excerpt": "I have been using jj (jujitsu-vcs) for a while now, but dealing with Github has been a struggle, especially when working with other on the same repo. That was until I found \"jellycat\", which is a jellyfish inspired CLI for dealing with Github and jj! The tool's creator worked on Facebook's (sorry, Meta!) internal source control, which imho is one of the best ecosystems that I have ever seen. In fact, I was using sapl", "context": "", "use_case": "version control", "switched_from": "Sapling", "story": "Jellycat: a Rust CLI for Turning Jujutsu Changesets into GitHub PR Stacks"}, {"id": 773726768, "item_id": 48357923, "url": "https://news.ycombinator.com/item?id=48357923", "by": "mamcx", "date": "2026-06-01", "stance": "recommend", "quote": "THEN, I move to jujutsu.", "excerpt": "I use rerere when \"forced\" by team to use rebase. It not even work that much at the end (you can't control workflows outside yourself, that is why git ux is wrong: it desperately need total discipline). THEN, I move to jujutsu. Only has a few problems at start trying to use it as git, but after get the idea, all fine. BTW, this was with the same team and they never know, so JJ is in fact better: It survive OTHERS wor", "context": "", "use_case": "version control", "switched_from": "Git", "story": "Using Git's rerere feature to escape recurring conflict hell"}, {"id": 770797744, "item_id": 48174859, "url": "https://news.ycombinator.com/item?id=48174859", "by": "tekacs", "date": "2026-05-17", "stance": "recommend", "quote": "I use it in all my Git-underneath repos with `jj git init --colocate`", "excerpt": "https://github.com/jj-vcs/jj On the off chance that you haven't already had this suggested to you on HN, I would suggest taking a look at JJ. I use it in all my Git-underneath repos with `jj git init --colocate` (You can run that in a git repo and it will hybridize, or in a new folder and it will init and hybridize). It doesn't have the staging concept, treating the working copy as just another commit (@), and to boo", "context": "", "use_case": "version control on top of git", "switched_from": "", "story": "Mercurial, 20 years and counting: how are we still alive and kicking? [video]"}, {"id": 764258320, "item_id": 47766145, "url": "https://news.ycombinator.com/item?id=47766145", "by": "kevin_nisbet", "date": "2026-04-14", "stance": "warn", "quote": "I really wanted to like JJ, it was handy for a few months when I used it. But for me in the end I reverted back to regular git.", "excerpt": "I really wanted to like JJ, it was handy for a few months when I used it. But for me in the end I reverted back to regular git. What triggered me to go back was I never got a really clean mental model for how to keep ontop of Github PRs, bring in changes from origin/main, and ended up really badly mangling a feature branch that multiple contributors were working on when we did want to pull it in. I'll probably try it", "context": "works in a team via GitHub PRs", "use_case": "version control with GitHub PRs", "switched_from": "", "story": "What is jj and why should I care?"}]}