10 ms·

I see a future in jj

376 points by steveklabnik 1y ago

pityJuke 1y ago
Off-topic: I found it very surprising the Logical Awesome website still works.
- steveklabnik 1y ago
  I'll be honest, I did too. No https cert makes it give a warning in Chrome, which I had expected to just be a 404, and was surprised when it actually worked!
joshstrange 1y ago
I guess I see what the author was trying to convey talking about Rust/Go at the start but I'll admit it confused the hell out of me when we got to Jj (horrible name IMHO but whatever). Jj is a VCS, it was not at all clear (to me) until I got further and I was very confused as to why we were talking so much about source control (I thought Jj was a language since the article started by talking about Rust/Go). Apparently Jj can work on/with git repos making it easier to adopt incrementally which is neat and the main point of this post is that the author is leaving Oxide to go work for a new company trying to to create the GitHub of Jj (my understanding at least). I hope this helps someone else who might be confused like I was.
- steveklabnik 1y ago
  Thank you for the feedback! I talk about it so much I feel like regular readers of my blog will know this stuff already, but I also don't want to leave out important context for others. I tried to help fix this in https://github.com/steveklabnik/steveklabnik.com/pull/125/files https://github.com/steveklabnik/steveklabnik.com/pull/125/fi..., thanks again!
  - simultsop 1y ago
    If you're asked why Rust. I believe you are always free to choose.
- sunshowers 1y ago
  The full name is Jujutsu, but I think "jj" did come first. "j" is nice because on QWERTY keyboards, not only is it on the home row, it is one of the two keys that has a little tactile marker (bump) on it.
Bolwin 1y ago
Since JJ has technically git compat, I think there's 2 things needed for it to take off 1. A good vscode extension (there's two so-so ones that I'm not sure are being updated) 2. LLM knowledge. I ask gpt-5 about doing something in jj the other day, it didn't even recognize it at first. When I reminded it it was a vcs it hallucinated half the commands. I ended up figuring it out myself from the docs
- steveklabnik 1y ago
  I do think that GUI stuff is important, there's a lot of folks who have said "not interested unless there's a magit equivalent" which I totally understand. I'm not a big GUI person for VCS myself, so I don't feel the same pain. For LLMs, yeah this is hard for any new project. I use Claude Code, and it does a decent job with jj, it only tries to do git stuff sometimes. I haven't asked ChatGPT about it though, I'll have to experiment with it myself.
  - Bolwin 1y ago
    Since they guy behind it works at Google, I wonder if gemini is better at it.
    - steveklabnik 1y ago
      I don't think Google is best though of as a singular entity, I'd very seriously doubt that if it is, it's because of this.
    - victorbjorklund 1y ago
      Doubt the gemini team handpicks training material based on wether the author works at google or not. Doubt they handpick it at all.
      - p_l 1y ago
        Both Claude and Gemini can be integrated reasonably by informing them how to use JJ commands or even through MCP
kelnos 1y ago
At the risk of being unreasonably negative, stuff like this just makes me feel... tired. Git is... fine. I'm sure it doesn't solve every problem for everyone, and oh boy does it still have many rough edges, but it works and (as the article points out), git has won and is widely adopted. I've extensively used CVS and Subversion in the past. I touched Mercurial and Bazaar when I ran into a project that used it. I remember in the CVS days, SVN was exciting to me, because CVS was such a pain to use, in almost every way. In the SVN days, git was exciting to me, because SVN still had quite a few pain points that poked me during daily use. Again, yes, git had and has rough edges, but nothing that would make me excited about a new VCS, I don't think. Maybe I'm just getting old, and new tools don't excite me as much anymore. Learning a new tool means spending time doing something that isn't actually building, so my eventual use of the new tool needs to save me enough time (or at least frustration, messily converted into time units) to balance that out. And I need to factor in the risk that the new tool won't actually work out for me, or that it won't end up being adopted enough to matter. So I think I'll wait on jj, and see what happens. If it ends up becoming a Big Deal, I'll learn it.
- steveklabnik 1y ago
  I think being conservative about tool use is totally fine! I'm actually pretty conservative about most of the tools that I use. The goal of this post wasn't really to convince anyone on why they may want to give jj a shot, more of just a post about how I think about technologies I may want to spend my limited time on this planet working on, and announce that I'm making a move. I don't think that you're being unreasonably negative. I think it's crucial for technologies to understand that your position is basically the default one, and that you need to offer a real compelling reason to choose a new tool. For some people, jj has enough of that already to bother with choosing, but I think the real power is in things that aren't widely available yet. Hence the need to go build some stuff. It's early days! Not even 1.0 yet. It's very natural that most people do not care at this stage.
  - jimbokun 1y ago
    One thing not mentioned in the article: what advantages does jj offer over plain git?
tomstuart 1y ago
Congratulations on the new adventure, Steve, and good luck!
davidkunz 1y ago
jj describe -m "Good luck, Steve!"
- steveklabnik 1y ago
  Thanks!
drcongo 1y ago
Congrats on the new role, sounds exciting - looking forward to seeing where it goes!
- steveklabnik 1y ago
  Thanks so much!
baq 1y ago
I’m just sad pijul doesn’t get the same attention or love from the community. It desperately needs an ability to colocate with git.
- mirashii 1y ago
  I think that the ability to collocate with fit is really the thing that makes even evaluating the use of jj feasible in many organizations. To consider pijul, it requires throwing away all of your forge setup, configuration, permissions, backup, disaster recovery, as well as updating every CI pipeline. In a very real way, git won, and the inertia behind git is higher than it was for any VCS tool before it, and so just being better isn’t going to be enough, you’ll also need to interoperat.
- dagenix 1y ago
  I strongly suspect that its not feasible to colocate pijul and git. git and jj are based on snapshots, while pijul is based on patches. They have very different models.
  - baq 1y ago
    As long as some repository state in either system can map onto a checkout in the other system it should be possible at least in some capacity. I’d like to try out pijul at work, but I’d need an analog of jj git fetch and jj git push. Whatever happens in between doesn’t really matter too much unless it’s tedious manual bookkeeping to maintain history mapping.
- coastalpuma 1y ago
  Agree, the feature of commutative patches just seems obviously superior? Not sure why there's a critical mass to adopt jj over Pijul apart from jj's git backend.
  - steveklabnik 1y ago
    I think this gets at one of my original comments in this thread: I think the reason of commutative patches has communication issues. The benefits touted are very abstract. The problems I’m aware of it solving are mostly theoretical problems for working devs, and so the message hasn’t landed. If I were interested in advocating for these tools, I’d be trying to find a message that does resonate.
bagxrvxpepzn 1y ago
[flagged]
- sunshowers 1y ago
  > There are no substantial technical or usability reasons to switch to JJ from Git [...]. This is a neutral impersonal opinion that is virtually a fact. I respect your opinion, but I don't think it's a fact and I couldn't disagree any further with it. I wrote a whole testimonial about why I love jj (first one there): https://jj-vcs.github.io/jj/latest/testimonials/#what-the-users-have-to-say https://jj-vcs.github.io/jj/latest/testimonials/#what-the-us... > it's impractical for most working programmers to switch I don't know what you mean here. I think it's quite practical to switch to jj, and people switch over all the time. Some people are going to be earlier adopters than others, but the early adopters can bring others along (as I've been lucky to do at Oxide). > focus on something whose main appeal is more than social Steve and I both think that Jujutsu's appeal is far more than merely some bandwagon effect. I do think that social appeal is an important part of making a project succeed, and that projects without substantial technical merit win due to social appeal all the time, but Jujutsu has both! It's amazing!
  - bagxrvxpepzn 1y ago
    > I respect your opinion Thank you for charitably responding to the substance of my comment and especially not whatever tone you may have perceived. I appreciate you.
    - beaker52 1y ago
      Perhaps take a look at jj and give it a go. Maybe you’ll like it. I know I did. The fact I can use it with git and it doesn’t interfere with any GitHub PR workflows means no-one needs to know I use it. I enjoy the jj model. Maybe you could too, and it’s not a crazy investment of time and energy. It’s an evening playing around with a code kata or something. Then working with vcs becomes that little bit more enjoyable.
- mirashii 1y ago
adamwk 1y ago
I joined the sapling/subversion company this year, but haven’t had the chance to use jj. But given its resemblance I must say sapling has been great. Much more intuitive than git, and I find commit stacks much easier to follow than branches. I do wonder how it will work without the level of support of Meta, since you won’t have the same commit stack review UI (basically a series of pull requests being reviewed at the same time). So something like what this author is working on is needed.
- steveklabnik 1y ago
  Yeah, sapling and jj are fellow travelers, for sure :)
jmercouris 1y ago
After reading the article, the technical merits of `jj` are completely unclear.
- archargelod 1y ago
  The article can be summarized to essentially: I like Rust. jj is written in Rust. Some Rust person loves jj. jj is used at Google. Who upvotes this?
  - steveklabnik 1y ago
    I can’t speak to people’s motivations, but I have been a very active member on this forum for a long time, and I was on the Rust team for about a decade, beginning before 1.0. So the article is more like “Here’s why I started using Rust. If you thought I made a good choice then, well, I’m making a similar choice in case you want to join me.” Seems people find that compelling. Just like Rust’s success was not inevitable, neither is jj’s. But I think it might work out. You could also consider this a disclosure of sorts, I post a lot on this forum about jj (and Rust), and so knowing that I now have a financial incentive is important context to some people.
- steveklabnik 1y ago
  Yes, that was not the goal of the post. There's some comments about this in this thread though, here's the first one of mine: https://news.ycombinator.com/item?id=45673808 https://news.ycombinator.com/item?id=45673808
  - svat 1y ago
    That URL https://news.ycombinator.com/user?id=steveklabnik https://news.ycombinator.com/user?id=steveklabnik is a link to your user profile.
    - steveklabnik 1y ago
      Whoops, managed to fix it. Thank you!
weinzierl 1y ago
I think the real news is that some people have started to build what might become something like a "jjhub". https://ersc.io/ https://ersc.io/
- steveklabnik 1y ago
  I think 'jjhub' is a decent immediate first approximation, and is often how I've started out talking about it with people. At the same time, we have to offer real value here, as you can already use jj with github (and I have for a long time now), so there's more to it than that. But yes :)
  - davidkunz 1y ago
    What I would love: - Everything locally stored in the repo: PRs, comments, issues, discussions, boards, ... - CLI first - Offline first (+ syncing) - A website for hosting/presentation
    - steveklabnik 1y ago
      Noted :) In another comment I linked to beads, which is a cool project to keep your issue tracker in your repo, but that's just a personal thing, no comment on what the company plans to do (or not) in this area.
      - antonchekhov 1y ago
        I use command-line tooling much more than IDEs (e.g. VS Code), so the `gh` command-line tool (https://cli.github.com https://cli.github.com) for doing most of the usual hub-oriented workflow (PR authoring, viewing issues, status updates, etc) really helps a lot - I don't have to constantly <cmd>+<tab> to my browser, and point-click-point-click through web pages so much. It would be fantastic if ersc or any other jj-centered code-sharing hub had similar tooling early on.
        steveklabnik 1y ago
mh9r 1y ago
I tried Jujutsu in the last day and was going through your tutorial. I really liked the experience and can see some potential. I also got the feeling that there is a missing puzzle piece. For example, do I get any benefit from the change id if I push to GitHub for PR review? I guess you benefit from some of the good parts only with the Google internal Piper backend, at the moment. So I’m curious about the ideas and plans you have at ERSC. But what I’m also really yearning for is having a distributed asynchronous/offline-first code review flow built right in. The distributed nature of git somehow got lost with PRs or MRs in GitHub & Co.
- steveklabnik 1y ago
  Glad to hear you enjoyed it :) > do I get any benefit from the change id if I push to GitHub for PR review? As of right now? Not really. The details are more complicated, but basically, if your project doesn't like the behavior of github when it comes to comments + editing commits, and wants you to tack on new commits instead, we can't change that behavior. However, https://github.com/LucioFranco/jj-spr https://github.com/LucioFranco/jj-spr can, in some situations, give you some of this experience. If your project is okay with editing commits, then it can help you locally, sure. However. In an interesting turn of developments, GitHub's new SVP just tweeted that he's likes jj and is interested in adding stacked diffs to github. I don't know how this squares with their "no new features for 18 months" thing, but we'll see! > But what I’m also really yearning for is having a distributed asynchronous/offline-first code review flow built right in. It's not code review, it's issue tracking, but I've been using https://github.com/steveyegge/beads https://github.com/steveyegge/beads this week, and I think it might be the first "put your issues in your repo" system I actually enjoy. It says it's built for AI stuff, but like, you don't have to use AI with it.
- CGamesPlay 1y ago
  One thing to note is that the actual commit objects you make through jj do include a `change-id` header which means that even though Github is unaware of jj, peers using jj will still be able to keep track of the rebases. Demo: run `git cat-file -p HEAD` in any jj repository that you've made a change to.
j2kun 1y ago
> I also don’t mean to imply that everyone at Google is using jj, but the contingent feels significant to me, given how hard it is to introduce a new VCS inside a company of that size. I don't mean to imply that Google is fickle, but anything besides Google's perforce fork is deprecated every few years. We used to have a proper git wrapper, then mercurial+extensions, now jj is supposed to replace the mercurial thing, all in 7-ish years?
- steveklabnik 1y ago
  The intention with this is to also deprecate the Perforce fork, in my understanding. But yeah, it's been a lot. Frankly even harder to keep track of from the outside!
- joshuamorton 1y ago
  I don't think this is quite right. The git wrapper was never fully supported and had some rough edges (I think it was only ever a 20% project, and also its, like, really old). And the customized mercurial has been around for more than 7 years, I think close to a decade (the client I'm using right now is turning 7, and it wasn't my first one).
  - j2kun 1y ago
    I started using git as my daily driver at Google in 2018. I was forcibly kicked off it for mercurial in 2020. The deprecation plan for mercurial is 2026 IIUC. Maybe if you adopted mercurial early it's different.
    - yomismoaqui 1y ago
      What was the reason for using Mercurial?
      - j2kun 1y ago
        Why did Google decide to choose Mercurial? Based on what I read the main reason was that the mercurial dev team was willing to prioritize features needed for Google to add custom extensions to support its monorepo, and the git dev team wasn't going to reprioritize just for the sake of Google.
Pet_Ant 1y ago
One thing I've wanted is the ability to group commits into a mega commit. So the history of little changes remains, but as you are scrolling you don't see all of them.
- steveklabnik 1y ago
  This is an interesting idea... jj has a templating language, but it's not stateful, so you couldn't like, hide some commits based on other commits, for example. But I'll file this away...
  - Pet_Ant 1y ago
    I've thought that it could be as simple as commit's with a message beginning with "minor:: " do not get shown by default.
    - steveklabnik 1y ago
      Hmm, yeah that might work. I was thinking about grouping all “minor::” commits as one commit, but this sounds more feasible.
- eddd-ddde 1y ago
  You could probably use bookmarks for this.
- 1718627440 1y ago
  That's called a merge commit. You can even group them further by creating merges of merge commit. It requires you to merge in the right direction though.
  - steveklabnik 1y ago
    That doesn’t really hide them in the UI though.
    - 1y ago
stonecharioteer 1y ago
Steve, Rain, please call it dojo.dev or something before jjhub catches on.
- steveklabnik 1y ago
  Rain’s not working at ERSC, but we won’t be naming the product jjhub, don’t worry.
zephraph 1y ago
So excited for this. I talked to the ERSC folks last year about joining but it was a little early for me. Still incredibly excited about what they're building and glad to see one of my favorite people joining the effort. Steve, if you come to NYC hit me up!
- steveklabnik 1y ago
  Thank you! I’ll try to remember that.
deleted 1y ago
[deleted]
mrbonner 1y ago
Is there a jj tutorial not assuming git knowledge at all? I'd love to see how to approach jj without git.
- steveklabnik 1y ago
  Not really, but I think there should be.
- dcre 1y ago
  Someone attempted that a couple of months ago: https://jj-for-everyone.github.io/ https://jj-for-everyone.github.io/ Discussion: https://news.ycombinator.com/item?id=45083952 https://news.ycombinator.com/item?id=45083952
TinkersW 1y ago
Does it work with large binary files and not choke like git? Cause git may have won for webdev etc, but in some industries such as gamedev, Perforce is the king... git is barely used at all because it can't handle binary files worth a damn(yes I know about the large file extension, no it isn't sufficient).
- steveklabnik 1y ago
  Right now, nothing special. But this is very much an area that's known about and something may happen in this area, we'll see.
  - tombert 1y ago
    If you could elegantly handle large or frequently-changing binaries I think I'd be willing to switch immediately. It has always annoyed me that there's not any clever way to handle binary changes with version control.
- jasonpeacock 1y ago
  Perforce’s binary support is basically equivalent to Git LFS, it does the same thing. What does Perforce binary support have that Git LFS doesn’t? AFAIK, the base issue that Perforce is already in use and it has enterprise support.
  - dafelst 1y ago
    I am the last person to ever promote perforce, but as of last yearish it has the option for binary delta transfer using fastCDC. Even without that, it is a just straight up a lot faster than git lfs. I know this because I benchmark it against git pretty frequently as I am creating my own large file capable VCS.
  - bananaboy 1y ago
    What do you mean by this? It's hardly equivalent to LFS. The binary files aren't replaced with a text pointer with actual content stored on a server elsewhere. Binary files are stored in the same place as text files.
jonstewart 1y ago
What I miss from the Perforce and Subversion days is committing directly to trunk in a team environment. Now everything revolves around PRs and lengthy code review. With direct commits to trunk, everyone was in a rush to get their commit in before someone else did, so they didn’t have to update and have conflicts. This made commits small, frequent, and usually well-scoped. What -sucked- was when you did need to do a large refactoring or other big change, then that was work best done on a weekend because branching and merging didn’t work very well. Git’s model is right for PRs for open source projects where one day you could wind up with code from someone you don’t know and you need to take your time in review and possibly making further changes before merging. But as much as git’s a meaningful upgrade over Perforce and (especially) Subversion, branching and merging is not the right default model for normal team development.
- cozzyd 1y ago
  You can totally use that workflow with git.
  - jonstewart 1y ago
    I know but tell that to GitHub/Gitlab/BitBucket/etc.
- ivolimmen 1y ago
  PR's are a man made ritual that was never required by GIT. Just like we are all doing the Lean/Scrum or whatever dance. It does not change the development process, it's just a man made ritual for collaboration. The branching model is nicer to work with than the revision based model from subversion though.
- philipwhiuk 1y ago
  > then that was work best done on a weekend I mean that's just toxic.
  - jonstewart 1y ago
    So was CVS!
tmtvl 1y ago
Does JJ have equivalet functionality to git's format-patch and am? Because I, for one, am rather fond of the e-mail based workflow and not having that would make JJ a no-go for me.
- steveklabnik 1y ago
  There hasn’t been a ton of desire for it because it’s easy to just run git format-patch. Jj’s workflows feel closer to the email workflow than not, but prioritization in a young project is tough.
- Iwan-Zotow 1y ago
  Oh man...
oefrha 1y ago
I gave jj two honest tries. While first class conflicts is a cool idea, in practice I deal with staging/committing 30x more than conflict resolution, and coming from magit, using jj’s hunk split & select felt like being thrown into stone age. Plus I rebase a lot and get a lot of jj’s benefits from magit’s various rebase shortcuts already, IIRC first class conflicts was the only truly novel thing I didn’t have. For people like me who stage/commit often and judiciously I don’t think jj will beat magit until its hunk selection UX comes close.
- ModernMech 1y ago
  Oh wow, they were going for "magic" with that name?? I read it as "maggot".
- dcre 1y ago
  I’m curious what the magit hunk selection UX consists in. I couldn’t find any videos showing something substantially different from the one built into jj — the videos I found were meant as beginner intros. I’ve never used magit but I used GitUp (https://gitup.co/ https://gitup.co/) for years before jj. I don’t find the jj one super natural, but I feel like that’s mostly a matter of keyboard shortcuts — I need to see if they can be customized.
  - chrchr 1y ago
    There's more than one way to do it, but the very normal UX is that you can just scroll through the diff file-by-file and stage/stash/drop each hunk individually by placing your cursor over it and issuing the appropriate command. You can do the same with files, staging/stashing/dropping changes to a file by placing the cursor on its name and issuing a command.
    - aardvark179 1y ago
      Crucially you can also select a region within a chunk and perform those commands, so it’s easy to untangle changes.
RustSupremacist 1y ago
This is one person's career move that is defended by the idea that they somehow always make good bets. This is more than a bit arrogant. Past performance is no guarantee of future results. I don't see a future for this. I see a series of blog posts that culminate in a tone deaf "What went wrong" finale.
- steveklabnik 1y ago
  I certainly don’t think anything is a sure thing.
  - ivolimmen 1y ago
    Death and taxes though...
- deleted 1y ago
  [deleted]
yomismoaqui 1y ago
For all its warts and less than stellar UX Git is good enough (from a former Mercurial user)
jjmarr 1y ago
I'm kind of ambivalent about jujutsu. There's too big of an impedance mismatch between GitHub PRs and jujutsu, nor does it have a good VS Code UI. I only use it when I have a ton of minor PRs I want to work on simultaneously, otherwise I just do git worktrees. I'm mainly in favour because my name is JJ and sharing my name with a widely-used source control tool might help my career.
- Hasnep 1y ago
  I've been enjoying the jujutsu kaisen VSCode extension, you just need to disable VSCode's built in git integration for each project where you use jj (although I'm planning to invert by disabling git globally and then only enable it for the few projects where I don't use jj)
wocram 1y ago
I think jj is great, godspeed!
gneray 1y ago
Say what you will -- East River Source Control is a great name
baby 1y ago
That's exciting! Have you guys looked into sappling from Meta as well? It looked really cool the last time I looked into it but never tried to use it much.
- steveklabnik 1y ago
  One of ERSC's cofounders left Meta for this, so it's known by the team very well. Sapling and jj are similar for sure.
  - baby 1y ago
    I would guess rain must be aware of it too! rain are you here :P
vivzkestrel 1y ago
stupid question: can someone with a deeper understand kindly explain, why are talks lurking around the corner about hopping version control systems, whats wrong with git that jj solves?
- KingMob 1y ago
  There's a variety of things that all add up to a very pleasant experience. For starters, git has a poorly-designed UI, whereas jj borrows from Mercurial, which was widely-considered to be better designed from a DX perspective. I can usually guess what commands and flags to use on jj without reading the manual; not so for git. E.g., `jj undo` undoes anything you might have done; For anything esoteric in git, I consult ohshitgit.com because there's half a dozen different commands to know to undo everything. Another is a simplified model whose pieces compose better with each other. There's no need for staging or stashes in jj. You essentially work in a HEAD commit all the time, and when it's ready, you commit what you want, make a new child commit and keep going. A stash is just some random commit. Anything you've learned about manipulating commits now applies to "stashes" with no extra effort. No need for branch names. If you come from git, learning that "stashes" are just random little HEAD commits may make you groan and think you have to give each of those branches a name. jj doesn't care about that. I still give major branches a name, but since I don't have to name them in general, it's easier to create lots of little branch "experiments". Branch names were never really a substitute for commit messages, anyway. More rebase-friendly IDs. Git penalizes the use of SHAs when rebasing, whereas in jj, change IDs are stable after rebasing, making them actually usable. This makes rebasing easier and safer. First-class conflicts. Git forces you to stop the world and deal with conflicts immediately, or back out entirely. This isn't really required, and jj has no opinion. It marks conflicted changes, and waits for you to get around to fixing them. This is great when your boss interrupts you for something high-priority. It also automatically rebases all downstream changes after you've fixed it, which usually clears their conflicts too. Megamerge workflow. This is possibly doable in git, but I don't know how easy the workflow is. But in jj, creating a work commit that has multiple branches as parents is trivial, as is pushing work down into individual parent branches. This makes integration easier, as you can easily see how your upcoming changes interact with your colleagues' upcoming changes. Jujutsu's not a revolutionary VCS change (like Pijul's theories of commutative patches), but it's generally way more pleasant to use, with better DX, than git. I gave up git forever after two weeks of jj.
jtwaleson 1y ago
I have Luddite feelings reading about alternatives to Git. As an industry we have soooo many languages, frameworks, tools, distros etc. It's like we are pre metric system or standardization on screw thread sizing. I am really happy that at least for VCS, we have a nearly universal solution in Git, except for the big tech folks. Sure, jj might solve some issues, but once it gets serious traction, all the tooling that works with e.g. repo analysis will need to start supporting git and jj. More docs need to be created, junior developers will need to learn both systems (as git is not going anywhere). Given all the downstream effects, I do not think introducing another VCS is a net positive.
- ahartmetz 1y ago
  In my case, the shoddiness and thoughtlessness of Git's user interface pisses me off so much that I just want it to be replaced. A good tool similar to Git may even explain Git's concepts better than Git or its documentation that likes to discuss "some tree-ish refs".
  - jtwaleson 1y ago
    I do see that, and git is not perfect, not by a long shot. I'd much rather see an evolution of git itself rather than getting more alternatives.
    - louistsi 1y ago
      That essentially is what jj is though, given it can be used on git repositories transparently.
- KingMob 1y ago
  Having used jj for the last year and a half, I hear you on the tooling issues. From IDEs, to plugins, to docs, to workflows, to LLMs, jj is not as well supported as git. Despite that, it's still a net time-saver for me, and I suspect the same will be true for others. Git imposes constant overhead, mostly with its poor UI, but also by some of its unnecessary models (e.g., staging as a separate concept).
Vinnl 1y ago
@Steve: Do you think it would be possible to expose ERSC's Bluesky account to the Fediverse? It's fairly straightforward via https://fed.brid.gy https://fed.brid.gy. Edit: Ah in fact, just like your personal account already is, so you know how straightforward it is :)
- steveklabnik 1y ago
  I’ll take a look at doing that once I actually start work :) I agree it’s something we should do.
jamesnorden 1y ago
jj feels astroturfed imo, not commenting on its merits, but I just get that feeling.
ahaferburg 1y ago
I tried jj, but I'm used to Sublime Merge. Doing version control in the command line was just too much repeated typing, as you keep losing information. In a GUI you always see the current state. You commit, it updates the display. A diff is a click away. Changing focus to type the commit message is a click away. No reason to ask the same questions again and again. Even with aliases like jjl for `jj log --limit 10` it felt too inefficient and annoying. Selecting individual hunks with the keyboard... I don't ever want to do that again. In SM it's a pleasure. The git CLI might suck, but SM just doesn't. Looking forward to jj GUIs taking off. Or even better: jj getting integrated into SM.
suralind 1y ago
I’ve been adopting jj for my personal projects for 1-2 months and have been very happy with it. One downside is if you move back to edit older revisions, it’s very easy to accidentally append something that was added to .gitignore in the meantime. I suppose it’s a relatively unique problem. Other than that I definitely like it, but my git knowledge accumulated over the years is still much larger than jj. I’m going to be slowly adopting it for work.

376 points by steveklabnik 1y ago

pityJuke 1y ago

Off-topic: I found it very surprising the Logical Awesome website still works.

steveklabnik 1y ago
I'll be honest, I did too. No https cert makes it give a warning in Chrome, which I had expected to just be a 404, and was surprised when it actually worked!

joshstrange 1y ago

I guess I see what the author was trying to convey talking about Rust/Go at the start but I'll admit it confused the hell out of me when we got to Jj (horrible name IMHO but whatever). Jj is a VCS, it was not at all clear (to me) until I got further and I was very confused as to why we were talking so much about source control (I thought Jj was a language since the article started by talking about Rust/Go). Apparently Jj can work on/with git repos making it easier to adopt incrementally which is neat and the main point of this post is that the author is leaving Oxide to go work for a new company trying to to create the GitHub of Jj (my understanding at least). I hope this helps someone else who might be confused like I was.

steveklabnik 1y ago
Thank you for the feedback! I talk about it so much I feel like regular readers of my blog will know this stuff already, but I also don't want to leave out important context for others. I tried to help fix this in https://github.com/steveklabnik/steveklabnik.com/pull/125/files https://github.com/steveklabnik/steveklabnik.com/pull/125/fi..., thanks again!
- simultsop 1y ago
  If you're asked why Rust. I believe you are always free to choose.
sunshowers 1y ago
The full name is Jujutsu, but I think "jj" did come first. "j" is nice because on QWERTY keyboards, not only is it on the home row, it is one of the two keys that has a little tactile marker (bump) on it.

Bolwin 1y ago

Since JJ has technically git compat, I think there's 2 things needed for it to take off 1. A good vscode extension (there's two so-so ones that I'm not sure are being updated) 2. LLM knowledge. I ask gpt-5 about doing something in jj the other day, it didn't even recognize it at first. When I reminded it it was a vcs it hallucinated half the commands. I ended up figuring it out myself from the docs

steveklabnik 1y ago
I do think that GUI stuff is important, there's a lot of folks who have said "not interested unless there's a magit equivalent" which I totally understand. I'm not a big GUI person for VCS myself, so I don't feel the same pain. For LLMs, yeah this is hard for any new project. I use Claude Code, and it does a decent job with jj, it only tries to do git stuff sometimes. I haven't asked ChatGPT about it though, I'll have to experiment with it myself.
- Bolwin 1y ago
  Since they guy behind it works at Google, I wonder if gemini is better at it.
  - steveklabnik 1y ago
    I don't think Google is best though of as a singular entity, I'd very seriously doubt that if it is, it's because of this.
  - victorbjorklund 1y ago
    Doubt the gemini team handpicks training material based on wether the author works at google or not. Doubt they handpick it at all.
    - p_l 1y ago
      Both Claude and Gemini can be integrated reasonably by informing them how to use JJ commands or even through MCP

kelnos 1y ago

At the risk of being unreasonably negative, stuff like this just makes me feel... tired. Git is... fine. I'm sure it doesn't solve every problem for everyone, and oh boy does it still have many rough edges, but it works and (as the article points out), git has won and is widely adopted. I've extensively used CVS and Subversion in the past. I touched Mercurial and Bazaar when I ran into a project that used it. I remember in the CVS days, SVN was exciting to me, because CVS was such a pain to use, in almost every way. In the SVN days, git was exciting to me, because SVN still had quite a few pain points that poked me during daily use. Again, yes, git had and has rough edges, but nothing that would make me excited about a new VCS, I don't think. Maybe I'm just getting old, and new tools don't excite me as much anymore. Learning a new tool means spending time doing something that isn't actually building, so my eventual use of the new tool needs to save me enough time (or at least frustration, messily converted into time units) to balance that out. And I need to factor in the risk that the new tool won't actually work out for me, or that it won't end up being adopted enough to matter. So I think I'll wait on jj, and see what happens. If it ends up becoming a Big Deal, I'll learn it.

steveklabnik 1y ago
I think being conservative about tool use is totally fine! I'm actually pretty conservative about most of the tools that I use. The goal of this post wasn't really to convince anyone on why they may want to give jj a shot, more of just a post about how I think about technologies I may want to spend my limited time on this planet working on, and announce that I'm making a move. I don't think that you're being unreasonably negative. I think it's crucial for technologies to understand that your position is basically the default one, and that you need to offer a real compelling reason to choose a new tool. For some people, jj has enough of that already to bother with choosing, but I think the real power is in things that aren't widely available yet. Hence the need to go build some stuff. It's early days! Not even 1.0 yet. It's very natural that most people do not care at this stage.
- jimbokun 1y ago
  One thing not mentioned in the article: what advantages does jj offer over plain git?

tomstuart 1y ago

Congratulations on the new adventure, Steve, and good luck!

davidkunz 1y ago

jj describe -m "Good luck, Steve!"

steveklabnik 1y ago
Thanks!

drcongo 1y ago

Congrats on the new role, sounds exciting - looking forward to seeing where it goes!

steveklabnik 1y ago
Thanks so much!

baq 1y ago

I’m just sad pijul doesn’t get the same attention or love from the community. It desperately needs an ability to colocate with git.

mirashii 1y ago
I think that the ability to collocate with fit is really the thing that makes even evaluating the use of jj feasible in many organizations. To consider pijul, it requires throwing away all of your forge setup, configuration, permissions, backup, disaster recovery, as well as updating every CI pipeline. In a very real way, git won, and the inertia behind git is higher than it was for any VCS tool before it, and so just being better isn’t going to be enough, you’ll also need to interoperat.
dagenix 1y ago
I strongly suspect that its not feasible to colocate pijul and git. git and jj are based on snapshots, while pijul is based on patches. They have very different models.
- baq 1y ago
  As long as some repository state in either system can map onto a checkout in the other system it should be possible at least in some capacity. I’d like to try out pijul at work, but I’d need an analog of jj git fetch and jj git push. Whatever happens in between doesn’t really matter too much unless it’s tedious manual bookkeeping to maintain history mapping.
coastalpuma 1y ago
Agree, the feature of commutative patches just seems obviously superior? Not sure why there's a critical mass to adopt jj over Pijul apart from jj's git backend.
- steveklabnik 1y ago
  I think this gets at one of my original comments in this thread: I think the reason of commutative patches has communication issues. The benefits touted are very abstract. The problems I’m aware of it solving are mostly theoretical problems for working devs, and so the message hasn’t landed. If I were interested in advocating for these tools, I’d be trying to find a message that does resonate.

bagxrvxpepzn 1y ago

[flagged]

sunshowers 1y ago
> There are no substantial technical or usability reasons to switch to JJ from Git [...]. This is a neutral impersonal opinion that is virtually a fact. I respect your opinion, but I don't think it's a fact and I couldn't disagree any further with it. I wrote a whole testimonial about why I love jj (first one there): https://jj-vcs.github.io/jj/latest/testimonials/#what-the-users-have-to-say https://jj-vcs.github.io/jj/latest/testimonials/#what-the-us... > it's impractical for most working programmers to switch I don't know what you mean here. I think it's quite practical to switch to jj, and people switch over all the time. Some people are going to be earlier adopters than others, but the early adopters can bring others along (as I've been lucky to do at Oxide). > focus on something whose main appeal is more than social Steve and I both think that Jujutsu's appeal is far more than merely some bandwagon effect. I do think that social appeal is an important part of making a project succeed, and that projects without substantial technical merit win due to social appeal all the time, but Jujutsu has both! It's amazing!
- bagxrvxpepzn 1y ago
  > I respect your opinion Thank you for charitably responding to the substance of my comment and especially not whatever tone you may have perceived. I appreciate you.
  - beaker52 1y ago
    Perhaps take a look at jj and give it a go. Maybe you’ll like it. I know I did. The fact I can use it with git and it doesn’t interfere with any GitHub PR workflows means no-one needs to know I use it. I enjoy the jj model. Maybe you could too, and it’s not a crazy investment of time and energy. It’s an evening playing around with a code kata or something. Then working with vcs becomes that little bit more enjoyable.
mirashii 1y ago

adamwk 1y ago

I joined the sapling/subversion company this year, but haven’t had the chance to use jj. But given its resemblance I must say sapling has been great. Much more intuitive than git, and I find commit stacks much easier to follow than branches. I do wonder how it will work without the level of support of Meta, since you won’t have the same commit stack review UI (basically a series of pull requests being reviewed at the same time). So something like what this author is working on is needed.

steveklabnik 1y ago
Yeah, sapling and jj are fellow travelers, for sure :)

jmercouris 1y ago

After reading the article, the technical merits of `jj` are completely unclear.

archargelod 1y ago
The article can be summarized to essentially: I like Rust. jj is written in Rust. Some Rust person loves jj. jj is used at Google. Who upvotes this?
- steveklabnik 1y ago
  I can’t speak to people’s motivations, but I have been a very active member on this forum for a long time, and I was on the Rust team for about a decade, beginning before 1.0. So the article is more like “Here’s why I started using Rust. If you thought I made a good choice then, well, I’m making a similar choice in case you want to join me.” Seems people find that compelling. Just like Rust’s success was not inevitable, neither is jj’s. But I think it might work out. You could also consider this a disclosure of sorts, I post a lot on this forum about jj (and Rust), and so knowing that I now have a financial incentive is important context to some people.
steveklabnik 1y ago
Yes, that was not the goal of the post. There's some comments about this in this thread though, here's the first one of mine: https://news.ycombinator.com/item?id=45673808 https://news.ycombinator.com/item?id=45673808
- svat 1y ago
  That URL https://news.ycombinator.com/user?id=steveklabnik https://news.ycombinator.com/user?id=steveklabnik is a link to your user profile.
  - steveklabnik 1y ago
    Whoops, managed to fix it. Thank you!

weinzierl 1y ago

I think the real news is that some people have started to build what might become something like a "jjhub". https://ersc.io/ https://ersc.io/

steveklabnik 1y ago
I think 'jjhub' is a decent immediate first approximation, and is often how I've started out talking about it with people. At the same time, we have to offer real value here, as you can already use jj with github (and I have for a long time now), so there's more to it than that. But yes :)
- davidkunz 1y ago
  What I would love: - Everything locally stored in the repo: PRs, comments, issues, discussions, boards, ... - CLI first - Offline first (+ syncing) - A website for hosting/presentation
  - steveklabnik 1y ago
    Noted :) In another comment I linked to beads, which is a cool project to keep your issue tracker in your repo, but that's just a personal thing, no comment on what the company plans to do (or not) in this area.
    - antonchekhov 1y ago
      I use command-line tooling much more than IDEs (e.g. VS Code), so the `gh` command-line tool (https://cli.github.com https://cli.github.com) for doing most of the usual hub-oriented workflow (PR authoring, viewing issues, status updates, etc) really helps a lot - I don't have to constantly <cmd>+<tab> to my browser, and point-click-point-click through web pages so much. It would be fantastic if ersc or any other jj-centered code-sharing hub had similar tooling early on.
      - steveklabnik 1y ago

mh9r 1y ago

I tried Jujutsu in the last day and was going through your tutorial. I really liked the experience and can see some potential. I also got the feeling that there is a missing puzzle piece. For example, do I get any benefit from the change id if I push to GitHub for PR review? I guess you benefit from some of the good parts only with the Google internal Piper backend, at the moment. So I’m curious about the ideas and plans you have at ERSC. But what I’m also really yearning for is having a distributed asynchronous/offline-first code review flow built right in. The distributed nature of git somehow got lost with PRs or MRs in GitHub & Co.

steveklabnik 1y ago
Glad to hear you enjoyed it :) > do I get any benefit from the change id if I push to GitHub for PR review? As of right now? Not really. The details are more complicated, but basically, if your project doesn't like the behavior of github when it comes to comments + editing commits, and wants you to tack on new commits instead, we can't change that behavior. However, https://github.com/LucioFranco/jj-spr https://github.com/LucioFranco/jj-spr can, in some situations, give you some of this experience. If your project is okay with editing commits, then it can help you locally, sure. However. In an interesting turn of developments, GitHub's new SVP just tweeted that he's likes jj and is interested in adding stacked diffs to github. I don't know how this squares with their "no new features for 18 months" thing, but we'll see! > But what I’m also really yearning for is having a distributed asynchronous/offline-first code review flow built right in. It's not code review, it's issue tracking, but I've been using https://github.com/steveyegge/beads https://github.com/steveyegge/beads this week, and I think it might be the first "put your issues in your repo" system I actually enjoy. It says it's built for AI stuff, but like, you don't have to use AI with it.
CGamesPlay 1y ago
One thing to note is that the actual commit objects you make through jj do include a `change-id` header which means that even though Github is unaware of jj, peers using jj will still be able to keep track of the rebases. Demo: run `git cat-file -p HEAD` in any jj repository that you've made a change to.

j2kun 1y ago

> I also don’t mean to imply that everyone at Google is using jj, but the contingent feels significant to me, given how hard it is to introduce a new VCS inside a company of that size. I don't mean to imply that Google is fickle, but anything besides Google's perforce fork is deprecated every few years. We used to have a proper git wrapper, then mercurial+extensions, now jj is supposed to replace the mercurial thing, all in 7-ish years?

steveklabnik 1y ago
The intention with this is to also deprecate the Perforce fork, in my understanding. But yeah, it's been a lot. Frankly even harder to keep track of from the outside!
joshuamorton 1y ago
I don't think this is quite right. The git wrapper was never fully supported and had some rough edges (I think it was only ever a 20% project, and also its, like, really old). And the customized mercurial has been around for more than 7 years, I think close to a decade (the client I'm using right now is turning 7, and it wasn't my first one).
- j2kun 1y ago
  I started using git as my daily driver at Google in 2018. I was forcibly kicked off it for mercurial in 2020. The deprecation plan for mercurial is 2026 IIUC. Maybe if you adopted mercurial early it's different.
  - yomismoaqui 1y ago
    What was the reason for using Mercurial?
    - j2kun 1y ago
      Why did Google decide to choose Mercurial? Based on what I read the main reason was that the mercurial dev team was willing to prioritize features needed for Google to add custom extensions to support its monorepo, and the git dev team wasn't going to reprioritize just for the sake of Google.

Pet_Ant 1y ago

One thing I've wanted is the ability to group commits into a mega commit. So the history of little changes remains, but as you are scrolling you don't see all of them.

steveklabnik 1y ago
This is an interesting idea... jj has a templating language, but it's not stateful, so you couldn't like, hide some commits based on other commits, for example. But I'll file this away...
- Pet_Ant 1y ago
  I've thought that it could be as simple as commit's with a message beginning with "minor:: " do not get shown by default.
  - steveklabnik 1y ago
    Hmm, yeah that might work. I was thinking about grouping all “minor::” commits as one commit, but this sounds more feasible.
eddd-ddde 1y ago
You could probably use bookmarks for this.
1718627440 1y ago
That's called a merge commit. You can even group them further by creating merges of merge commit. It requires you to merge in the right direction though.
- steveklabnik 1y ago
  That doesn’t really hide them in the UI though.
  - 1y ago

stonecharioteer 1y ago

Steve, Rain, please call it dojo.dev or something before jjhub catches on.

steveklabnik 1y ago
Rain’s not working at ERSC, but we won’t be naming the product jjhub, don’t worry.

zephraph 1y ago

So excited for this. I talked to the ERSC folks last year about joining but it was a little early for me. Still incredibly excited about what they're building and glad to see one of my favorite people joining the effort. Steve, if you come to NYC hit me up!

steveklabnik 1y ago
Thank you! I’ll try to remember that.

deleted 1y ago

[deleted]

mrbonner 1y ago

Is there a jj tutorial not assuming git knowledge at all? I'd love to see how to approach jj without git.

steveklabnik 1y ago
Not really, but I think there should be.
dcre 1y ago
Someone attempted that a couple of months ago: https://jj-for-everyone.github.io/ https://jj-for-everyone.github.io/ Discussion: https://news.ycombinator.com/item?id=45083952 https://news.ycombinator.com/item?id=45083952

TinkersW 1y ago

Does it work with large binary files and not choke like git? Cause git may have won for webdev etc, but in some industries such as gamedev, Perforce is the king... git is barely used at all because it can't handle binary files worth a damn(yes I know about the large file extension, no it isn't sufficient).

steveklabnik 1y ago
Right now, nothing special. But this is very much an area that's known about and something may happen in this area, we'll see.
- tombert 1y ago
  If you could elegantly handle large or frequently-changing binaries I think I'd be willing to switch immediately. It has always annoyed me that there's not any clever way to handle binary changes with version control.
jasonpeacock 1y ago
Perforce’s binary support is basically equivalent to Git LFS, it does the same thing. What does Perforce binary support have that Git LFS doesn’t? AFAIK, the base issue that Perforce is already in use and it has enterprise support.
- dafelst 1y ago
  I am the last person to ever promote perforce, but as of last yearish it has the option for binary delta transfer using fastCDC. Even without that, it is a just straight up a lot faster than git lfs. I know this because I benchmark it against git pretty frequently as I am creating my own large file capable VCS.
- bananaboy 1y ago
  What do you mean by this? It's hardly equivalent to LFS. The binary files aren't replaced with a text pointer with actual content stored on a server elsewhere. Binary files are stored in the same place as text files.

jonstewart 1y ago

What I miss from the Perforce and Subversion days is committing directly to trunk in a team environment. Now everything revolves around PRs and lengthy code review. With direct commits to trunk, everyone was in a rush to get their commit in before someone else did, so they didn’t have to update and have conflicts. This made commits small, frequent, and usually well-scoped. What -sucked- was when you did need to do a large refactoring or other big change, then that was work best done on a weekend because branching and merging didn’t work very well. Git’s model is right for PRs for open source projects where one day you could wind up with code from someone you don’t know and you need to take your time in review and possibly making further changes before merging. But as much as git’s a meaningful upgrade over Perforce and (especially) Subversion, branching and merging is not the right default model for normal team development.

cozzyd 1y ago
You can totally use that workflow with git.
- jonstewart 1y ago
  I know but tell that to GitHub/Gitlab/BitBucket/etc.
ivolimmen 1y ago
PR's are a man made ritual that was never required by GIT. Just like we are all doing the Lean/Scrum or whatever dance. It does not change the development process, it's just a man made ritual for collaboration. The branching model is nicer to work with than the revision based model from subversion though.
philipwhiuk 1y ago
> then that was work best done on a weekend I mean that's just toxic.
- jonstewart 1y ago
  So was CVS!

tmtvl 1y ago

Does JJ have equivalet functionality to git's format-patch and am? Because I, for one, am rather fond of the e-mail based workflow and not having that would make JJ a no-go for me.

steveklabnik 1y ago
There hasn’t been a ton of desire for it because it’s easy to just run git format-patch. Jj’s workflows feel closer to the email workflow than not, but prioritization in a young project is tough.
Iwan-Zotow 1y ago
Oh man...

oefrha 1y ago

I gave jj two honest tries. While first class conflicts is a cool idea, in practice I deal with staging/committing 30x more than conflict resolution, and coming from magit, using jj’s hunk split & select felt like being thrown into stone age. Plus I rebase a lot and get a lot of jj’s benefits from magit’s various rebase shortcuts already, IIRC first class conflicts was the only truly novel thing I didn’t have. For people like me who stage/commit often and judiciously I don’t think jj will beat magit until its hunk selection UX comes close.

ModernMech 1y ago
Oh wow, they were going for "magic" with that name?? I read it as "maggot".
dcre 1y ago
I’m curious what the magit hunk selection UX consists in. I couldn’t find any videos showing something substantially different from the one built into jj — the videos I found were meant as beginner intros. I’ve never used magit but I used GitUp (https://gitup.co/ https://gitup.co/) for years before jj. I don’t find the jj one super natural, but I feel like that’s mostly a matter of keyboard shortcuts — I need to see if they can be customized.
- chrchr 1y ago
  There's more than one way to do it, but the very normal UX is that you can just scroll through the diff file-by-file and stage/stash/drop each hunk individually by placing your cursor over it and issuing the appropriate command. You can do the same with files, staging/stashing/dropping changes to a file by placing the cursor on its name and issuing a command.
  - aardvark179 1y ago
    Crucially you can also select a region within a chunk and perform those commands, so it’s easy to untangle changes.

RustSupremacist 1y ago

This is one person's career move that is defended by the idea that they somehow always make good bets. This is more than a bit arrogant. Past performance is no guarantee of future results. I don't see a future for this. I see a series of blog posts that culminate in a tone deaf "What went wrong" finale.

steveklabnik 1y ago
I certainly don’t think anything is a sure thing.
- ivolimmen 1y ago
  Death and taxes though...
deleted 1y ago
[deleted]

yomismoaqui 1y ago

For all its warts and less than stellar UX Git is good enough (from a former Mercurial user)

jjmarr 1y ago

I'm kind of ambivalent about jujutsu. There's too big of an impedance mismatch between GitHub PRs and jujutsu, nor does it have a good VS Code UI. I only use it when I have a ton of minor PRs I want to work on simultaneously, otherwise I just do git worktrees. I'm mainly in favour because my name is JJ and sharing my name with a widely-used source control tool might help my career.

Hasnep 1y ago
I've been enjoying the jujutsu kaisen VSCode extension, you just need to disable VSCode's built in git integration for each project where you use jj (although I'm planning to invert by disabling git globally and then only enable it for the few projects where I don't use jj)

wocram 1y ago

I think jj is great, godspeed!

gneray 1y ago

Say what you will -- East River Source Control is a great name

baby 1y ago

That's exciting! Have you guys looked into sappling from Meta as well? It looked really cool the last time I looked into it but never tried to use it much.

steveklabnik 1y ago
One of ERSC's cofounders left Meta for this, so it's known by the team very well. Sapling and jj are similar for sure.
- baby 1y ago
  I would guess rain must be aware of it too! rain are you here :P

vivzkestrel 1y ago

stupid question: can someone with a deeper understand kindly explain, why are talks lurking around the corner about hopping version control systems, whats wrong with git that jj solves?

KingMob 1y ago
There's a variety of things that all add up to a very pleasant experience. For starters, git has a poorly-designed UI, whereas jj borrows from Mercurial, which was widely-considered to be better designed from a DX perspective. I can usually guess what commands and flags to use on jj without reading the manual; not so for git. E.g., `jj undo` undoes anything you might have done; For anything esoteric in git, I consult ohshitgit.com because there's half a dozen different commands to know to undo everything. Another is a simplified model whose pieces compose better with each other. There's no need for staging or stashes in jj. You essentially work in a HEAD commit all the time, and when it's ready, you commit what you want, make a new child commit and keep going. A stash is just some random commit. Anything you've learned about manipulating commits now applies to "stashes" with no extra effort. No need for branch names. If you come from git, learning that "stashes" are just random little HEAD commits may make you groan and think you have to give each of those branches a name. jj doesn't care about that. I still give major branches a name, but since I don't have to name them in general, it's easier to create lots of little branch "experiments". Branch names were never really a substitute for commit messages, anyway. More rebase-friendly IDs. Git penalizes the use of SHAs when rebasing, whereas in jj, change IDs are stable after rebasing, making them actually usable. This makes rebasing easier and safer. First-class conflicts. Git forces you to stop the world and deal with conflicts immediately, or back out entirely. This isn't really required, and jj has no opinion. It marks conflicted changes, and waits for you to get around to fixing them. This is great when your boss interrupts you for something high-priority. It also automatically rebases all downstream changes after you've fixed it, which usually clears their conflicts too. Megamerge workflow. This is possibly doable in git, but I don't know how easy the workflow is. But in jj, creating a work commit that has multiple branches as parents is trivial, as is pushing work down into individual parent branches. This makes integration easier, as you can easily see how your upcoming changes interact with your colleagues' upcoming changes. Jujutsu's not a revolutionary VCS change (like Pijul's theories of commutative patches), but it's generally way more pleasant to use, with better DX, than git. I gave up git forever after two weeks of jj.

jtwaleson 1y ago

I have Luddite feelings reading about alternatives to Git. As an industry we have soooo many languages, frameworks, tools, distros etc. It's like we are pre metric system or standardization on screw thread sizing. I am really happy that at least for VCS, we have a nearly universal solution in Git, except for the big tech folks. Sure, jj might solve some issues, but once it gets serious traction, all the tooling that works with e.g. repo analysis will need to start supporting git and jj. More docs need to be created, junior developers will need to learn both systems (as git is not going anywhere). Given all the downstream effects, I do not think introducing another VCS is a net positive.

ahartmetz 1y ago
In my case, the shoddiness and thoughtlessness of Git's user interface pisses me off so much that I just want it to be replaced. A good tool similar to Git may even explain Git's concepts better than Git or its documentation that likes to discuss "some tree-ish refs".
- jtwaleson 1y ago
  I do see that, and git is not perfect, not by a long shot. I'd much rather see an evolution of git itself rather than getting more alternatives.
  - louistsi 1y ago
    That essentially is what jj is though, given it can be used on git repositories transparently.
KingMob 1y ago
Having used jj for the last year and a half, I hear you on the tooling issues. From IDEs, to plugins, to docs, to workflows, to LLMs, jj is not as well supported as git. Despite that, it's still a net time-saver for me, and I suspect the same will be true for others. Git imposes constant overhead, mostly with its poor UI, but also by some of its unnecessary models (e.g., staging as a separate concept).

Vinnl 1y ago

@Steve: Do you think it would be possible to expose ERSC's Bluesky account to the Fediverse? It's fairly straightforward via https://fed.brid.gy https://fed.brid.gy. Edit: Ah in fact, just like your personal account already is, so you know how straightforward it is :)

steveklabnik 1y ago
I’ll take a look at doing that once I actually start work :) I agree it’s something we should do.

jamesnorden 1y ago

jj feels astroturfed imo, not commenting on its merits, but I just get that feeling.

ahaferburg 1y ago

I tried jj, but I'm used to Sublime Merge. Doing version control in the command line was just too much repeated typing, as you keep losing information. In a GUI you always see the current state. You commit, it updates the display. A diff is a click away. Changing focus to type the commit message is a click away. No reason to ask the same questions again and again. Even with aliases like jjl for `jj log --limit 10` it felt too inefficient and annoying. Selecting individual hunks with the keyboard... I don't ever want to do that again. In SM it's a pleasure. The git CLI might suck, but SM just doesn't. Looking forward to jj GUIs taking off. Or even better: jj getting integrated into SM.

suralind 1y ago

I’ve been adopting jj for my personal projects for 1-2 months and have been very happy with it. One downside is if you move back to edit older revisions, it’s very easy to accidentally append something that was added to .gitignore in the meantime. I suppose it’s a relatively unique problem. Other than that I definitely like it, but my git knowledge accumulated over the years is still much larger than jj. I’m going to be slowly adopting it for work.