Live data from Hacker News

Jujutsu and Radicle

radicle.xyz

71–80 of 97 posts

Re: Jujutsu and Radicle

#71
post #62

Earlier quoted context omitted.

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 automa…

Ah interesting. That makes sense, thanks!

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.

Re: Jujutsu and Radicle

#73
post #46

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

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 hat…

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.

Re: Jujutsu and Radicle

#74
post #24

Earlier quoted context omitted.

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 unfin…

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…

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 ` 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.

Re: Jujutsu and Radicle

#75
post #70
post #45

Earlier quoted context omitted.

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…

jjui is what you're looking for. Incredible TUI https://github.com/idursun/jjui

I use jjui, but it still punts to scm-record for interactive hunk selection.

Re: Jujutsu and Radicle

#76

Earlier quoted context omitted.

Wouldn't you end up with like 1 million commits in a decent size projects really quickly?

These are entirely local, and can be GC’d.

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

Re: Jujutsu and Radicle

#77
post #64
post #36

Earlier quoted context omitted.

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.

Gitpatch looks really great. And I greatly appreciate you listing out alternatives. Do you have any plans to allow for self-hosting?

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.

Re: Jujutsu and Radicle

#78
post #15

Earlier quoted context omitted.

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.

> 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.…

Spot on to both.

Re: Jujutsu and Radicle

#79
post #10

Earlier quoted context omitted.

Why say yup to disagree with the premise of the article?

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.

I tried it and decided not to switch because there was simply no way to resolve the line endings problem on Windows and sync up jj with our git repo

Re: Jujutsu and Radicle

#80

Earlier quoted context omitted.

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.

I tried it and decided not to switch because there was simply no way to resolve the line endings problem on Windows and sync up jj with our git repo

The line ending thing should have been resolved very recently, I believe: https://github.com/jj-vcs/jj/pull/6728
Post reply on HN