36 ms·

jj – the CLI for Jujutsu

• dgb23 6mo ago
  The last paragraph might be the most important one: > There's one other reason you should be interested in giving jj a try: it has a git compatible backend, and so you can use jj on your own, without requiring anyone else you're working with to convert too. This means that there's no real downside to giving it a shot; if it's not for you, you're not giving up all of the history you wrote with it, and can go right back to git with no issues.
  • eru 6mo ago
    Funnily enough, that's how I used git with CVS and Subversion, too.
  • jeremyjh 6mo ago
    But this is not true. They are interoperable but far from seamless. Those features mainly support migration use cases or things like git deployment from an repo managed in jj. Operations git does are not in jj’s log. You have to constantly import them. The project recommends a single primary interface.
    • miyoji 6mo ago
      But it is true. I (and many others) happily use jj on teams that use git without anyone else on the team using jj or knowing (or caring) what I'm using.
    • maleldil 6mo ago
      If you constantly switch between the two, you're going to have a hard time, but you can take a git repo, try jj for a while, and if you decide to go back, you don't lose anything.
      • jeremyjh 6mo ago
        Right, but that’s different from working in a team environment where everyone else continues using git.
        • saghm 6mo ago
          How so? I've used `jj` locally on teams where most (if not all) of the other team members were using git, and they only found out I was using `jj` when I told them.
        • pyreko 6mo ago
          fwiw I don't use it personally but some people on my team use it while the others use git, and nobody complains.
          • tonfa 6mo ago
            Yeah same here, have been using jj exclusively, the only reason people notice is because my branch names default to the changeid in my setup so I've had questions about the random looking strings.
        • stouset 6mo ago
          No? What problems, exactly, are you suggesting exist? I have used jj extensively on git teams and it has been seamless. The only people who have noticed or cared are the coworkers I’ve gotten to join me.
        • maleldil 6mo ago
          You're confusing mixing git and jj in your local copy of the repo vs what it looks like to other people. You can use jj locally, and it interoperates perfectly with any git remote, and no one has to know you're even using it. From the point of view of other people, it doesn't matter.
        • Balinares 6mo ago
          I don't understand what you mean. The team I currently work with is 100% git while I only use jj anymore, and I've had zero issues?
    • ongy 6mo ago
      I think you are talking about colocation, which is slightly different than the `jj git push` `jj git fetch` type commands. Colocation has its uses bit is a bit finicky. The push/pull compatibility works perfectly fine (with some caveats of github being broken that can be worked around).
    • asdfasgasdgasdg 6mo ago
      Most importantly, submodules are not fully supported, which are used by almost every open source project at least in the space I work in (embedded). So you can't use jj to easily contribute back to those project. It can be done but you always have to be cognizant of whether a submodule has changed between two branches or when you sync, since they don't update automatically the way they do with git.
    • saghm 6mo ago
      It's been over a year since I last used git manually in the CLI, and I've exclusively worked with git remotes. The only time I had any friction was on a team where stale code-gen output was checked into the repo and for whatever reason no one was willing to either add it to the `.gitignore` or commit (pun intended) to keeping it up to date, meaning that I had to manually remove the changes from when I compiled before pushing. I would have argued in favor of adding to .gitignore or keeping it up to date even if I didn't use `jj` though because I think having stale output checked in is just silly.
      • nchagnet 6mo ago
        For what it's worth, you can have your own local gitignore by adding patterns to .git/info/exclude. It's quite useful in this exact situation.
        • saghm 6mo ago
          I did try this, but for whatever reason it kept getting added back automatically. I forget the details of exactly why it was happening because it was close to a year ago, and in the compatibility guide it says this is supported, but I'm not sure if it was at the time or I was running into something different. This was a contract gig for me where I knew it would be ending within a month or so, which meant I didn't bother spending a ton of time trying to figure out a long-term solution.
          • nchagnet 6mo ago
            Interesting, I tried on a recent version so who knows? I do find that sometimes jj is a bit precious with ignored files if the file exists before the ignore rule, even if you untrack. In those situations I almost always "delete/recreate" after the rule is added.
  • IshKebab 6mo ago
    Big caveat: do not try to use Git and JJ in the same directory. It's probably fine if you only use JJ, but if you mix them you will horribly break things.
    • surajrmal 6mo ago
      This isn't true?
      • IshKebab 6mo ago
        It is when I tried it.
        • stouset 6mo ago
          Jujutsu uses git as its primary backing store and synthesizes anything else it needs on top on-the-fly. Any incompatibility here is considered a serious bug. Obviously I can’t argue against your lived experience, but it is neither typical nor common. This is quite literally an explicitly-supported use, and one that many people do daily.
          • rstuart4133 6mo ago
            > Obviously I can’t argue against your lived experience, but it is neither typical nor common. I consider myself a proficient jj user, and it was my lived experience too. Eventually you get your head around what is going on, but even then it requires a combination of jj and git commands to bring them into sync, so `jj status` and `git status` say roughly the same things. The friction isn't that jj handles state differently, it's that `jj git export` doesn't export all of jj's state to git. Instead it leaves you in a detached HEAD state. When you are a newbie looking for reassurance this newfangled tool is doing what it claims by cross checking it with the one you are familiar with, this is a real problem that slows down adoption and learning. There are good reasons for `jj git export` leaving it in a detached head state of course: it's because jj can be in states it can't export to git. If we had a command, say `jj git sync` that enforced the same constraints as `jj git push` (requiring a tracked branch and no conflicts) but targeted the local .git directory, it would bridge the conceptual gap for Git users. Instead of wondering why git status looks wrong, the user would get an immediate, actionable error explaining why the export didn't align the two worlds.
  • verdverm 6mo ago
    Unless you use LFS, submodules, or hooks at your org.
    • igor47 6mo ago
      Submodules work fine but yeah, it's frustrating that lfs is taking so long. But there seems to be some momentum recently https://github.com/jj-vcs/jj/pull/9068 https://github.com/jj-vcs/jj/pull/9068
      • verdverm 6mo ago
        The git compatibility page states that submodules are not supported https://docs.jj-vcs.dev/latest/git-compatibility/ https://docs.jj-vcs.dev/latest/git-compatibility/
        • steveklabnik 6mo ago
          What "not supported" means with submodules specifically is that jj doesn't have commands to manage them. You can use git commands to manage them, and it does, in my understanding, work. There's just no native support yet. This is sort of similar to how you can create lightweight tags with jj tag, but you need to push them with git push --tags.
          • rstuart4133 6mo ago
            > and it does, in my understanding, work. I use submodules with jj, and jj saves and restores submodule hashes perfectly. What it doesn't do is manipulate the sub-repository from its parent. You can do that yourself using jj or git of course, which is what I ended up doing using a few scripts. The result ended up being more reliable than using git's submodule commands directly. They can take all the time in the world to implement submodules as far as I'm concerned. jj's implementation of workspaces removes all of the hairs of git's worktrees. git submodule implementation has even more hairs than worktrees. If the jj developers need time to do as good a job on submodules as they did with workspaces, then I say give it to them.
• tucnak 6mo ago
  16 year-old me would have been very impressed by this!
  • auggierose 6mo ago
    Is that a compliment, or the opposite?
    • tucnak 6mo ago
      A bit of both. I guess it's nice, but nothing I actually care about.
      • xtracto 6mo ago
        I had a similar thought: there surely are lots of young folks who will be all excited with this (I was back in the CVS/SVN days when git appeared). But nowadays I'm extremely lazy to attempt to learn this new thing. Git works, I kind of know it and I understand its flow.
        • nithril 6mo ago
          Same here, I’m not experiencing so much friction to justify looking for an alternative
        • cestith 6mo ago
          We still have some repos in Subversion and most things in git. It’s still exciting for every repo we get migrated out of svn. That’s a high bar to cross if we’re talking further improvements compared to git though.
        • steveklabnik 6mo ago
          I was 38 or 39 when I found jj.
          • hacker161 6mo ago
            See? You weren’t even over 50! Young whippersnappers…
• jansan 6mo ago
  We all need to give ourselves a push and finally make the next step in version control. Github, Google, Microsoft, Meta (did I forget anyone relevant? Probably) should just join forces and finally make it happen, which should not be a problem with a new system that is backend compatible to Git. Sure, Github may lose some appeal to their brand name, but hey, this is actually for making the world a better place.
  • ramblerman 6mo ago
    The new solution is better. It’s so good we must get all the big players to mandate its usage. If ur making an appeal on a forum like this u could have gone with ur favorite feature, or anything else really.
    • jansan 6mo ago
      It is not about starting over, like moving from CVS or Subversion to Git. jj is backend compatible to Git, so nothing really had to change on the backend. It's just that although Git was created by Linus Torvalds it is not perfect and could be more beginner friendly. But efforts to improve this should be concerted, not individual efforts. And it does not have to be jj. I just think there is room for improvement, and not to alienate old farts it could be called GitNext, GitStep, GitFlow or similar to emphasize that is still is just Git, only with an improved front end. Maybe Linus Torvalds himself should start the initiative.
      • childintime 6mo ago
        Linus? Too tired of the open source community to risk having to deal with it more. Hasn't released anything since 2005, he just drifts on the waves. So sad he doesn't see the human energy wasted on his projects, and doesn't move them into the modern era, where compatibility with the past can be dropped in favor of a much tighter feature set, while also coming free of C/C++. In short: don't count on Linus, he's been a coward, he's too comfortable leading from the back.
        • deleted 6mo ago
• tom_alexander 6mo ago
  I'm giving jj a try but one aspect of it I dislike is edits to files are automatically committed, so you need to defensively create empty new commits for your changes. As in, want to browse the repo from a commit 2 weeks ago? Well if you just checkout that commit and then edit a file, you've automatically changed that commit in your repo and rebased everything after it on top of your new changes. So instead you create a new branch off of the old commit and add an empty commit to that branch so any file changes don't end up rewriting the past 2 weeks of history. git is much nicer in that I can do whatever I want to the files and it won't change the repo until _I tell it to_.
  • smackmybishop 6mo ago
    Just don't ever use `edit`, use `new` instead; then your changes are tracked without making a mess. I think that's much nicer than juggling stashes in git.
    • VMG 6mo ago
      ... unless you actually want to edit a change!
      • throawayonthe 6mo ago
        well, you can do jj new <revision>, make your edit, and then do jj squash which will add the changes to the prev revision i do this for example when i want to see a specific edit highlighted in my editor, it's a nice workflow i think
        • Aeolun 6mo ago
          This is exactly how someone explained Git to me 12 years ago or so, and I’ve finally wrapped my head around it. Not changing now.
          • hacker161 6mo ago
            [flagged]
• 7e 6mo ago
  Is it better for AIs? That’s the only reason I would care.
  • VMG 6mo ago
    I've had mixed results. Most models don't have a 100% correct CLI usage and either hallucinate or use some deprecated patterns. However `jj undo` and the jj architecture generally make it difficult for agents to screw something up in a way that cannot be recovered.
    • glasner 6mo ago
      I've gone all in on jj with a OSS framework I'm building. With just a little extra context, the agents have been amazingly adapt at slicing and dicing with jj. Gives them a place to play without stomping on normal git processes.
    • nvader 6mo ago
      Try using https://github.com/danverbraganza/jujutsu-skill https://github.com/danverbraganza/jujutsu-skill This is enough of a command reference that with it, agents are able to work with jj pretty well.
  • joshka 6mo ago
    The cli and a few concepts have evolved with time past the model's knowledge cutoff dates, so you have to steer things a bit with skills and telling it to use --help a bit more regularly. I find it reasonably good with lots of tweaking over time. (With any agent - ask it to do a retrospective on the tool use and find ways to avoid pain points when you hit problems and add that to your skill/local agents.md). I expect git has a lot more historical information about how to fix random problems with source control errors. JJ is better at the actual tasks, but the models don't have as much in their training data.
• rob74 6mo ago
  Still not finished unfortunately :( Guess Steve is currently busy writing the next big thing in programming languages (https://steveklabnik.com/writing/thirteen-years-of-rust-and-the-birth-of-rue/ https://steveklabnik.com/writing/thirteen-years-of-rust-and-...) ?
  • surajrmal 6mo ago
    It hasn't been touched in 3 months: https://github.com/rue-language/rue https://github.com/rue-language/rue .
  • BeetleB 6mo ago
    To be honest, while Steve's tutorial was what got me interested in jj, other tutorials were better in actually helping me understand it.
    • steveklabnik 6mo ago
      This is why I'm glad we have many of them! Not everyone is going to resonate with my writing style.
      • BeetleB 6mo ago
        Yes, but it's a sad state of affairs that the official jj docs point to your tutorial, which is incomplete (and IIRC, more incomplete than in the past - I think you took down some topics).
        • steveklabnik 6mo ago
          Nope, I haven't taken anything down. I have merged in some contributions from others though, it's actually grown (Manish, iirc, contributed the Gerrit section).
          • BeetleB 6mo ago
            Oh, OK. Must be a bad memory. I often go to your tutorial looking for something I could have sworn I read over a year ago and not find it. I must have read it elsewhere.
• cynicalsecurity 6mo ago
  [flagged]
  • ramon156 6mo ago
    [flagged]
  • tomhow 6mo ago
    Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
    • cynicalsecurity 6mo ago
      I'm sorry, it's hard to say anything good about a project that brings nothing new to the table while desperately trying to replace a well-established industry standard. Such attempts look annoying at best and irritating at most. At the very least the person behind the project could have been more humble in pushing it, and instead of presenting it as a "git killer" causing everyone only headache he could have had 1) polished it 2) pointed out precisely what "problems" with git his project solves. None of those were clearly stated; instead, the shared page is simply a shameless plug for wasting everyone's time. Okay, next time I'm simply going to ignore it, but allowing this kind of posting only works against the HN. I'm not sure if you've noticed, but even the original post title was annoying enough that someone from the moderators had to replace it.
      • tomhow 6mo ago
        I'm the moderator who changed the title, which is a routine action. That doesn't mean the post itself is inappropriate for HN. > allowing this kind of posting only works against the HN HN is for curious conversation between good hackers. We can't and won't ever disallow a post about a software project that someone has built and that others find interesting. That would be way too interventionist and completely against the ethos of HN. If you have a substantive critique of the project, you're most welcome to share it in the spirit of curious conversation that this site strives to cultivate. Your original comment and your reply to me reek of just the kind of curmudgeonliness and snarkiness we're trying avoid here.
• shuyang 6mo ago
  Has anyone found a good code review workflow with `jj`? My problem is that GitHub doesn't remember the content of the last reviewed SHA, so every time I push a new change from jj, reviewers lose the delta from their last reviewed commit. To work around this I stopped moving revs (squash/rebase) after review starts, which creates awkward local graphs if I have to merge from main for merge conflicts. Graphite works but it's $$$, and phabricator/reviewable/gerritt all have significant onboarding hurdles.
  • roblabla 6mo ago
    I wonder if the recent github stack system could help with that (https://github.github.com/gh-stack/guides/ui/ https://github.github.com/gh-stack/guides/ui/)
    • shuyang 6mo ago
      waitlist only :/ waiting to get in so i can test it out!
  • bananapub 6mo ago
    github added support for this in the last six hours - https://github.github.com/gh-stack/faq/#will-this-work-with-a-different-tool-for-stacking https://github.github.com/gh-stack/faq/#will-this-work-with-...
  • joshka 6mo ago
    The last reviewed sha is generally available on the PR page (not the changes page) when you force push. There should be a changes since review link somewhere near the push. When reviewing, you can also mark individual files as reviewed (useful in larger reviews where you're incrementally reviewing files). If you do this, only files that are changed will be expanded when you come back to the review.
    • shuyang 6mo ago
      yeah, this is where my complaint is - github shows a "compare" button when I force push, but it's not linked to the PR review. The "file changed" status is often not granular enough - if I change one line, force push, the entire file gets marked as unreviewed. the github "changes since your last review" is commit-based, not sha-based. what I want is something like graphite/gerritt/google's critique where after each force push, the review page shows only the true delta between the two shas (similar to the "compare" button in github, bu as a reviewable unit). poked around on github, doesn't look like the stacked PR feature has affected this "changes since your last review" selector yet :(
• swoorup 6mo ago
  I love jj, but mostly I use jjui. I would like more uniformity in the way jjui handles commands when you are viewing changes vs when you are viewing files within a single change. Often I just make my changes and leave it there without `new`, as I am not sure which file should go in a single commit. I just leave it there and I interactively commit later. For me to use `new` more, I would like the ability to also simply be able to get a tree view of all changes, which contains file which contains file changes, so I could can have marks that span multiple changes and then either `split` or `commit` or `squash` the change, idk if there is a good word for it. Right now I can only mark within a single change, and I lose it once I navigate up.
  • joshka 6mo ago
    I use jj fairly regularly and I'm trying to understand what your approach means, but having difficulty following what you want to acheive here. Seems like you're using ambiguous language that isn't aligned - wdym by marks?
  • gcr 6mo ago
    In jjui, you can select multiple changes to squash/rebase by pressing space bar before pressing S or r. Is that what you mean?
    • swoorup 6mo ago
      yes exactly, pressing space bars to select them. I referred these selection as marks.
  • nchmy 6mo ago
    yeah, i know almost nothing about jj because i only use it via jjui. Why would I waste brain power learning about and remembering new incantations when I can just browse around with arrow keys and mouse and then use like 9 hotkeys to do everything that I could possibly need?
• PUSH_AX 6mo ago
  If it ain't broke...
  • surajrmal 6mo ago
    I think there are a lot of things that work well but still get improved versions. For example, grep works well but there are plenty of better versions these days.
    • newsoftheday 6mo ago
      Really? I use grep multiple times per day, works great, I've seen no need to change. Same with git.
  • BeetleB 6mo ago
    As a Mercurial user, git was broken from day 1 :-)
• butlike 6mo ago
  FWIW, it's a pretty decent fried fish chain in Chicago as well.
  • cestith 6mo ago
    And chicken. And they have a few other things like Italian beef. They’re branching out, too. We had one in our neighborhood in Houston before moving back here to Illinois.
• dhruv3006 6mo ago
  this looks pretty interesting.
• blacknig 6mo ago
  [flagged]
  • whattheheckheck 6mo ago
    The tower continues to build higher and higher, I wonder when it will collapse under its own weight
• enbugger 6mo ago
  1) Are there any benefits in replacing a personal private project git repo with jj? I usually just commit straight to master in order to just not to lose the changes and be able to roll back. 2) Are there any pros in doing so in a project with many large binary files (3d models, images)?
  • Jenk 6mo ago
    You don't replace. jj is backed by git anyway.
    • gcr 6mo ago
      You can switch an existing git repo to jj by using: jj git init --git-repo my-repo I think (but CANNOT PROMISE) that just removing the .jj folder will bring you back, but definitely take a backup of .git before you try this in case I’m wrong.
      • Jenk 6mo ago
        No that is correct when in colocate mode (which is the default mode). Simply removing the .jj folder will "de-jj" the repo entirely, but will leave you in a headless state. Simple to fix with a `git switch` though. If you are _not_ in colocate mode, the .git folder is located _inside_ the .jj folder. So worth checking!
    • ncphillips 6mo ago
      Okay but why would they use jj when they do trunk-based dev
      • Jenk 6mo ago
        I do trunk based dev. My colleagues prefer git. I still prefer to use jj.
• andrepd 6mo ago
  Is there a concise introduction / overview of jj? I've read 8 pages of this link and the author is still in preambles and considerations... Not my favourite style of article!
  • marcuskaz 6mo ago
    I wrote a brief intro to Jujutsu here: https://mkaz.blog/code/jujutsu-vcs https://mkaz.blog/code/jujutsu-vcs
    • simonmic 6mo ago
      This is great, thanks.
  • SAI_Peregrinus 6mo ago
    You have a DAG of "changes" to the repo state. Each change has a stable ID, you can modify its contents or description without changing the ID. There's always a "current" change checked out, JJ automatically snapshots your edits to files into this change. JJ provides tools to edit changes, describe them, group them into named branches (bookmarks), reorder them, split them apart, etc. JJ defaults to being backed by git. Each change has a corresponding git commit. When you edit the contents of a change, jj makes a new git commit & points the change at that new git commit. JJ is never actually amending or editing git commits, it's using git as a content-addressed data store. That's the mental model. It's like git with a lot of accidental complexity (staging area, stashes, commit ID instability) removed. There are a few ways you can work with this model. I like the following: When I want to start new work, I fetch any changes from upstream `jj git fetch`, then make a new change after the current `main` or `master` bookmark: `jj new main`. Then I start writing code. When I want to commit it, I type `jj commit` and write a description. If I find I want to make an edit to a previous change, I edit my working copy and interactively squash to that change ID with `jj squash -i -r <change_id>`. When I'm ready to push those changes, I name the branch HEAD with `jj bookmark create`, then push it with `jj git push -b <bookmark_name>`. If there are review comments I squash edits into the appropriate changes or add new changes, and move the bookmark to the new head with `jj bookmark move`. If I want to merge two (or more) branches, I use `jj new <branch_1_name> <branch_2_name> <...>` to make a new commit with those branch names as parents. If I want to rebase some changes I use `jj rebase`. JJ doesn't care about conflicts, I fix them after a rebase has completed, instead of in the middle.
• tiborsaas 6mo ago
  Does JJ really prefer for me to think backwards? It wants me to start with the new and describe command, but with git I first make the changes and name the changeset at the end of the workflow. I also often end up with in a dirty repo state with multiple changes belonging to separate features or abstractions. I usually just pick the changes I want to group into a commit and clean up the state. Since it's git compatible, it feels like it must work to add files and keep files uncommitted, but just by reading this tutorial I'm unsure.
  • Jenk 6mo ago
    It doesn't need you to think that way at all. `jj new` simply means "create a new commit [ontop of <location>]" - you don't have to describe it immediately. I never do. I know that the intention was to do that, and I tried forcing the habit, but I too found it counter-productive to invariably end up re-writing the description.
    • surajrmal 6mo ago
      I don't usually do that right away, but I often use squash or absorb to move additional changes into a commit I already made in my stack. I think the spirit still applies if you take that course.
  • smweber 6mo ago
    My preferred workflow is to start with a new change, pick the changes I want, then use jj commit to describe the change and create a new empty one on top. Feels very similar to my old git workflow. If I end up with multiple features or abstractions in one change (equivalent to the “dirty repo”), jj split works very well as an alternative to the git add/git commit/repeat workflow tidying up one’s working copy.
    • pythonaut_16 6mo ago
      I also like `jj commit [paths]` to commit just a subset of files when I don't need hunk based splitting. Like `jj commit -m 'Feature A' file1 file2` then `jj commit -m 'Feature B' file3 file 4`
• deleted 6mo ago
  [deleted]
• palata 6mo ago
  I tried jj for a few months. It was fun to learn a new thing, but I haven't had a single case of "wow, this would have been a pain with git". Then I went back to git (it's been 6 months now) and I haven't had a single case of "this is so painful, I wish something better existed". So it felt like the XKCD on "standards": I now have one versioning system, if I learn jj I will have two. What for? Don't get me wrong: it's nice that jj exists and some people seem to love it. But I don't see a need for myself. Just like people seem to love Meson, but the consequence for me is that instead of dealing with CMake and Autotools, I now have to deal with CMake, Autotools and Meson. EDIT: no need to downvote me: I tried jj and it is nice. I am just saying that from my point of view, it is not worth switching for me. I am not saying that you should not switch, though you probably should not try to force me to switch, that's all.
  • naasking 6mo ago
    > Then I went back to git (it's been 6 months now) and I haven't had a single case of "this is so painful, I wish something better existed". The core issues are: how long did it take you to get there, how many lucky decisions did you have to make to not run into git footguns, and how many other people accidentally made different choices and so have very different experiences from you?
    • palata 6mo ago
      What you're saying is that other people may find jj easier for them, right? I am fine with that. I am just saying that the "you should use jj, you will finally stop shooting yourself in the foot regularly" doesn't work so well for me, because I don't remember shooting myself in the foot with git.
  • BeetleB 6mo ago
    For me, it was kind of the same. I used jj. Really liked it, but did not find it all that much better than git. Then, for various reasons, I switched back to git. By day 2, I was missing jj. Stuff like "jj undo" really is nice.
    • 6mo ago
• demorro 6mo ago
  This doesn't seem different enough to be worth the transitional cost, even if you don't need to actually move away from a git backend.
  • maleldil 6mo ago
    It is definitely worth a try. Just being able to squash changes to earlier commits without having to fiddle with fixups and interactive rebases is worth it for me. jj absorb is great too.
• scotty79 6mo ago
  Does jj have partial clones of remote repo?
  • steveklabnik 6mo ago
    jj does not have partial clones, but it does have sparse checkouts.
    • scotty79 6mo ago
      Thank you for the info. Sparse checkouts from remote repo directly or do I need to clone it in whole locally and only then can do a sparse checkouts into some work directory?
      • steveklabnik 6mo ago
        I'm 99% sure it's "clone the whole locally and then sparse checkout from there".
• systems 6mo ago
  its almost impossible for me to tell if this better or worst than git i read few things about jj, and my conclusion 1. its different 2. very few user would really care about this difference i think git is good (not good enough, good just good, or really good) and unlike shells, i cant think of a reason to have mass migration to it people use zsh because apple choose it, and pwsh because microsoft settled on it, on linux i am sure we can do better than bash, but it good enough and nothing justified replacing it (that being said, all 3 OSes should have settled non nushell) in summary, if we couldnt replace bash on linux, i dont think anyone can replace git, git as an scm tool if far better than bash as a shell
  • porksoda 6mo ago
    I may be reading too deeply but it sounds like you haven't even tried it. You should! Its really hard to live without it, once you feel it in your fingers.
  • kccqzy 6mo ago
    > very few user would really care about this difference Oh the user absolutely does if that user creates lots of branches and the branches are stacked on top of each other. I get your feeling though; sometimes in my own private repositories I don’t bother creating branches at all. Then in this case jj doesn’t really make much of a difference.
  • em-bee 6mo ago
    we may have not been able to replace bash yet, but the popularity of alternative shells that are not bash compatible is growing. besides nushell there are fish, elvish, murex, oils (also includes a bash compatible mode to help with the transition) and probably some others that i missed. i see more and more tooling support for some of these, which shows that usage of these shells is growing.
• qezz 6mo ago
  For those, who want to/need to keep some files uncommitted, the workaround I found is to put gitignore into some nested directory: mkdir junk echo '*' > junk/.gitignore jj won't track those files under ./junk/ Also might be relevant for claude, since it wants to put its settings into the repo itself as `.claude/`: mkdir junk/.claude bwrap ... --bind "$(pwd)/junk/.claude" "$(pwd)/.claude" ... For some more common files, I use global gitignore file as # ~/.gitconfig [core] excludesFile = ~/gitconf/gitignore_global # ~/gitconf/gitignore_global .envrc .direnv/*
  • tcoff91 6mo ago
    I run jj in colocated mode so I put stuff in .git/info/exclude if I want it ignored but not part of the main .gitignore
  • BeetleB 6mo ago
    You can also set snapshot.auto-track to tell it not to track certain files. Another option is to make a branch with the files that you want to keep around but not push (e.g. stuff specific to your own tooling/editor/IDE), and mark that branch as private. Private commits (and their descendants) can't be pushed. You then make a merge commit with this branch and main, make your changes, etc. You will have to rebase before pushing so that your branch isn't a descendant of the private commit. This will involve more work, but it has the benefit that you're actually version controlling your other files.
• nailer 6mo ago
  JJ might be good (this article couldn't convey why in the "What is jj and why should I care?" page) but it's not 10x better than git, so it will likely die. Sorry, nothing personal, Mercurial/hg was a little bit better than git and died too. Network effects. What has a change is ast-based version control. You adding a feature to a function that uses a struct I renamed shouldn't be a conflict. Those actions don't confliuct with each other, unless you treat code as text - rather than a representation of the logic. Ending merge conflicts might make a new version control 10x better than git, and therefore actually replace it.
  • saghm 6mo ago
    > JJ might be good (this article couldn't convey why in the "What is jj and why should I care?" page) but it's not 10x better than git, so it will likely die. Sorry, nothing personal, Mercurial/hg was a little bit better than git and died too. Network effects. The difference is that I can (and do) use `jj` with existing git repos today without needing anyone else using the repo to change what they're doing. There's no need to replace something when it can exist alongside it indefinitely.
    • cageface 6mo ago
      Unless you need to work with a repo that uses submodules or lfs.
  • celdon25 6mo ago
    Did you confirm that the network effects are applicable here before posting that?
    • nailer 6mo ago
      Nope. As mentioned "What is jj and why should I care?" didn't cover it and I timeboxed jj advocacy to the page that says it will get me to care.
• aftbit 6mo ago
  Nope, git is good enough, and is the global standard. We don't need more new VCS.
  • cryptos 6mo ago
    Might be true, but Subversion was also good enough and a de-facto standard.
    • aftbit 6mo ago
      IMO Subversion was never as much of a standard as git. I saw a lot of software that still used CVS back then, and even more that didn't do version control beyond versioned source tarballs. I'd be happy to be proven wrong. You won't get there by designing a solution that is more ergonomic (if jj even is), but rather by designing one that solves problems that git doesn't solve. Also, you probably need to get some big and important software (like Linux, for git) to switch to using it instead of git. Even then, I'm usually _not_ an early adopter of something as pivotal as a VCS. This isn't something that's easy to rip out or rewrite later. It shapes my workflow at a deep level and holds the history of my changes in its database. Only once it's being used by 25-50% of projects I encounter daily will I consider moving stuff I control to it. I have deep scars from mercurial lol.
  • porksoda 6mo ago
    Great opinion. Have you tried it? It takes just 30 minutes to wash all the Stockholm syndrome off of you.
    • homebrewer 6mo ago
      Not necessarily. I used jj for a couple of weeks and found it to be a complete waste of time. For an advanced user, it did not offer anything I cannot quickly solve in git. Which is probably the wrong thing to optimize in the first place, because even though I frequently rewrite history and split commits during normal worklfow, it takes so little time that improving something else would yield greater returns. We (not royal we) don't usually go out of our way repeating negative experiences with these tools, so you build a very skewed view of their adoption.
• justinmayer 6mo ago
  Many folks aren’t aware that there is also an open-source, cross-platform desktop GUI application for Jujutsu called GG: https://github.com/gulbanana/gg https://github.com/gulbanana/gg I mention it because while the jj command line interface is excellent, there are certain tasks that I find easier to perform with a graphical user interface. For example, I often want to quickly tap on various revisions and see their diffs. GG makes that kind of repository browsing — and certain squash operations — much more efficient for me. If you’re interested in more information about GG, my co-host and I talked about it in a recent episode of the Abstractions podcast at about the 8:17 mark: https://shows.arrowloop.com/@abstractions/episodes/052-they-deserve-the-dunks https://shows.arrowloop.com/@abstractions/episodes/052-they-...
  • tcoff91 6mo ago
    jjui TUI is incredible also
• ferfumarma 6mo ago
  Can jj iterate through a list of repositories and clone them all to local storage? It isn't very hard to make a bash script to do it, but I have about six github repos, all of which frequently need to be put on a new machine. that kind of functionality would be cool to have out of the box.
  • hosteur 6mo ago
    for url in url1 url2 ..; do git clone $url; done That’s not really a script but a basic one liner.
    • Filligree 6mo ago
      No, but to be honest, why would you want it to? That's... well, you already showed the trivial one-liner.
  • saghm 6mo ago
    Are you accessing these boxes via ssh or using them directly? If it's via ssh, I'd expect that you would already be using the clipboard for copying the names of them rather than typing them out manually, at which point copying `git clone <a> && git clone <b> && ...` would achieve the same thing.
• zingar 6mo ago
  "It's more powerful and easier" is a great claim, but I need examples in this opening page to convince me of the pain I could save myself or the awesome things I'm living without.
  • baq 6mo ago
    does trivially working on 3 PRs in a single checkout and pushing focused changes to each one independently without thinking twice count? if you don't need this, you might not see any value in jj and that's ok. you might use magit to get the same workflow (maybe? haven't used magit personally) and that's also ok.
    • alphabetag675 6mo ago
      Actually it is a anti-demo, because while software allows you to do it, I don't think many software engineers can work on this.
      • baq 6mo ago
        in large enough monorepos and teams and big enough changes you either do it like this or have a humongous giga-PR which eventually starts conflicting with everything.
    • VanTodi 6mo ago
      Guess he was talking about the presentation, not what the tool can achieve. It has no hard proof on the first page, which could easily just be a LinkedIn pitch, but not on hackernews
    • tinco 6mo ago
      It might count, but it is easy with git as well, what is the feature in jj that makes this easier? Switching branches and pushing changes to remotes is the core feature of git and in my opinion really easy so I'm curious how jj improves on it.
      • 6mo ago
• zhaoyongjie 6mo ago
  To be honest, JJ is dick in Chinese, literally.
  • verdverm 6mo ago
    https://chinese.stackexchange.com/questions/31646/is-jj-slang-for-penis-in-chinese https://chinese.stackexchange.com/questions/31646/is-jj-slan...
• BeetleB 6mo ago
  One of my favorite jj features is "jj absorb". For each change you've made in the current revision, it finds the last commit where you made a change near there, and moves your changes to that commit. Really handy when you forgot to make a change to some config file or .gitignore. You just "jj new", make the changes, and "jj absorb". No need to make a new commit or figure out where to rebase to. Oh, and not having to deal with merge conflicts now is awesome. My repository still has merge conflicts from months ago. I'll probably go and delete those branches as I have no intention to resolve them.
  • xixixao 6mo ago
    git absorb exists too fyi
    • bitdivision 6mo ago
      Not by default: https://github.com/tummychow/git-absorb https://github.com/tummychow/git-absorb
  • dnmc 6mo ago
    And If `jj absorb` gets it wrong, you can run `jj undo`. This is such a killer feature to me. I'm not scared to start potentially gnarly rebases anymore because I can painlessly undo.
    • BeetleB 6mo ago
      Yes. With "jj undo", I'm not scared to do anything. The brief time I had to go back to using vanilla "git", I didn't enjoy being extra cautious. Using a version control tool shouldn't require much self discipline.
    • nchmy 6mo ago
      yeah, i regularly try absorb then undo when it moves it to a commit from 7 years ago, then manually squash where appropriate
  • jhhh 6mo ago
• mi_lk 6mo ago
  Please update the "Stacked PRs" workflow article Steve...
  • steveklabnik 6mo ago
    I'll get there... someday...
• ux266478 6mo ago
  Clicked on this hoping it would be the irc client, very disappointed! For those in the know, how does jujutsu stack up to something like Darcs?
  • steveklabnik 6mo ago
    jj is still snapshot based.
• SV_BubbleTime 6mo ago
  >You can request to not use the pager by using jj st --no-pager, or if you hate the pager and want to turn it off, you can configure that with $ jj config set --user ui.paginate never In one feature they can’t help themselves from calling it two different things already. Why do this? Why can’t the very clearly smart people making things step 1/2 step outside themselves and think about it like they are the users they want? Earlier they talk about the native format and how it isn’t ready… so that to start you need jj git init … but… if they’re planning a native format that makes no sense as a command. It would be ‘jj native init’ later? Early planning keys/plans imo but those rarely change so as to not accept your early adopters. These seem like small things but to me it’s a warning.
  • Philpax 6mo ago
    1. Pagination with a pager is a reasonable default. See `git log`. 2. The native format would be `jj init`. For precedent, see how uv dealt with its pip compatibility: `uv pip install` was obsoleted by `uv add`.
    • SV_BubbleTime 6mo ago
      1. No one with good vision would give a single feature two names. It’s dumb. Here is our pager feature. Cool, how do I access it? Oh you set the ui.paginate options of course!! 2. It’s almost like we have some established ways to denote arguments that are pretty popular… ‘jj init —-git’ for example? By using ‘jj git init’ I would expect all of the git compatible commands to be be ‘jj git xxx’ because that is a reasonable expectation. This is a problem with the voodoo. These obscure nonsense commands only makes sense when you are accustomed to them. If there’s no reasonable expectation that you could just figure it out on your own. Go on vacation and come back and be surprised when you forget the voodoo. Not to mention that every tool has to have its own unique voodoo. Almost like the professional world has figured out that made by software engineers for software engineers will never be popular. And then engineers don’t understand the effects of why you might want tool to be intuitive and popular.
      • steveklabnik 6mo ago
• randyrand 6mo ago
  jj sounds awesome. I think I’ll give it a shot. But I found this article a bit long winded and ended up asking an LLM about it instead.
• QuiDortDine 6mo ago
  > $ cargo install jj-cli@0.23.0 --locked I won't install Rust just to test your software. Make a debian package like everyone else.
  • harg 6mo ago
    I believe the full docs page does indicate that there are binaries to install via popular package managers [1] [1]: https://docs.jj-vcs.dev/latest/install-and-setup/ https://docs.jj-vcs.dev/latest/install-and-setup/
    • QuiDortDine 6mo ago
      I did check that page, as far as I can tell you still need to run Cargo which I don't want to do because I don't care about Rust. I'm not complaining for the sake of complaining, I'm saying if they want to play in the Big Boy leagues, they need to do things right.
      • steveklabnik 6mo ago
        You do need Cargo to build from source. If you're on Arch, gentoo, or openSUSE, you can use the package. It is true that Debian has not packaged jj yet. It'll get there, and it's fine if you'd rather wait until things are more mature.
        • saint_yossarian 6mo ago
          It's available in Debian sid, although a few versions behind: https://packages.debian.org/search?searchon=names&suite=all&section=all&keywords=jujutsu https://packages.debian.org/search?searchon=names&suite=all&...
          • steveklabnik 6mo ago
            You know, I went and searched before I posted. I wonder why it didn’t come up! Thanks.
• jrockway 6mo ago
  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 PR as adding a feature. I can have them both self-contained, but still start on the next step before they're all merged. It's easy to add changes on top, switching between the individual PRs as comments come up, etc. I always liked doing things like this. At Google where we used a custom fork of Perforce, I told myself "NEVER DO STACKED CLs HAVE YOU NOT LEARNED YOUR LESSON YET?" If one CL depended on another... don't do it. With git... I told myself the same thing, as I sat in endless interactive rebases and merge conflict commits ("git rebase abort" might have been my most-used command). With jj, it's not a problem. There are merge conflicts. You can resolve them with the peace of mind as a separate commit to track your resolution. `jj new -d 'resolve merge conflict` -A @` to add a new commit after the conflicted one. Hack on your resolution until you're happy. jj squash --into @-. Merge conflict resolved. It is truly a beautiful model. Really a big mental health saver. It just makes it so easy to work with other people.
  • andrewdea 6mo ago
    I'm having trouble understanding the value of this and most other supposed advantages of jj I'm seeing. I'm trying to pinpoint if it's because 1) my workflow doesn't need jj's fancy stuff, 2) I've gotten so used to `git`'s "flaws" that I don't notice them, or 3) the git porcelain I use (magit) does a good enough job at managing the flaws. If you need to build on something that requires changes from 3 open PRs, can't you just start a new branch from main, merge all 3 PRs into it, and get to work? As changes are applied to the open PRs, you can rebase. Obviously that might cause some merge conflicts here and there, but as long as the PRs aren't super overlapping, they should still be manageable. If there's a ton of overlap between 3 open PRs, that to me sounds like a problem in the workflow/plan, which must be dealt with regardless of the VCS or porcelain.
    • steveklabnik 6mo ago
• wolttam 6mo ago
  What happens when jj introduces this native repository format - break compatibility with all the popular git hosts? If jj is so great now and works with git as a backend, it’s tough to imagine why it’s worth pursuing a native and presumably incompatible backend.
  • steveklabnik 6mo ago
    Nothing will break. You just keep using the git backend if you want to keep being compatible with git. > it’s tough to imagine why it’s worth pursuing a native and presumably incompatible backend. Well, there's no active work on a "native" backend. There are basically three backends right now: 1. the git backend 2. A simple backend used for tests, you can think of it almost like a mock backend, you wouldn't use it for real work, but it's still useful as part of the test suite 3. the piper backend at google There's not a lot of reason for anyone to produce another open source "native" backend, because 99% of open source projects use git.
    • wolttam 6mo ago
      That makes sense, thanks for the reply. For some reason I was under the impression that there was an active drive towards a backend that was not git.
      • steveklabnik 6mo ago
        You're welcome. I think it's natural to assume that.
• kevin_nisbet 6mo ago
  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 again at some point, but working in a team through Github PRs that was my main barrier to entry.
  • steveklabnik 6mo ago
    This is good feedback, thanks. The next version of the tutorial will certainly focus on stuff like this, as I agree it's really important to teach people.
  • p_stuart82 6mo ago
    locally? sure. stacked changes in jj are great. but the moment you push to GitHub, the review UI still thinks in SHAs. a lot of the pain just moves from the author to the reviewer.
  • opem 6mo ago
    I see that is an issue with many people, but now with github adding support for stacked PRs, I guess that would change
• theappsecguy 6mo ago
  I'm still struggling most with the fact that my day-to-day work involves a git first platform like GitHub. Although jj as a vcs system, it does feel better, working with git through it still feels like a chore, but to be fair I only gave it a day before going back to git. Does anyone have any good resources on how to augment a git flow through the lens of a git hosting platform to work smoothly and still reap the benefits of jj?
  • r5Khe 6mo ago
    I'm not sure what the hangup is, TBH. I use `jj` with GitHub and ADO every day, and it works great. What specific challenges are you running into that make it feel like a chore?
    • theappsecguy 6mo ago
      Hmm, it was a while back so now I'm struggling to recall, but I remember feeling like I'm going against the grain of easily using GitHub. I followed this exact tutorial at the time and it looks like there are now sections on how to work with GitHub. Perhaps I need to force myself to commit for longer...
  • BeetleB 6mo ago
    What problems are you running into? The jujutsu docs have a page for this - it has everything I needed. https://docs.jj-vcs.dev/latest/github/ https://docs.jj-vcs.dev/latest/github/
• fallat 6mo ago
  Now that Steve is part of a GitHub competitor to push jj, I see all these posts as just sales pitches.
  • Philpax 6mo ago
    This tutorial predates his involvement with ERSC.
  • steveklabnik 6mo ago
    I am quite happy for anyone to use whatever tools they find to be good. I'm also happy for anyone to use jj with whatever server they want to. It is right to be skeptical of me, but I hope to keep that integrity by continuing to talk about things that I believe are legitimately good, regardless of anything else.
    • fallat 6mo ago
      Thanks for the reply Steve - I think it's only natural, and charitably unintentional :) But almost everything I've seen upvoted around the Internet from you has been about jj and being directly tied to east river source control... I think that's a reasonable framing. I can only hope me signalling this maybe changes something. While I'm not a fan of jj (I'd much rather Pijul were to eat the world), I think you as a person is really nice and always have been "for the community", but I can't shake this current framing!
      • steveklabnik 6mo ago
        I mean, most people seem to think I solely post about AI these days, so it’s kinda funny to run into someone that feels otherwise! I’m not sure why I’d stop posting about a project I’ve been passionate about for years, just because my job is adjacent to it.
        • fallat 6mo ago
          You can't say it's adjacent to it, when your job directly involves the technology. You'd stop posting because anything you say about jj could be interpreted as a sales pitch for jj, and a lot of people can be turned off by that. That's one reason. Our lack of creativity is not proof of no more. But I don't think "stop writing" is the only strategy to jump on... Or maybe I'm just extremely unlucky to have only caught these kinds of posts and gained this framing! Totally possible.
• octocop 6mo ago
  Nobody is asking for a git replacement? I keep seeing these posts and I don't know who wants them.
  • SatvikBeri 6mo ago
    jj has almost 30,000 stars on github. You might not be looking for a different git ux, but plenty of people are!
  • vaylian 6mo ago
    You could have said the same thing about subversion. Subversion is a fine VCS. But git offers a better approach with being offline-first and decentralized. It also makes merging branches a lot easier. I don't know enough about jj to praise it, but I don't think git will be the last VCS that will become widely popular.
  • steveklabnik 6mo ago
    I wasn't asking. I loved git. But then after trying jj, I wrote this tutorial because I love it even more.
  • __turbobrew__ 6mo ago
    The feeling I get with jj is it is almost like people are trying to convince others why jj is superior instead of just sharing that jj exists and let others decide themselves. It seems like every few months there is a jj post on HN which devolves into the narratives of “git works for me” and “but jj is better at X”.
    • ncphillips 6mo ago
      Where X = something I’ve never wanted to do
    • chriswarbo 6mo ago
      Exactly the same thing happened when git showed up (alongside the same things for bzr, darcs, hg, etc. too!)
  • 6mo ago
• alunchbox 6mo ago
  So glad to see this on HN, here to support it. JJ is amazing, the hardest hurdle was not the tool but the toolchain and ecosystem when I started ~ 2 years ago. It's grown rapidly and is incredible to see the community grow!
• steveklabnik 6mo ago
  Hey folks! So, I haven't updated the tutorial in a long time. My intent is to upstream it, but I've been very very busy at the startup I'm at, ersc.io, and haven't had the chance. I'm still using jj every day, and loving it. Happy to answer any questions!
  • klauserc 6mo ago
    jj automatically hides "uninteresting" changes. Most of the time, this is good. Occasionally, I need to see more changes. It is not obvious to me how I get jj to show me elided changes. I mean, sure, I can explicitly ask jj to show me the one ancestor of the last visible change, and then show me the ancestor of that one, etc. Is some flag to say: "just show me 15 more changes that you would otherwise elide"?
    • steveklabnik 6mo ago
      I use `jj log -r ..` for that, which is just an open ended range. It's not the "15 more" but it's what's worked for me. I suspect you could do it with some sort of revset stuff, but I like to keep it simple.
    • nickisnoble 6mo ago
      Easy: `jj log -n 25` (Default is 10 iirc, so if you want 15 more... 25) If you want everything, ever: `jj log -r ::` Or every ancestor of your current change: `jj log -r ..@`
      • steveklabnik 6mo ago
        IIRC -n only limits the output, not expands it. jj log and jj long -n 25 show the same results for me.
    • rstuart4133 6mo ago
      I'm not sure what you are asking, but you want to look at how a particular jj change-id evolved over time, use `jj evolog`. By default that evolution is hidden. The `change-id/N` syntax has uses beyond conflicts.
• Openpic 6mo ago
  [flagged]
• rs545837 6mo ago
  jj is genuinely great and I think it deserves way more adoption than it has right now. The mental model is so much cleaner than git, undo actually works the way you'd expect it to, and working with stacked changes feels natural instead of that constant low-grade anxiety of actually breaking something. It's probably the best frontend for version control that exists today. For the last few months though I've been thinking a lot about what you said at the end there. What if version control actually understood the code it was tracking, not as lines of text but as the actual structures we write and think in, functions, classes, methods, the real building blocks? A rename happening on one branch and an unrelated function addition on another aren't a real conflict in any meaningful sense, they only look like one because every tool we have today treats source code as flat text files. For enhancing this kind of structural intelligence I started working on https://github.com/ataraxy-labs/sem https://github.com/ataraxy-labs/sem, which uses tree-sitter to parse code into semantic entities and operates at that level instead of lines. When you start thinking of code not as text there's another dimension where things can go, even a lot of logic at the comiler level with call graphs becomes useful.
  • sieabahlpark 6mo ago
    [dead]
• jimmypk 6mo ago
  [flagged]
• jiggunjer 6mo ago
  I think the mental model is like C vs python. Git gives you a forensic trace back in time. jj gives you a story with chapters. Look under the hood you'll still see forensic map of state transitions, but this not what we want to navigate most of the time. Sometimes we need to rewrite an early chapter to make the latest chapter make more sense.
  • baq 6mo ago
    the fact that almost by definition stuff that jj does is possible in git makes it hard for some folks to let go of the baggage that git has; it's simply hard to imagine a world where you can't git add ('how do you commit what you need committed and not commit the rest?') or not having to resolve conflicts immediately ('why would I want not to?') ...and it turns out when you answer these questions differently ('working tree is a commit', 'conflicts can committed) but still want git compatibility, jj kinda falls out of the design space by necessity.
• compiler-guy 6mo ago
  One of the things that makes jj worth trying out is simply the fact that it is different than git, and having exposure to more than one way of doing things is a good thing. Even if you don't adopt it (and I didn't), it's easy to think that "this way is the only way", and seeing how systems other than your own preferred one manage workflows and issues is very useful for perspective. That doesn't mean you should try everything regardless (we all only have so much time), but part of being a good engineer is understanding the options and tradeoffs, even of well loved and totally functional workflows.
  • beanjuiceII 6mo ago
    being a good engineer is also understanding when something is a waste of time because the gain is insignificant 99% of the time
    • eddd-ddde 6mo ago
      Using "good engineering" as an argument against learning is definitely an interesting approach.
      • cindyllm 6mo ago
        [dead]
    • dcre 6mo ago
      It seems like all of your comments are like this. Consider stopping that!
    • dwattttt 6mo ago
      I think siblings point needs to be made more sharply: this could've gone somewhere good, "I evaluated it and found the gain was not worth the cost to change", but instead went to "the gain from a change is insignificant 99% of the time, so it's not worth understanding it". The latter is poor engineering.
• tobinfricke 6mo ago
  Here are some notes on Jujutsu from Evan Martin that I found interesting/useful: https://neugierig.org/software/blog/2025/08/jj-bookmarks.html https://neugierig.org/software/blog/2025/08/jj-bookmarks.htm...
• waynecochran 6mo ago
  Anything new or special in jj that allows me to work with large binary files simply? To me, this is still unsolved in terms of providing an elegant solution (e.g. things like Git Large File Storage (Git LFS) are awkward).
  • steveklabnik 6mo ago
    Not yet. It's desired to do something better here, but there's no active development that I'm aware of right now. (LFS support is in progress though)
  • brendoncarroll 6mo ago
    I've heard that jj has support for non-git backends? Can anyone comment on how difficult it would be to add support for another backend, any docs or examples? I have a project[0] that does the large file thing well, but is missing most of the version control porcelain. I've been looking for the path of least resistance to integrate it into something with a larger user base. [0] https://github.com/gotvc/got https://github.com/gotvc/got
    • steveklabnik 6mo ago
      To add a new backend, there's a trait that you implement for your backend: https://github.com/jj-vcs/jj/blob/713a0d0898448392d38fdcbabacb0a244d14703c/lib/src/backend.rs#L538 https://github.com/jj-vcs/jj/blob/713a0d0898448392d38fdcbaba... I suspect if you came by the jj discord, folks could help you with more detail than that.
      • brendoncarroll 6mo ago
        Thanks for the link. It looks like this treats files as blobs just like Git, and trees as single objects which fit in memory. Assuming that is a correct understanding, this core abstraction would need to change to handle large files and directories well. All the well known version control systems do this though, and it simplifies the system significantly. It's the right model for source code, but it doesn't translate well to arbitrary data.
• misnome 6mo ago
  The problems with jj that led me to abandon are: - All of everything good about it breaks down the instant you want to share work with the outside world. It's git on the backend! Except there isn't any concept of a remote jj so you have to go through the painful steps of manually naming commits, pushing, pulling, then manually advancing the current working point to match. And in doing so, you lose almost everything that gives it value in the first place - the elegant multi branch handling, anonymous commits, the evolog. Even if you want to work on the same project on two machines your only choice for this is without breaking everything via git is to rsync the folder. Yes, you can write alias to do all this like git. I might as well use git if I can't use the nice features. - All files automatically committed is great until you accidentally put a secret in an unignored file in the repository folder. And then there is no way to ensure that it's purged (unlike in git) - the community response as far as I can tell is "Don't do this, never put a file that isn't in gitignore". - And adding to .gitignore fails if you ever want to wind back in history - if you go back before a file was added to .gitignore, then whoops now it isn't ignored, is all part of your immutable history, and disappears if you ever switch off of that new commit state.
  • rstuart4133 6mo ago
    > Except there isn't any concept of a remote jj so you have to go through the painful steps of manually naming commits, pushing, pulling, then manually advancing the current working point to match. All true. I ended up writing my own `jj push` and `jj pull` aliases that automated all this. They aren't simple aliases, but it worked. `jj push` for example "feels" very like `git push --force-with-lease`, except if you've stacked PR's it pushed all branches your on. It hasn't been a problem since. I ended up wondering if they deliberately left the `jj pull` and `jj push` commands unimplemented just so you could write something custom. > All files automatically committed is great until you accidentally put a secret in an unignored file in the repository folder. jj abandon COMMIT && jj git garbage-collect > And adding to .gitignore fails if you ever want to wind back in history - if you go back before a file was added to .gitignore, then whoops now it isn't ignored True, but how is this different to any other VCS?
    • misnome 6mo ago
• pheggs 6mo ago
  I was already pretty happy with svn to be honest, I dont see myself switching away from the industry standard today for no substantial reason. in my opinion git was only able to change the standard thanks to github and a popular author (i love git and its branching, but I dont think it would have been enough if it was just for that). I personally believe its going to be very difficult for jj to replicate that.
  • newsoftheday 6mo ago
    I like the distributed nature of git but miss how svn worked to some degree. Generally I agree with you, git works, I read the post and didn't see anything that makes me want to change. The small number of jjites who have been inundating comment sections on this site lately feels like the devotees of Rust (a crap language), podman (which has too many operational inconsistencies) and JetBrains IntelliJ ballywhooers who used to preach IntelliJ's features on every programming related site.
  • GuB-42 6mo ago
    In my opinion, svn lost to git because git is just so much better in a distributed environment. To me the improvement between git and svn is much more than the improvement between svn and cvs. In fact, by many aspects, I preferred cvs, but now that we have git, they can both go to hell. Now, it is not the only DVCS, there is also Mercurial, which is built on similar principles. It could have become the standard, but I agree with you that the reason it didn't probably has to do with Github and Linux. jj isn't fundamentally different from git, it is actually compatible with git, which is a good and a bad thing. Good because it makes transition easy, bad because it is fundamentally the same thing and there is no pressing reason to change. But jj definitely look nicer than git, which is not hard, under the hood, git is great, but it is ugly. It started off as a hack and it still shows. I think the common sentiment of "I know git, I don't want to learn a new VCS" mostly tells about how painful the process of learning git was. If you had started off with Mercurial, like I did, I am sure it would feel much smoother, it is just git that is messy. For jj, it looks like they took the best parts of git and mercurial, so hopefully, the transition will be rather painless.
• kristo 6mo ago
  I followed steve's excellent tutorial about two months ago, and haven't looked back. I have never felt so competent at git (vcs rather) as I do now. jj is so much simpler and easier for me to reason about.
• tracker1 6mo ago
  Seems interesting, but tbf, I only really use a small subset of git commands as it is... I've tended to practice a few workflows that just reduce the overhead and risk for conflicts.
• bikelang 6mo ago
  Reading threads like this and the GitHub stacked PRs just makes me feel like an alien. Am I the only one that thinks that commits are a pointless unit of change? To me - the PR is the product of output I care about. The discussion in the review is infinitely more important than a description of a single change in a whole series of changes. At no point are we going to ship a partial piece of my work - we’re going to ship the result of the PR once accepted. I just squash merge everything now. When I do git archeology - I get a nice link to the PR and I can see the entire set of changes it introduced with the full context. A commit - at best - lets me undo some change while I’m actively developing. But even then it’s often easier to just change the code back and commit that.
  • steveklabnik 6mo ago
    You're not an alien: this is the workflow that GitHub encourages. It's just that not every tool is GitHub. Other systems, like Gerrit, don't use the PR as the unit of change: they use the commit itself. And you do regularly ship individual commits. Instead of squashing at the end, you squash during development.
    • bikelang 6mo ago
      Thanks for explaining that. Having a bit of a (dim) lightbulb moment now. I’ve never used Gerrit - just GitHub and GitLab and Forgejo. So I assumed the PR/MR model was more or less universal. But if smaller development commits are being squashed into the shippable/reviewable unit - then the focus on commits makes a lot more sense.
      • steveklabnik 6mo ago
        You're welcome! It is one of those "do fish realize they're wet" kind of things, tools can shape our perception so strongly that you don't even realize that they're doing it!
  • rs545837 6mo ago
    You could agree that the PR is the meaningful unit for shipping, but push back gently that for agents working in parallel, the commit/changeset level matters more than it used to because agents don't coordinate the way humans do. Multiple agents touching the same repo need finer-grained units of change than "the whole PR."
• ai_slop_hater 6mo ago
  Unfortunately OpenAI's models really suck at JJ, while, on the other hand, Opus 4.6 is much better at it, probably due to a later training cut off.
• Aperocky 6mo ago
  With agents, my go to is now have multiple of the same repository and each agents must work on a separate one. Preventing dirty workspace by solving the co-work problem to start with. merges are much more trivial than trying to make agents remember which branch or which folder it is supposed to work on. Disk space is cheaper than mental anguish and token usage.
  • rattray 6mo ago
    What's your naming scheme?
    • Aperocky 6mo ago
      REPO_NAME_0 REPO_NAME_1 REPO_NAME_2 REPO_NAME_3
  • chriswarbo 6mo ago
    https://git-scm.com/docs/git-worktree https://git-scm.com/docs/git-worktree
    • Aperocky 6mo ago
      rare case of feature bloat for git. Still completely optional, thank god linus.
• rattray 6mo ago
  Has anyone tried both jj and gitbutler extensively yet? Both seem to have some interesting new ideas on top of git.
  • ymir_e 6mo ago
    I was hoping someone else had written about it here. From my knowledge there are three different takes on git being worked on which looked interesting. - JJ - GitButler - Zed Zed version system doesn't have that much public info yet, but they wanted to build a db for storing code versions for AI agents. Not sure if this is still the direction, and I'm a bit skeptical, but interested to see what they come up with. Even though git works well enough, I'm certain there will be another preferred way at some point in the future. There are aspects of git that are simply not intuitive, and the CLI itself is not up to standard of today's DX.
• newsoftheday 6mo ago
  OK I read it, I'm not interested, git does exactly what I want.
  • tombert 6mo ago
    That's sort of where I've been stuck with with jj. Maybe someone can convince me otherwise, but to me it hasn't felt sufficiently better than git to justify bothering re-learning this stuff, even if it's relatively easy.
  • deleted 6mo ago
    [deleted]
  • plutokras 6mo ago
    Git wins by not needing to be replaced badly enough. Latley you can just ask an agent to "amend the last commit" so even that is being abstracted away.
• sam_goody 6mo ago
  I use the CLI often enough, but still most of my time is in a GUI. It just makes the diffs easier, the flow simpler, etc. As such, I wanted to break into jj via the GUI, and only adopt the command line after I could visualize the concepts and differences in my head. Alas, the GUI I tried - a VSCode plugin - did more to confuse me than to help, and it made it very easy to catastrophically rewrite the history by accident. I tried another UI and it kept failing and leaving me with cleanup work. I couldn't find a third UI that looked promising. So, I gave up. One less jj user on the planet - no biggie. But I really wonder if it would be worth the effort for some of the jj pushers to try to get a proper UI in place - I bet I am not the only one that likes to learn visually.
• carverauto 6mo ago
  am a big fan, just started using it a few days ago
• jtrueb 6mo ago
  Call me crazy, but jj is more confusing than git.
• jancsika 6mo ago
  I was going to write a big long comment, but honestly it boils down to this: Whatever git's practical benefits over SVN and CVS back in the day (and I can go into the weeds as a user if someone wants that), git was the DVCS that took over from the centralized VCS's of that era. There is nothing in jj, pijul, or Bram Cohen's thing that is anywhere near as dramatic a quality of life improvement as going from VCS to any DVCS. And dramatic improvement is what is needed to unseat git as the standard DVCS. I mean, if you're not doing something so important[1] that it adds a letter to the acronym, it's probably not the next new thing in version control. 1: I originally wrote the word "novel" here. But it has to be big-- something like guaranteeing supply chain integrity. (No clue if a DVCS can even do that, but that's the level of capability that's needed for people to even consider switching from git to something else.)
  • rstuart4133 6mo ago
    There is some truth to that, but to give a different perspective ... A long, long time ago, back when VCS's were novel enough to be of academic interest, I read numerous papers describing what these VCS's could be. They talked in terms of change sets, and applying them like a calculus to source code. In the meantime those of us writing code people actually used were using sccs and rcs, or if you were really unlucky Visual SourceSafe. To us in the trenches those academics were dreamers in ivory towers. With the passage of time we got new VCS that gradually knocked the rough edges off thoase early ones. svn gave us atomic commits, hg gave us a distributed VCS, git gave us that plus speed. But none came close to realising the dreams of those early academics. It seemed like it was an impossible dream. But then along came jj ... and those dreams were realised.
• acoustics 6mo ago
  jj has made me much more comfortable using non-linear DAGs in my trunk-based development workflow. Several changes with the same parent, changes with several different parents, etc. I used to have a habit of imposing an unnecessary ordering structure on my work product. My stack of changes would look like A -> B -> C -> D, even if the order of B and C was logically interchangeable. jj makes DAGs easier to work with because of how it handles conflicts and merges. Now I feel empowered to be more expressive and accurate about what a change actually depends on. In turn, this makes review and submission more efficient.
  • tonfa 6mo ago
    Do you use a mega-merge + absorb workflow on top of the faned-out changes?
• eranation 6mo ago
  For those who switched, what is the main selling point that made you stay with Jujutsu?
  • tonfa 6mo ago
    For me, can do anything complex in terms of history rewriting without ever shooting myself in the foot (worse case just `jj undo`). And the UI is pretty intuitive so don't really have to search for a solution, usually the command to use is obvious (tho I guess now you could delegate the UI to an LLM to ask it to give you the right incantations).
• 0xnadr 6mo ago
  Interesting to see more Rust CLI tools gaining traction. The undo-everything model is compelling. I've lost work to bad git rebases more times than I'd like to admit.
• TrysterosEmp 6mo ago
  Why should you care about jj? Look, ethereal, balaeric Gothenburg indie from the 2010s may not be important in the grand scheme of things, but their strong hip hop influence was genuinely exciting at the time. When the great chill wave summer of 2009 crested, you definitely cared about jj’s otherworldly grooves and lil Wayne samples. Even if they never did reach the euphoric highs of Washed Out or even label mates The Tough Alliance.
  • erdaniels 6mo ago
    Preach... thank you
• dmitshur 6mo ago
  What is the current story for serving jj repositories over HTTPS? Git has https://git-scm.com/book/ms/v2/Git-on-the-Server-The-Protocols#:~:text=HTTP%20protocol%20first.-,Smart%20HTTP,-Smart%20HTTP%20operates https://git-scm.com/book/ms/v2/Git-on-the-Server-The-Protoco... . Does jj have something better, equivalent, or nothing (at this time) at all?
  • steveklabnik 6mo ago
    Unless you're at Google (or writing your own backend), jj talks to a git server, and so you'd just do exactly that: host a git repo over https.
    • dmitshur 6mo ago
      I am at Google, but that's probably not relevant since the reason I was curious about this is that my personal website currently implements a git server over HTTPS[1], and git's CLI/API for that is not the friendliest[2]. It sounds like jj hasn't reached the point of tackling this problem space yet, which is okay. Thanks for confirming I wasn't missing out on something. [1] https://pkg.go.dev/github.com/shurcooL/home/internal/code#NewGitHandler https://pkg.go.dev/github.com/shurcooL/home/internal/code#Ne... [2] https://pkg.go.dev/github.com/shurcooL/home/cmd/githook/pre-receive https://pkg.go.dev/github.com/shurcooL/home/cmd/githook/pre-...
      • steveklabnik 6mo ago
        Yeah all I meant to say is that `jj piper` exists in Google's private fork of jj, so not relevant for your case :) You should be able to use jj with your server just fine.
• ibejoeb 6mo ago
  A lot of the discussion focuses on differences from git and how it uses the git storage strategy under the hood. Honestly, I think you should just ignore all of that. Don't think about git. Here's a workflow that'll get you through your daily usage: On a clean repo: $ jj The working copy has no changes. Working copy (@) : abcdef a53ff9ba (empty) (no description set) Parent commit (@-): qrstuv 4bc1bf34 the last thing you did Make some changes. $ jj # shows status (new, modified, deleted, moved, etc.) If you're satisfied with your changes, $ jj commit -m "made changes" Now `jj` is back to clean state. You don't need to do `jj new` to continue working linearly. Just make your next changes and commit. If you realize that you messed something up, fix it, then `jj squash` and it gets incorporated into that last commit. You only `jj new -r lmnop` if you want to do some work based on the state of the codebase at revision lmnop, rather than the previous revision, which is a figurative branch. No need to manually create and name branches. As for git history: just do `git log` to see what's actually going on. It's a clean history reflecting your `jj commit`s. You're not going to see all of the stuff the jj machinery does.
  • skydhash 6mo ago
    If I really wanted that, I could create an alias like alias.save="!git add -A; git commit -m" And then use $ git save "made changes"
    • ibejoeb 6mo ago
      You could. That's not the point. I suggesting that if you want to try jj, try it based on its affordances, not by comparing it to how you'd do it differently with git. Most of the tutorials start with git and try to teach you how to change your thinking. I think the project would find many more fans if it didn't make such a big deal about being kinda like git.
      • skydhash 6mo ago
        I did try it, but it was not my cup of tee. Git fits my mental modal better. Branches are experiments, commits are notes in my lab notebook, stashes are notes in scrap of papers, the staging area is for things that I plan to note down and the working tree is the workbench. Then every once in a while I take the notebook and rewrite stuff in it or update it to fit recent changes in the canonical branches. I use magit so the actual operations are just a few quick key presses. I could probably do the same thing with jj, but why use a new tool when the old thing works well, has myriad of integrations, and it's fairly standard.
• lofaszvanitt 6mo ago
  Someone add attribute and rights handling to git. Plus empty dirs. And thats all.
• LoganDark 6mo ago
  I tried jj and holy wow it's so perfect for me. There's a learning curve but I picked a bunch of it up within a couple hours and I am going to be pretty much using only jj from now on.
• aubanel 6mo ago
  Does jj work well with parallel agents? The current problem that I often have is that I want to work on several things in parallel through several agents, always forget to do worktrees, then the different branches of work tend to step on each other Does JJ make it simpler?
  • hi-im-buggy 6mo ago
    jj supports workspaces, akin to git's worktrees. They've felt pretty natural for me to use. The only caveat is that if you're in jj repo that uses git colocation, only your main workspace will have a `.git/` directory. When you have other infra set up that assumes you're in a valid git repo, this can be a little annoying.
• hi-im-buggy 6mo ago
  jj's mental model maps really well to Gerrit's code review system. It's also really nice to have `jj undo` and automatic rebasing.
• CodeCompost 6mo ago
  I like the idea but it feels like more of an attempt to usurp Git than actually solving a problem.
• deleted 6mo ago
  [deleted]