[adastra22]

How? The jj documentation seems to be pretty clear about getting rid of the staging area.

[Human-Cabbage]

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 [e-mail] 2025-09-01 12:32:33 9ac76a0f
  │  (empty) (no description set)
  ○  wvzltyyr [e-mail] 2025-09-01 12:32:31 80b2d5d0
  │  (empty) feature
  ◆  zxrulorx [e-mail] 2024-12-11 03:44:38 main 351a2b30
  │  all the stuff
  $ vim
  $ jj
  @  trtpzvno [e-mail] 2025-09-01 12:34:50 5516c2b9
  │  (no description set)
  ○  wvzltyyr [e-mail] 2025-09-01 12:32:31 80b2d5d0
  │  (empty) feature
  ◆  zxrulorx [e-mail] 2024-12-11 03:44:38 main 351a2b30
  │  all the stuff
  ~
  $ jj squash -i
  # interactively choose hunks to squash into parent
  $ jj
  @  oxqnumku [e-mail] 2025-09-01 12:35:48 8694aa34
  │  (empty) (no description set)
  ○  wvzltyyr [e-mail] 2025-09-01 12:35:48 47110bff
  │  feature
  ◆  zxrulorx [e-mail] 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 [e-mail] 2025-09-01 12:38:39 84c6ecaa
  │  (empty) feature
  ◆  zxrulorx [e-mail] 2024-12-11 03:44:38 main 351a2b30
  │  all the stuff
  ~
  $ vim
  $ jj
  @  snomlyny [e-mail] 2025-09-01 12:39:51 8038bdd4
  │  feature
  ◆  zxrulorx [e-mail] 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 [e-mail] 2025-09-01 12:41:47 5656f1c5
  │  debugging junk
  ○  snomlyny [e-mail] 2025-09-01 12:41:44 1d17740b
  │  feature
  ◆  zxrulorx [e-mail] 2024-12-11 03:44:38 main 351a2b30
  │  all the stuff
  ~

[steveklabnik]

Because it’s not a distinct feature, it’s just another commit. Which means you can bring all of the usual tools for modifying commits to bear. My sibling has some details, but at the high level, that’s the idea.

[baq]

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