8 ms·

Jujutsu and Radicle

132 points by vinnyhaps 1y ago

vlovich123 1y ago
How are these patch sets reviewed? Is there some mechanism for integrating with review systems like GitHub?
- watusername 1y ago
  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 1y ago
    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 1y ago
      (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!!
      - koreth1 1y ago
        As a satisfied customer of yours, the prospect of having to give up Graphite is the main thing keeping me from giving jj a try at my day job. Ironic, since if there are a bunch of people in my boat, the lack of us in jj's user base will make it that much harder for jj to cross the "popular enough to be worth supporting" threshold.
        jacobegold 1y ago
        My ideal is really just a version of `gt sync` and `gt submit` that handle updating the Graphite + Github server-side of things let you use `jj` for everything else, I think it could feel super nice. Probably not as simple as my dreams, but hopefully something we can get to with enough interest!
    - stouset 1y ago
      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 1y ago
        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 1y ago
        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 1y ago
        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-parallelize https://jj-vcs.github.io/jj/latest/cli-reference/#jj-paralle...
        sgjennings 1y ago
        I mostly solve this by putting a branch on the merge commit M, then the “real” change R is a child of that. The PR is targeted to merge R into M. As the parents of M are merged, I rebase the whole stack. When M has a single parent left, I abandon M and retarget the PR to merge R into that parent. It requires a little babysitting, but the PR shows the diff I want it to.
    - shayief 1y ago
      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 1y ago
        Gitpatch looks really great. And I greatly appreciate you listing out alternatives. Do you have any plans to allow for self-hosting?
        shayief 1y ago
        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.
vinnyhaps 1y ago
Follow along with Fintan as he details how he put his Git workflow into submission with Jujutsu and Radicle
mac-monet 1y ago
Just waiting for Jujutsu to support submodules and I can replace git completely.
- IshKebab 1y ago
  I really hope they don't add submodule support. There's an opportunity to do something that works properly!
  - nrclark 1y ago
    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 1y ago
      Do you know of something that's good for what people tend to misuse Git submodules for? A multi-repo workspace thingamajig.
      - gpm 1y ago
        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 1y ago
        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.
WolfeReader 1y ago
Jujutsu is so good. I'm using a megamerge workflow and absolutely loving it!
- codethief 1y ago
  I had to google to understand what that workflow is about. This blog post seems to explain it quite well and it sounds pretty great: https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj-absorb/ https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj...
wirybeige 1y ago
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 1y ago
  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 1y ago
    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.
JimDabell 1y ago
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 1y ago
  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 1y ago
    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 1y ago
      > 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.
      - 1y ago
frizlab 1y ago
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 1y ago
  Why say yup to disagree with the premise of the article?
  - do_not_redeem 1y ago
    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 1y ago
      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 1y ago
        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.
roman_soldier 1y ago
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 1y ago
  jj undo, and jj op log && jj op restore can get you out of any trouble.
- landr0id 1y ago
  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/ https://jj-vcs.github.io/jj/latest/operation-log/
  - diarrhea 1y ago
    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.
  - roman_soldier 1y ago
    No, it was a clean jj init'ed repo. I think I just hadn't grokked it properly. Might give it another shot but as git works well for me right now finding the motivation/time is an issue.
LadyLag 1y ago
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 1y ago
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 1y ago
  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 1y ago
  Claude knows how to use jj just fine.
throwaway755755 1y ago
What happened to Radicle?
- _flux 1y ago
  Did you hear something? 1.3.0 was released on August, so it seems it's still a functional project.
nchmy 1y ago
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 https://github.com/idursun/jjui
ephimetheus 1y ago
I got into jujutsu recently for the mega merge workflow. The only thing I’m missing now is support for git submodules, especially when working with workspaces. This requires me to keep using git worktrees with collocated jj in each of them, which is suboptimal.
- steveklabnik 1y ago
  Does jj’s own workspaces not help? I don’t use submodules so I don’t know.

Jujutsu and Radicle

132 points by vinnyhaps 1y ago

vlovich123 1y ago

How are these patch sets reviewed? Is there some mechanism for integrating with review systems like GitHub?

watusername 1y ago
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 1y ago
  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 1y ago
    (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!!
    - koreth1 1y ago
      As a satisfied customer of yours, the prospect of having to give up Graphite is the main thing keeping me from giving jj a try at my day job. Ironic, since if there are a bunch of people in my boat, the lack of us in jj's user base will make it that much harder for jj to cross the "popular enough to be worth supporting" threshold.
      - jacobegold 1y ago
        My ideal is really just a version of `gt sync` and `gt submit` that handle updating the Graphite + Github server-side of things let you use `jj` for everything else, I think it could feel super nice. Probably not as simple as my dreams, but hopefully something we can get to with enough interest!
  - stouset 1y ago
    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 1y ago
      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 1y ago
        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 1y ago
      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-parallelize https://jj-vcs.github.io/jj/latest/cli-reference/#jj-paralle...
      - sgjennings 1y ago
        I mostly solve this by putting a branch on the merge commit M, then the “real” change R is a child of that. The PR is targeted to merge R into M. As the parents of M are merged, I rebase the whole stack. When M has a single parent left, I abandon M and retarget the PR to merge R into that parent. It requires a little babysitting, but the PR shows the diff I want it to.
  - shayief 1y ago
    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 1y ago
      Gitpatch looks really great. And I greatly appreciate you listing out alternatives. Do you have any plans to allow for self-hosting?
      - shayief 1y ago
        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.

vinnyhaps 1y ago

Follow along with Fintan as he details how he put his Git workflow into submission with Jujutsu and Radicle

mac-monet 1y ago

Just waiting for Jujutsu to support submodules and I can replace git completely.

IshKebab 1y ago
I really hope they don't add submodule support. There's an opportunity to do something that works properly!
- nrclark 1y ago
  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 1y ago
    Do you know of something that's good for what people tend to misuse Git submodules for? A multi-repo workspace thingamajig.
    - gpm 1y ago
      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 1y ago
        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.

WolfeReader 1y ago

Jujutsu is so good. I'm using a megamerge workflow and absolutely loving it!

codethief 1y ago
I had to google to understand what that workflow is about. This blog post seems to explain it quite well and it sounds pretty great: https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj-absorb/ https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj...

wirybeige 1y ago

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 1y ago
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 1y ago
  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.

JimDabell 1y ago

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 1y ago
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 1y ago
  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 1y ago
    > 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.
    - 1y ago

frizlab 1y ago

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 1y ago
Why say yup to disagree with the premise of the article?
- do_not_redeem 1y ago
  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 1y ago
    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 1y ago
      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.

roman_soldier 1y ago

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 1y ago
jj undo, and jj op log && jj op restore can get you out of any trouble.
landr0id 1y ago
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/ https://jj-vcs.github.io/jj/latest/operation-log/
- diarrhea 1y ago
  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.
- roman_soldier 1y ago
  No, it was a clean jj init'ed repo. I think I just hadn't grokked it properly. Might give it another shot but as git works well for me right now finding the motivation/time is an issue.

LadyLag 1y ago

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 1y ago

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 1y ago
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 1y ago
Claude knows how to use jj just fine.

throwaway755755 1y ago

What happened to Radicle?

_flux 1y ago
Did you hear something? 1.3.0 was released on August, so it seems it's still a functional project.

nchmy 1y ago

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 https://github.com/idursun/jjui

ephimetheus 1y ago

I got into jujutsu recently for the mega merge workflow. The only thing I’m missing now is support for git submodules, especially when working with workspaces. This requires me to keep using git worktrees with collocated jj in each of them, which is suboptimal.

steveklabnik 1y ago
Does jj’s own workspaces not help? I don’t use submodules so I don’t know.