[HN Gopher] Jujutsu and Radicle
___________________________________________________________________
Jujutsu and Radicle
Author : vinnyhaps
Score : 111 points
Date : 2025-08-14 13:58 UTC (9 hours ago)
(HTM) web link (radicle.xyz)
(TXT) w3m dump (radicle.xyz)
| vinnyhaps wrote:
| Follow along with Fintan as he details how he put his Git
| workflow into submission with Jujutsu and Radicle
| mac-monet wrote:
| Just waiting for Jujutsu to support submodules and I can replace
| git completely.
| IshKebab wrote:
| I really hope they _don 't_ add submodule support. There's an
| opportunity to do something that works properly!
| nrclark wrote:
| I feel like submodules are one of Git's most misused
| features. They're intended as a method of pinning read-only
| upstream Git dependencies. And when used for that purpose,
| they're good at what they do.
|
| I think that people mostly get a bad taste in their mouths
| because they try to use submodules for building multi-repo
| workspaces where a developer might need to commit in some/all
| of the repos. They're a bad fit for that problem, but it's
| mostly because that's not what they were designed to do.
|
| I'd love to see the jj team tackle case #2, personally. I bet
| they'd do a pretty good job of it.
| hju22_-3 wrote:
| Do you know of something that's good for what people tend
| to misuse Git submodules for? A multi-repo workspace
| thingamajig.
| gpm wrote:
| I _think_ what I 'd like for that is a mono-repo with
| better support for subsetting instead of a multi-repo
| with better support for unioning.
|
| I understand that Google (and may some of the other
| fangs) have tooling like that internally - but I haven't
| had the pleasure of using it.
| JoshTriplett wrote:
| That doesn't help if you actually need those repositories
| to exist separately.
|
| For instance, consider the problem of having an external
| Open Source project your company maintains or heavily
| contributes to, and which also has common libraries
| shared with internal non-public work. Or, the same
| problem applies if you have a downstream Open Source
| project that needs to incorporate and vendor an upstream
| one but easily contribute changes upstream.
|
| Some folks do this by generating the external repo as a
| filtered version of an internal monorepo, but that's
| awful in so many ways, and breaks the ability to properly
| treat the external repo as a first-class thing that can
| merge PRs normally. It leads to workflows where people
| submitting PRs feel like their work gets absorbed
| internally and maybe eventually spit back out the other
| end, rather than just being merged.
| gpm wrote:
| Is the pain with publishing a subsetted version of the
| internal monorepo anything but a tooling limitation where
| things like pushing into that that subsetted version, and
| merging changes made on the subsetted version, aren't
| automatic because our tools don't natively understand
| subsets?
|
| It would require forge integration, but I'd like a world
| where I could make a PR to `company/open-source-subdir`
| and the company could merge that PR and that was that
| without any extra steps because open-source-subdir is
| just a publicly published subset of the `company` repo.
| JoshTriplett wrote:
| No, it's not just a tooling limitation. Or, at least, not
| one solvable just by having forges expose public subsets
| of private repos. That _might_ partially solve the
| simplest case of `company /open-source-subdir`, if the
| company trusts the forge tooling to handle subsetting and
| to not expose more than they want, but it doesn't solve
| the more general problem.
|
| Consider the case where the repositories are owned by
| different entities, for instance, or have different
| governance. For instance, Project X needs to vendor
| Project Y, and have a few downstream patches that they're
| working on upstreaming.
|
| Right now, the two major options include:
|
| - Use a submodule. Experience all the pain of submodules.
|
| - Use some tooling to fold the repo into your own repo.
| Extract commits from it when you want to upstream.
| Experience all the pain of not having the original
| commits and the ability to easily pull/merge/cherry-
| pick/rebase, plus pain when you make changes across that
| repo and other code.
| IshKebab wrote:
| > They're intended as a method of pinning read-only
| upstream Git dependencies. And when used for that purpose,
| they're good at what they do.
|
| No they are not. In _theory_ they _could_ be good, but the
| actual implementation falls down in ... let me count the
| ways:
|
| 1. Transitive dependencies. I sure do love that my
| company's submodule-based repo has 12 copies of one of our
| dependencies.
|
| 2. Checkouts don't work any more. You can't simply `git
| switch <branch>`, _especially_ if that other branch has a
| different set of submodules. And good fucking luck if one
| branch has a submodule and another branch has a not-
| submodule in the same location.
|
| 3. They don't work with worktrees. In theory... maybe. In
| practice, the documentation says not to try and in my
| experience it is right!
|
| 4. The submodule URLs are now baked into the git repo. This
| means you can't mirror the repo anymore easily. I've even
| had cases where I couldn't even clone the repo because the
| authors had used `ssh://` URLs which required permissions I
| didn't have. It's insane that the authentication method
| gets baked into the repo. I have no idea why they
| implemented it like this.
|
| 5. The tooling experience is just way worse. Want to see a
| diff of everything you've changed? Well you can't. If
| you've changed anything in a submodule you just get a hash
| difference, or at best a list of commits (which is better
| but it's not even the default!).
|
| Before you instinctively reach for the "well obviously it
| _must_ work like that " part of your brain, take a moment
| to think if it _should_ work like this. I can think of
| several ways to do it better (beyond just making the
| implementation less buggy).
| JoshTriplett wrote:
| > They're intended as a method of pinning read-only
| upstream Git dependencies.
|
| Except, dependencies are rarely read-only.
| WolfeReader wrote:
| Jujutsu is so good. I'm using a megamerge workflow and absolutely
| loving it!
| wirybeige wrote:
| I think this is the first blog on JJ that has made me want to use
| it. The flow seems like it could be quite a bit better than git
| prerok wrote:
| Ok, so I have to admit I started skimming soon, because after
| explanation of `jj new`, I thought this is just `git commit
| --allow-empty`. Oh, and you can specify the message! Add `-m`
| and you are done.
|
| Then it's a series of either git ammends or `git checkout -b`
| etc.
|
| Now, since there is so much high praise in this comment and
| sibling comments, what am I really missing? From the post it
| just seems like the person hates branches for an unspecified
| reason.
|
| Here's my workflow, of the past 15 years:
|
| - git checkout main - git pull
|
| Do some changes. Do some more changes. Now:
|
| - git checkout -b <feature-name> - git status - gvim into every
| file and then :Gvdiffsplit, select what I want to stage for
| each file - git push # open PR if I think it's ready
|
| For the remaining changes not in the commit, I either create a
| separate commit, or discard.
|
| An honest question of curiosity, how does jj improve this
| workflow?
| judofyr wrote:
| Here's a few workflows that I really enjoy in jj:
|
| - While I'm working on something I can do `jj desc` and start
| writing the commit message. Every edit is automatically being
| added to this change.
|
| - My work tree is dirty and I quickly want to switch to a
| clean slate. In Git: (1) either do `git stash` where I'm
| definitely is going to forget about it or (2) do `git commit
| -a -m wip && git switch -c some-random-branch-name`. In jj:
| `jj new @-`. That's it! If I run `jj log` then my previous
| change shows up. No need to come up with arbitrary names.
| It's so refreshing to move changes around.
|
| - I'm working on a stack of changes and sometimes need to
| make edits to different parts. In Git (1): Each change is its
| own branch and I need to switch around and do a bunch of
| rebases to keep them in sync. In Git (2): I have one branch
| with multiple commits. I make changes towards the final state
| and then do `git rebase -i` to move them upwards to where
| they belong. Biggest downside: I'm not actually testing the
| changes at the point where they end up and I'm not guaranteed
| it makes sense. In jj: I do `jj new <CHANGE>` to make changes
| further up in the stack. Once I'm happy with it I do `jj
| squash` and every dependent change is automatically rebased
| on top.
|
| - And finally: I can solve merge conflicts when I want to! If
| any rebasing leads to a merge conflict I don't have to deal
| with it right away.
| Bjartr wrote:
| If you already have 15 years of muscle memory for efficient
| use of git it's probably not that valuable to you. AFAIU jj's
| goal is to allow people to be as effective in a workflow like
| you describe without having to stumble through all of git to
| find the happy path building that muscle memory.
| riwsky wrote:
| That exact workflow? It won't improve much. But it tends to
| change peoples' workflows.
|
| For example: let's say you have a few feature branches in
| flight at the same time, and you want to make a change to one
| of them to address some PR feedback. In your git workflow,
| that presumably means something like `git stash; git checkout
| feature-name; vim-and-actually-make-the-change; git add -up;
| git commit; git push; git checkout whatever-you-were-doing-
| before; git stash pop`, +- a `--amend` depending on your PR
| philosophy. A common workflow in jj is to instead sit on top
| of a merge commit with all the feature branches at once, and
| handle this like `vim-and-actually-make-the-change; jj squash
| -i --into feature-name; jj git push`. You can do something
| like the latter in git too, of course, it just tends to get
| hairy relatively quickly with rebases and merge conflicts.
| steveklabnik wrote:
| It may not make it fundamentally better, but it might make it
| easier and more pleasant. That's what jj does for me; my
| basic workflow would work in git too, but it's just nicer and
| easier. Which I would not have guessed, as I was very
| comfortable with git before I switched.
|
| In your case, jj's ability to slice and dice commits is
| really nice; jj split is built in and works similarly, but
| you also have other tools too.
| vlovich123 wrote:
| How are these patch sets reviewed? Is there some mechanism for
| integrating with review systems like GitHub?
| watusername wrote:
| From git's perspective, jj bookmarks are just regular git
| branches, so you can just do `jj git push` and open a PR as
| usual.
|
| However, unlike git, jj bookmarks are pinned to change IDs
| instead of immutable commit SHA-1s. This means that stacked PRs
| just work: Change something in the pr-1 bookmark, and all
| dependent bookmarks (pr-2, pr-3, ...) are automatically
| updated. A `jj git push --tracked` later and everything is
| pushed.
| vlovich123 wrote:
| And do downstream PRs show just what changed or is the merge
| target against main which then just keeps accumulating
| differences?
|
| This is one of the strengths I appreciate about graphite
| which is that the PRs are always on the preceding branch but
| it knows that when you go to merge it should actually really
| retarget and merge against main.
| jacobegold wrote:
| (Graphite dev here)
|
| Yeah - the key thing here is that there is work to be done
| on the server, so JJ likely either needs its own forge or a
| GitHub App that handles managing PRs for each JJ commit.
|
| I'm a huge fan of the JJ paradigm - this is something I'd
| love for us to be able to do in the future once one or both
| of: - we have more bandwidth to go down this road - JJ is
| popular enough that its worthwhile for us to do
|
| That said I'd also love to see if anyone in the community
| comes up with an elegant GH app for this!!
| stouset wrote:
| Github and GitLab both allow you to specify a merge target
| other than main and only show you the differences from the
| target. If that target is merged into main, they're
| retargeted to main.
|
| There is definitely room for an improved forge experience
| that takes advantage of the additional powers of jj, but
| it's no worse an experience using them today than it is
| with git.
| nothrabannosir wrote:
| By any chance did you manage to get branch protection
| rules working neatly in this paradigm? Ideally I'd like
| any CI to be re-run as necessary and the branch to be
| automatically merged if review was approved and its base
| became master, but I never got a completely hands free
| setup working. Maybe a skill issue though.
|
| Basically if I have five stacked PRs, and the newest four
| get an approval, I want everything to stay in place no
| merges. Then when the base (oldest) PR gets approved, I'd
| like the PRs to all get merged, separately , one after
| the other, without further interaction from me.
|
| Does GitHub's merge queue implementation support that?
| stouset wrote:
| Gitlab's does when you have merge queues set up. I'm not
| sure about GitHub, we didn't have that kind of setup at
| the last place I worked.
| diarrhea wrote:
| One problem remains: jj makes it a breeze to parallelize
| work, but descendant changes will then end up with
| multiple parents. But PRs cannot target multiple target
| branches at once - so you cannot point them at both at
| once.
|
| cf. https://jj-vcs.github.io/jj/latest/cli-reference/#jj-
| paralle...
| shayief wrote:
| Gitpatch author here.
|
| Gitpatch attempts to build a Git hosting with native
| support for patches and commit-based review system, where
| each commit is its own patch. It's also smart to handle
| force pushes and can update or reorder patches as needed.
| jcgl wrote:
| Gitpatch looks really great. And I greatly appreciate you
| listing out alternatives.
|
| Do you have any plans to allow for self-hosting?
| shayief wrote:
| thanks for checking it out.
|
| yeah, I plan to release it under AGPL at some point when
| it's more complete. Currently it still needs more work.
| But no timeline yet.
| JimDabell wrote:
| I've started using Jujutsu recently and was surprised at how low
| friction it was to switch. If you're like the author and keep
| hearing about it without giving it a shot, I suggest you just sit
| down and try it - it's a lot less effort than you might expect.
| sestep wrote:
| I really like all the concepts and have only heard good things,
| so I tried it but wasn't able to figure out how to use it as
| effectively as I can use Git. Specifically, I use VS Code and
| do a lot of stuff with the IDE's builtin support for selecting
| specific parts of files to stage, and I was hoping to be able
| to do something similar for jj split. I asked the Jujutsu
| Kaizen devs on Discord and they said that isn't currently
| implemented. They did also mention that VisualJJ might have
| more what I want, but I'm reluctant to switch to JJ only to
| have to rely on a closed-source tool.
|
| Are there others who've previously made heavy use of VS Code's
| builtin Git staging support and have successfully migrated to
| JJ? Anything I'm missing?
| stouset wrote:
| As far as I know right now, no editors have great built-in
| support. As a heavy CLI user of (previously) git and now jj,
| selecting changes graphically is genuinely the one thing I'm
| envious of. The TUI that jj uses for interactive changes,
| `scm-record`, is fine but not great. It gets the job done but
| it could be so much more.
|
| Getting _really_ good diff and conflict editor support into
| VS Code, Zed, et al is going to be a huge win when it comes.
| gpm wrote:
| > The TUI that jj uses for interactive changes, `scm-
| record`, is fine but not great.
|
| The change selection TUI is one of the things that I'm
| happiest with in jj over the equivalent in git. It's a huge
| quality of life improvement over git's version.
|
| Could it be even better? Probably... but compared to `git
| add -p`... it is already way better.
| sestep wrote:
| Right, but the only time I've ever used `git add -p` was
| just to try it out years ago and be like "yep that sucks"
| and go back to using Magit (and then later VS Code).
| Those are my actual baselines.
| gpm wrote:
| Totally fair, I stubbornly used `git add -p` anyways
| because the terminal is where I want that tool to live,
| but I entirely understand why other people have different
| habits here.
| nchmy wrote:
| jjui is what you're looking for. Incredible TUI
|
| https://github.com/idursun/jjui
| stouset wrote:
| I use jjui, but it still punts to scm-record for
| interactive hunk selection.
| diarrhea wrote:
| One of my favorite features of jj is file watching. Once set
| up, jj will snapshot the repo on every filesystem event. This
| means on every file save, you get a git commit! It provides
| arbitrarily fine-grained commit history, and works across all
| tools (not just your IDE). I set it up in the config and it has
| "just worked" ever since.
|
| The result is that `jj evolog -p` will show detailed history of
| your actions. But all but the most recent commit are _hidden_ ,
| so neatly tucked away behind the same _change_ as usual.
|
| Another favorite is git no longer yelling at me and having
| meltdowns about switching branches - "files would be
| overwritten, please stash". This never happens in jj, by
| design. It's nicer than "auto-stash" options of recent git
| versions.
| typpilol wrote:
| Wouldn't you end up with like 1 million commits in a decent
| size projects really quickly?
| steveklabnik wrote:
| These are entirely local, and can be GC'd.
| typpilol wrote:
| Oh I understand. I guess it works just like the local
| history plugin for vscode. It makes a snapshot of every
| file edit as well.
|
| Thanks
| frizlab wrote:
| Yup. Still 0 incentive to try jj. I'm still very much convinced
| most of the problems solved by jj either do not exist or are
| already solved by recent features of git.
|
| It's good alternatives of popular tools exist but git would not
| be my first bet as a tool that needs fixing...
| magnio wrote:
| Why say yup to disagree with the premise of the article?
| do_not_redeem wrote:
| Some people just enjoy being contrarian.
|
| I always enjoy how on jj articles, 90% of commenters tried it
| and switched, 10% never bothered to try it, and 0% tried it
| but decided not to switch.
| IshKebab wrote:
| I dunno, I've tried it and I think I will stick with Git
| for a while longer at least. I really don't like the fact
| that it automatically commits changes in the working tree.
| Apparently you can turn it off but.. yeah I dunno.
|
| I may change my mind. Especially if they provide a less
| shit alternative to submodules and LFS. (And I agree this
| guy is just being contrarian - jj definitely _does_ fix
| some Git annoyances.)
| stouset wrote:
| This was the thing that stopped me from giving jj a shot
| for the longest time, but it turned out to be a complete
| non-issue. Definitely _don 't_ turn it off!
|
| The "aha" moment you might be missing is that you should
| consider your latest revision to just be the staging
| area. `jj commit -i` (shorthand for `jj describe; jj
| split -i`) is effectively `git add -i; git commit`. If
| you're worried about accidentally pushing unfinished
| work, don't be! It won't let you push changes without a
| message by default, and you update bookmarks (e.g.,
| branch pointers) at your discretion anyway. Both of these
| mean that `jj git push` isn't going to accidentally push
| a bunch of in-flight work.
|
| Think of it less like jj commits everything by default,
| and more like your working copy gets the benefits of
| change tracking and being able to take part in repo
| operations even when you haven't taken a moment to make a
| commit.
| IshKebab wrote:
| Say I check out a branch (or bookmark or whatever). I
| compile it. Some stuff doesn't work. I add some debug
| printfs. Compile it again. Ok I'm done now.
|
| In git I can just revert all the changes and I haven't
| modified anything important. In `jj` won't I have
| actually added all of those debug printfs to the top
| commit of that branch? Now I have to _manually_ revert
| the edit?
|
| As I understand it, the answer is "aha, but you just have
| to remember to `jj new` before you do any edits. The
| problem is I'm very sure I will constantly forget to do
| that. I guess you could say Git is opt-in to modifying
| commits whereas jj is opt-out, and I think I prefer opt-
| in.
|
| I have very little jj experience but does that sound
| accurate? (Genuine question; I would love something
| better than Git.)
| kinghajj wrote:
| In order to "check out a branch" in jj, you would have
| had to run `jj new` already. So your edits won't be
| "added ... to the top commit of that branch", but in a
| new commit (revision) when you checked out the branch.
| Then you can use `jj split` to keep whatever changes are
| important and discard the debug print statements.
| gpm wrote:
| The default command you should reach for with jj to
| checkout a branch is `jj new branch` which creates a new
| commit to store your debug prints. You shouldn't do a two
| step process where you can forget the second step in the
| first place.
|
| That said, if you do for whatever reason run `jj edit
| branch` instead (which enables the case you are
| discussing), jj will have snapshotted the previous change
| so you can still automatically revert the debug prints
| using jj evolog; jj restore --from
| old_commit_id
| IshKebab wrote:
| Ah interesting. That makes sense, thanks!
| kps wrote:
| Better still, you can keep your debug printfs around on
| top of your 'pushable' work, and they'll be automatically
| be rebased as the tree changes underneath. If there are
| conflicts, you don't have to deal with them unless and
| until you actually want to use the conflicted code again.
| stouset wrote:
| In git you can _also_ revert all the changes and you
| haven 't modified anything important! `jj restore` or `jj
| abandon` would let you undo your changes or abandon the
| entire revision.
|
| As others have noted, checking out a branch and
| accidentally modifying one of the commits on it is
| actually kind of hard to do. `jj git fetch` pulls in
| remote changes to your repo, but you don't "check out a
| branch": you either `jj edit` an existing commit or
| create a new one entirely with `jj new`. So you're
| unlikely to accidentally overwrite a commit by accident.
| I even find myself using `jj edit` less and less these
| days; if I want to change an existing commit (even if
| it's in the middle of a chain of commits), it's easy to
| `jj new <commit-to-modify>` and then `jj squash` the
| modifications into it. This allows me to double-check the
| modifications I'm making before I decide to commit to
| them (pun intended).
|
| That said, I absolutely _have_ forgotten to `jj new`
| before. Mostly this happens when I plop down at the
| laptop and start making changes without remembering to
| make a new revision. Whatever revision I happened to be
| on gets all those edits. Sometimes I work for quite
| awhile before realizing this, and so having to pick out
| which changes belong where piecemeal would be a ton of
| work.
|
| But this is _precisely_ the power of having all these
| changes in the repo as a revision. I can use all my SCM
| tooling to solve the problem for me! For the sake of this
| example, let 's assume that I've pushed all my changes to
| a remote branch and then stupidly continued editing them.
| Now my local copy of branchname and branchname@origin
| have diverged; they both have the same revision, but
| different git contents. # Oh no! I've
| accidentally made edits to `master`. `omny` points to two
| # separate git commits; one is my local copy of `master`
| and one is the # remote. > jj log
| @ omny me@example.com 2025-08-14 13:22:15 master* ae25
| | Made some changes | * omny hidden
| me@example.com 2022-03-26 14:49:58 master@origin 79d4
| +-+ Made some changes * notn me@example.com
| 2022-03-23 17:03:05 b192 | Earlier changes
| # First, rebase our local changes onto the remote commit.
| This neatly # splits out the changes I just made
| from the changes that were there # before I
| messed up. > jj rebase --branch master
| --destination master@origin Rebased 1 commits to
| destination Working copy (@) now at: omny?? 67a9
| master* Parent commit (@-) : omny?? 79d4
| master@origin # You can see that now my
| local changes have been rebased on top of # the
| remote copy. Unfortunately, they still have share the
| same # revision id so jj is not happy with me!
| We'll have to put those # changes into a new
| revision and make sure our local `master` points
| # to the same id as the one at `origin`. > jj log
| @ omny?? me@example.com 2025-08-14 13:28:14 master* 67a9
| | Made some changes * omny?? me@example.com
| 2022-03-26 14:49:58 master@origin 79d4 | Made
| some changes ~ # Make a new revision
| for our changes to go into. > jj new
| Working copy (@) now at: plwu 70d8 (empty)
| Parent commit (@-) : omny 79d4 master #
| Abandon the local revision where we accidentally changed
| the # `master` branch. Normally this would get
| rid of our changes, # but `--restore-descendants`
| makes sure that the filesystem # contents of the
| new revision we just made remain unchanged. #
| Since we're getting rid of the revision that made those
| edits, # those edits have to be moved up into
| that new revision in order # for it to look the
| same as it did before! # # Abandon would
| also normally delete our local copy of the #
| `master` bookmark. But `--retain-bookmarks` keeps it, and
| pushes # it back one revision. This is exactly
| what we need! > jj abandon master --restore-
| descendants --retain-bookmarks Abandoned 1
| commits: omny?? 67a9 master* Rebased 1
| descendant commits (while preserving their content) onto
| parents of abandoned commits Working copy (@)
| now at: plwu 69ce Parent commit (@-) : omny
| 79d4 master # Everything is happy again! My
| recent changes are now on their # very own
| revision. > jj log @ plwu me@example.com
| 2025-08-14 13:33:45 69ce | (no description set)
| * omny me@example.com 2022-03-26 14:49:58 master 79d4
| | Make some changes ~
|
| I want to be clear about something here. I have _never
| done this before_. This isn 't a pattern that's ingrained
| into me. I've certainly accidentally edited the wrong
| revision before, but it's always been relatively easy to
| split out the changes I made so I've never needed to
| really solve this in the general case before.
|
| I read your comment, figured this would probably be the
| easiest way to do it using the primitives I'm familiar
| with, and I tried it. And it worked! I didn't need to go
| digging through manpages to figure out how to do it, it
| was a simple composition of commands I use every single
| day. I did this on a live, real repo I am actively
| working on where I had edits in flight, and just for
| giggles I squashed them into master. I had zero fear
| about doing this because a `jj op restore` would get me
| back to safety no matter what.
|
| This will also work basically unmodified if you _haven
| 't_ pushed the changes. The only difference is you'd use
| the raw revision id instead of `master` and you'd use git
| commit ID of the earlier changes you wanted to keep
| (pulled from `jj evolog`), which you'd substitute
| everywhere I used `master@origin`. This works for _every_
| case where you have two sets of changes in one revision
| and you want to pull out the later changes from the
| earlier ones.
| nocman wrote:
| > Some people just enjoy being contrarian.
|
| And some people just happen to disagree - doesn't
| automatically mean they just like "being contrarian". I
| took the "Yup..." to mean "this is what I was expecting,
| because it agrees with what I have seen before on this
| topic".
|
| > I always enjoy how on jj articles, 90% of commenters
| tried it and switched, 10% never bothered to try it, and 0%
| tried it but decided not to switch.
|
| And some unknown quantity of readers don't see anything
| compelling enough to either try it and/or comment on it
| after they have (or have not) tried it.
| frizlab wrote:
| Spot on to both.
| homebrewer wrote:
| You're reading an extremely biased sample of experiences.
| It's probably the opposite: 90% haven't tried it, 9% tried
| and didn't see any reason to switch, and around 1% have
| switched and won't shut up about it. For an advanced git
| user, it doesn't offer all that much. I used it for a
| couple of weeks and can't say that it saved me any time or
| any amount of work; it was either zero, or so close to zero
| that I wasn't able to notice it.
|
| When Linus and his lieutenants switch over and recommend it
| as loudly as some do here, then I'll take another look.
| Very unlikely IMHO.
| gpm wrote:
| > 90% haven't tried it,
|
| This is almost certainly true.
|
| > 9% tried and didn't see any reason to switch, and
| around 1% have switched and won't shut up about it
|
| This is almost certainly not true. People are far more
| inclined to give negative reviews than positive reviews.
| stouset wrote:
| > For an advanced git user, it doesn't offer all that
| much.
|
| As a (former) advanced git user, nothing could be further
| from the truth. We are always the most passionate cohort
| of jj users in these threads. This is almost certainly
| because jj unlocks a bunch of additional abilities and
| workflows that we've been torturing out of git (or given
| up on, or didn't even conceive was possible) for years.
|
| On the flip side if all you ever do it git pull, git
| commit, git push, jj is probably not going to offer you
| much.
| freeopinion wrote:
| So you're saying that novice jj users don't get any more
| benefits than they would if they made an effort to be an
| advanced git user?
| nixosbestos wrote:
| Wow, just wow.
|
| >For an advanced git user, it doesn't offer all that
| much.
|
| arrogant, and completely absurdly wrong. I've used Git
| for 20 years. `jj` the single best improvement to my
| development workflow in... well, since adopting Git.
|
| > I used it for a couple of weeks and can't say that it
| saved me any time or any amount of work
|
| I would bet 5 figures that's a lie.
|
| > When Linus and his lieutenants switch over and
| recommend it as loudly as some do here, then I'll take
| another look. Very unlikely IMHO.
|
| So despite all this chest puffing, an _appeal to
| authority_ would tip the scales for you?
| stouset wrote:
| There's no need to be antagonistic. We're all friends
| here :)
|
| I am an unabashed jj evangelist and I don't think they're
| lying when they say it didn't save them any time.
| Adoption costs might be small but they're not zero. Some
| workflows are easy with either tool. And some people just
| don't "get" it and struggle to adapt to a different
| mental model. That's okay!
|
| > So despite all this chest puffing, an appeal to
| authority would tip the scales for you?
|
| I think GP was simply saying this would be a clear sign
| to them that if it's mature enough to handle kernel
| developers' needs, that's a good sign it's worth the
| effort to switch. It definitely would be! I can't wait to
| hear if and when kernel developers start switching; it
| will be a huge positive indicator.
| latexr wrote:
| > 0% tried it but decided not to switch.
|
| It's trivial to prove that's not true. Just look at the
| last popular Jujutsu post on HN.
|
| https://news.ycombinator.com/item?id=44643984
|
| https://news.ycombinator.com/item?id=44643763
|
| https://news.ycombinator.com/item?id=44646902
|
| https://news.ycombinator.com/item?id=44645769
|
| https://news.ycombinator.com/item?id=44662803
|
| https://news.ycombinator.com/item?id=44644040
|
| And those are just the replies to the top comment which
| matched "went back".
| stouset wrote:
| To be fair, I more or less invited these responses by
| bringing it up. Organically, complaints are very rare.
|
| Obviously not everyone who tries something is going to
| switch, even if you take as an axiom that the other thing
| is objectively better. But I still think it's notable
| that--without explicitly prompting that type of response
| --so few people seem to have negative experiences with jj
| given how tribal and passionate engineers tend to be over
| tooling.
| 1718627440 wrote:
| > Some people just enjoy being contrarian.
|
| I have recently posted some critical questions. I didn't do
| that because I "enjoy being contrarian" (rather me enjoying
| a discussion). I did that to flesh out, what the benefits
| of JJ are. I think VCSs are interesting, I think Git has
| some issues, but in my opinion most problems are caused by
| a misguided mental models, I haven't/can't tried JJ. Most
| things I heard were workflows that are claimed are not
| possible in Git, but are possible and most-times only a few
| commands. There are other design choices which I disagree
| with and which might bother me.
|
| ("haven't/can't tried JJ" meaning I enjoy running a stable
| distro, but wouldn't mind compiling it myself. But Rust and
| Rust software is a fast moving target, so it is a hassle to
| deal with if you aren't invested in it's ecosystem. Also it
| violates the GNU standard, which makes it unfriendly for
| endusers, but this seams to be the norm nowadays.)
| rootnod3 wrote:
| I mean, undo alone is a killer JJ feature. Sure, you can always
| somehow undo any git operation if you dig deep enough, but the
| ease of use on the JJ side without question.
| stouset wrote:
| The oplog is absolutely amazing. Having such a comprehensive
| safety net means you can have absolutely zero fear from doing
| absolutely anything to your repo, because you can always
| return the _repo itself_ back to a known-good state. It 's
| git's reflog on steroids.
| mrbonner wrote:
| "You miss 100% of the shots you didn't take" - Michael Scott.
| roman_soldier wrote:
| I tried Jujutsu on a simple repo and it ended up a mess I
| couldn't fix. Never had that with git. Might be my lack of
| knowledge but it shouldn't allow this.
| Zambyte wrote:
| jj undo, and jj op log && jj op restore can get you out of any
| trouble.
| landr0id wrote:
| Did you reach out to `git` commands to make changes to the
| repo? If you use jj in a colocated repo you should _only_ use
| jj to manage the repo to ensure it's kept in-sync with jj's
| data.
|
| If you messed up with jj commands, you can use the op log to
| fix https://jj-vcs.github.io/jj/latest/operation-log/
| diarrhea wrote:
| In colocated repos, running _both_ git and jj commands is
| supported. I use it in release workflows which require git
| tags, which jj does not support creating. However, jj will
| pick up ( "import") on git-created tags just fine afterwards.
|
| AFAIK, jj runs "import" before and "export" (to git) after
| every invocation. That means it always has a consistent view.
|
| jj can also handle concurrent edits by itself, think in a
| repo shared across a network. That said, I wouldn't think
| concurrent git commands are safe.
| LadyLag wrote:
| I started using jujutsu after the last round of blog posts here,
| and have found it super super useful to my mental model of git
| and vcs.
|
| Stealing Fintan's `jj tug` alias from this post is something I
| have already found useful. Highly recommend if anyone is on the
| edge of trying to just give it a shot!
| theusus wrote:
| I used jj for a while and it was so problematic and seemed like
| nothing added value as compared to git. And now in the world of
| LLMs it is more difficult to switch to jj.
| r5Khe wrote:
| I actually think jujutsu is _more_ ideal for the agentic era.
| It makes it so easy to explore directions, experiment, play,
| backtrack, move commits around, etc.
| steveklabnik wrote:
| Claude knows how to use jj just fine.
| throwaway755755 wrote:
| What happened to Radicle?
| _flux wrote:
| Did you hear something? 1.3.0 was released on August, so it
| seems it's still a functional project.
| nchmy wrote:
| anyone who is using jj, or curious about using it, please do
| yourselves a favour and check out jjui - its an incredible TUI
| for jj. Brings it to yet another level.
|
| https://github.com/idursun/jjui
___________________________________________________________________
(page generated 2025-08-14 23:01 UTC)