[3523582908]

I use Jiujitsu, and my personal experience is that the basic "write code, git add what specifically I want to history" flow is the same. The working commit is the effective staging area and it doesn't get forever committed to public history. Without going too much in detail, the working commit can't be pushed to your remote, similar to how the staging area can't be pushed.

[smazga]

Could you explain that just a bit more? I'm trying to figure out how to adapt my personal workflow to jujutsu and this is the part that confuses me.

I think it's me not understanding the difference between "jj new" and "jj commit", but I'm not sure.

I'm a big fan of the staging area for crafting clean commits, so this would be super useful for me to understand.

[stouset]

Your currently active commit is the staging area, only now that it's a "real" commit instead of some bastard half-commit all of your regular tools work with it directly. Same goes with the stash, it's rendered completely irrelevant.

When you're ready to "commit", you give a description to your current set of changes (`jj describe -m`) and then split out any of the pieces you don't want into the next commit (`jj split`). You get to pick the parts you want pulled out, and those get pulled out onto a new, fresh commit.

[3523582908]

There's a notion of "empty commits" (commits without messages) in JJ. These are basically the "staging area" of git, and if you try to `jj git push` it JJ will reject. So these commits cannot make it to the remote branch.

To be honest, JJ makes it way easier for me to craft clean commits. The design philosophy of JJ is commit-oriented, not branch-oriented. Since it's a frontend to git, everything it does is fundamentally git. But it allows commit-oriented workflows to flow so much easier than git does.

[riwsky]

“jj commit” = “jj describe; jj new”. Basically, jj doesn’t force you to wait until you’re “done” with some work to write the VCS message for it.