3 ms·

Jj edit isn't even the jj way of doing things. Should be jj new. Unless you have changes stacked after then you'd do jj new -A. And squish when you're done

BeetleB 1y ago
As a relatively new jj user, I'm curious. Why is the jj new -A + squash better than just a jj edit?
- baq 1y ago
  Separation of concerns and performance; when you edit, the commit in the middle of the branch is your working copy and you’ll update the whole branch unnecessarily many times vs just once when you’re on a logical checkpoint.
  - adastra22 1y ago
    Not everyone works by “logical checkpoint” commit strategy. I myself want my tree clean and commits being atomic state transitions. Otherwise git bisect (which I rely on) would break. A lot of the jj strategies in this thread are a bit more cowboy, and I’m surprised.
    - steveklabnik 1y ago
      The key is to be cowboy until you’re happy with things, and then get clean, just like with git. It’s way easier to slice and dice commits with jj and so you can be sloppy at first and it’s easy to turn beautiful afterward.
      - adastra22 1y ago
        That’s not how I use git, at all. I have a messy workspace with a lot of things going on simultaneously, and only selectively stage when something crosses the finish line. Sounds very difficult to do this in jj.
        steveklabnik 1y ago
        Selectively staging is easier in jj. I loved git’s index, jj does it better.
        adastra22 1y ago
        How? The jj documentation seems to be pretty clear about getting rid of the staging area.
        baq 1y ago
        staging isn't needed since everything including the working copy is a commit you can split, rebase, etc. without any checkin step. yes, it does make sense and yes, it works in practice - the uncommitted vs staged vs committed states are very git-specific and don't need to be special in any way. if you check in the wrong thing (note - your working copy is a commit, so by definition you can't not have wrong things checked in at times) you split it (stage and/or commit in git).
        Human-Cabbage 1y ago
        There are a couple main ways to achieve a workflow similar to Git's staging area. #1: Squashing Create a revision for the feature, then create another revision atop that. $ jj new main -m 'feature' $ jj new $ jj @ trtpzvno samfredrickson@gmail.com 2025-09-01 12:32:33 9ac76a0f │ (empty) (no description set) ○ wvzltyyr samfredrickson@gmail.com 2025-09-01 12:32:31 80b2d5d0 │ (empty) feature ◆ zxrulorx samfredrickson@gmail.com 2024-12-11 03:44:38 main 351a2b30 │ all the stuff $ vim $ jj @ trtpzvno samfredrickson@gmail.com 2025-09-01 12:34:50 5516c2b9 │ (no description set) ○ wvzltyyr samfredrickson@gmail.com 2025-09-01 12:32:31 80b2d5d0 │ (empty) feature ◆ zxrulorx samfredrickson@gmail.com 2024-12-11 03:44:38 main 351a2b30 │ all the stuff ~ $ jj squash -i # interactively choose hunks to squash into parent $ jj @ oxqnumku samfredrickson@gmail.com 2025-09-01 12:35:48 8694aa34 │ (empty) (no description set) ○ wvzltyyr samfredrickson@gmail.com 2025-09-01 12:35:48 47110bff │ feature ◆ zxrulorx samfredrickson@gmail.com 2024-12-11 03:44:38 main 351a2b30 │ all the stuff ~ #2: Splitting Create a revision for the feature, then split it up retroactively. $ jj new main -m 'feature' $ jj @ snomlyny samfredrickson@gmail.com 2025-09-01 12:38:39 84c6ecaa │ (empty) feature ◆ zxrulorx samfredrickson@gmail.com 2024-12-11 03:44:38 main 351a2b30 │ all the stuff ~ $ vim $ jj @ snomlyny samfredrickson@gmail.com 2025-09-01 12:39:51 8038bdd4 │ feature ◆ zxrulorx samfredrickson@gmail.com 2024-12-11 03:44:38 main 351a2b30 │ all the stuff ~ $ jj split # interactively choose hunks to keep, splitting the rest into a new revision $ jj @ zpnpvvzl samfredrickson@gmail.com 2025-09-01 12:41:47 5656f1c5 │ debugging junk ○ snomlyny samfredrickson@gmail.com 2025-09-01 12:41:44 1d17740b │ feature ◆ zxrulorx samfredrickson@gmail.com 2024-12-11 03:44:38 main 351a2b30 │ all the stuff ~
- hdjrudni 1y ago
  I forget where I read it (maybe from Martin), but one reason I like to `jj new` before I start any work is just because it makes it easy to revert or abandon if I don't end up liking it. And also easy to diff. `jj new` is pretty much 'free' anyway, every time you make an edit you're creating new commits (not changes!) anyway.
  - BeetleB 1y ago
    Oh I'm good with jj new for any new thing I'm working on. But I was wondering why one would use jj new -A to fix a commit in the past vs jj edit,
    - kps 1y ago
      Mostly to keep the new changes isolated from the original commit until they're ready, I think. The only time I use `jj edit` is to resume a leaf I left in the middle of something (where I might have used `git stash pop` but without needing to stash).
- sfink 1y ago
  My personal opinion: `jj new` is better because it's non-modal. If you use `jj edit`, you're sort of switching to "edit mode": any change you make will trigger a rebase of all descendants.[1] You're live-mutating the core graph structure rather than a harmless appendage node. Also, if you notice something else that needs to be fixed, you can do it but then you'll need to remember to split it out into a separate commit before leaving edit mode. With `jj new` + `jj squash`[2], you're collecting work that you can review as a separate thing anytime as you go along. You don't have to remember anything. If you throw in an unrelated change, you'll notice it if you review the changes before squashing them, so you can split it out then. And I'm pretty much always working in this state even when I'm at the top of my branch, so `jj new some-deep-node` doesn't really change anything. If I get called away and have no memory of what I was doing when I return, it doesn't matter: my jj state tells me exactly where things are and what I was doing. [1] Which is not a huge problem, you have deferred conflict resolution so if something goes wrong you can probably just repair it with normal editing or your editor's undo functionality. [2] I don't usually bother with `jj new -A`, since I'm going to squash my "out of line" temporary commit into the linear chain anyway. `jj new -A` is more similar to `jj edit` than `jj new` -- it shares some but not all of the modal disadvantages. So perhaps my answer to your actual question is: "yeah, I dunno either."
  - BeetleB 1y ago
    Indeed, that was my point. jj new -A would also trigger rebases.
    - sfink 1y ago
      Heh, sorry. The `-A` part went whooshing over my head until I had already written up the rest. I just saw `jj new` and got triggered into a "well akshually..."

BeetleB 1y ago

As a relatively new jj user, I'm curious. Why is the jj new -A + squash better than just a jj edit?

baq 1y ago
Separation of concerns and performance; when you edit, the commit in the middle of the branch is your working copy and you’ll update the whole branch unnecessarily many times vs just once when you’re on a logical checkpoint.
- adastra22 1y ago
  Not everyone works by “logical checkpoint” commit strategy. I myself want my tree clean and commits being atomic state transitions. Otherwise git bisect (which I rely on) would break. A lot of the jj strategies in this thread are a bit more cowboy, and I’m surprised.
  - steveklabnik 1y ago
    The key is to be cowboy until you’re happy with things, and then get clean, just like with git. It’s way easier to slice and dice commits with jj and so you can be sloppy at first and it’s easy to turn beautiful afterward.
    - adastra22 1y ago
      That’s not how I use git, at all. I have a messy workspace with a lot of things going on simultaneously, and only selectively stage when something crosses the finish line. Sounds very difficult to do this in jj.
      - steveklabnik 1y ago
        Selectively staging is easier in jj. I loved git’s index, jj does it better.
        adastra22 1y ago
        How? The jj documentation seems to be pretty clear about getting rid of the staging area.
        baq 1y ago
        staging isn't needed since everything including the working copy is a commit you can split, rebase, etc. without any checkin step. yes, it does make sense and yes, it works in practice - the uncommitted vs staged vs committed states are very git-specific and don't need to be special in any way. if you check in the wrong thing (note - your working copy is a commit, so by definition you can't not have wrong things checked in at times) you split it (stage and/or commit in git).
        Human-Cabbage 1y ago
        There are a couple main ways to achieve a workflow similar to Git's staging area. #1: Squashing Create a revision for the feature, then create another revision atop that. $ jj new main -m 'feature' $ jj new $ jj @ trtpzvno samfredrickson@gmail.com 2025-09-01 12:32:33 9ac76a0f │ (empty) (no description set) ○ wvzltyyr samfredrickson@gmail.com 2025-09-01 12:32:31 80b2d5d0 │ (empty) feature ◆ zxrulorx samfredrickson@gmail.com 2024-12-11 03:44:38 main 351a2b30 │ all the stuff $ vim $ jj @ trtpzvno samfredrickson@gmail.com 2025-09-01 12:34:50 5516c2b9 │ (no description set) ○ wvzltyyr samfredrickson@gmail.com 2025-09-01 12:32:31 80b2d5d0 │ (empty) feature ◆ zxrulorx samfredrickson@gmail.com 2024-12-11 03:44:38 main 351a2b30 │ all the stuff ~ $ jj squash -i # interactively choose hunks to squash into parent $ jj @ oxqnumku samfredrickson@gmail.com 2025-09-01 12:35:48 8694aa34 │ (empty) (no description set) ○ wvzltyyr samfredrickson@gmail.com 2025-09-01 12:35:48 47110bff │ feature ◆ zxrulorx samfredrickson@gmail.com 2024-12-11 03:44:38 main 351a2b30 │ all the stuff ~ #2: Splitting Create a revision for the feature, then split it up retroactively. $ jj new main -m 'feature' $ jj @ snomlyny samfredrickson@gmail.com 2025-09-01 12:38:39 84c6ecaa │ (empty) feature ◆ zxrulorx samfredrickson@gmail.com 2024-12-11 03:44:38 main 351a2b30 │ all the stuff ~ $ vim $ jj @ snomlyny samfredrickson@gmail.com 2025-09-01 12:39:51 8038bdd4 │ feature ◆ zxrulorx samfredrickson@gmail.com 2024-12-11 03:44:38 main 351a2b30 │ all the stuff ~ $ jj split # interactively choose hunks to keep, splitting the rest into a new revision $ jj @ zpnpvvzl samfredrickson@gmail.com 2025-09-01 12:41:47 5656f1c5 │ debugging junk ○ snomlyny samfredrickson@gmail.com 2025-09-01 12:41:44 1d17740b │ feature ◆ zxrulorx samfredrickson@gmail.com 2024-12-11 03:44:38 main 351a2b30 │ all the stuff ~
hdjrudni 1y ago
I forget where I read it (maybe from Martin), but one reason I like to `jj new` before I start any work is just because it makes it easy to revert or abandon if I don't end up liking it. And also easy to diff. `jj new` is pretty much 'free' anyway, every time you make an edit you're creating new commits (not changes!) anyway.
- BeetleB 1y ago
  Oh I'm good with jj new for any new thing I'm working on. But I was wondering why one would use jj new -A to fix a commit in the past vs jj edit,
  - kps 1y ago
    Mostly to keep the new changes isolated from the original commit until they're ready, I think. The only time I use `jj edit` is to resume a leaf I left in the middle of something (where I might have used `git stash pop` but without needing to stash).
sfink 1y ago
My personal opinion: `jj new` is better because it's non-modal. If you use `jj edit`, you're sort of switching to "edit mode": any change you make will trigger a rebase of all descendants.[1] You're live-mutating the core graph structure rather than a harmless appendage node. Also, if you notice something else that needs to be fixed, you can do it but then you'll need to remember to split it out into a separate commit before leaving edit mode. With `jj new` + `jj squash`[2], you're collecting work that you can review as a separate thing anytime as you go along. You don't have to remember anything. If you throw in an unrelated change, you'll notice it if you review the changes before squashing them, so you can split it out then. And I'm pretty much always working in this state even when I'm at the top of my branch, so `jj new some-deep-node` doesn't really change anything. If I get called away and have no memory of what I was doing when I return, it doesn't matter: my jj state tells me exactly where things are and what I was doing. [1] Which is not a huge problem, you have deferred conflict resolution so if something goes wrong you can probably just repair it with normal editing or your editor's undo functionality. [2] I don't usually bother with `jj new -A`, since I'm going to squash my "out of line" temporary commit into the linear chain anyway. `jj new -A` is more similar to `jj edit` than `jj new` -- it shares some but not all of the modal disadvantages. So perhaps my answer to your actual question is: "yeah, I dunno either."
- BeetleB 1y ago
  Indeed, that was my point. jj new -A would also trigger rebases.
  - sfink 1y ago
    Heh, sorry. The `-A` part went whooshing over my head until I had already written up the rest. I just saw `jj new` and got triggered into a "well akshually..."