> My concern isn't just about pushing upstream. What I'm saying is that the typical change to a file shouldn't be committed to my local repo until I indicate that it's ready.
jj doesn't have the concept of a non-committed file.
instead you don't track the HEAD as the tip of the branch (@ in jj), you track HEAD^ (jj: @-) or something earlier and since jj rebase isn't dumb as a rock you can relatively easily keep the working set of changes (as in, multiple commits/WIP branches; not necessarily the index or the working copy) on top of what you are pushing and squash or advance the branch (bookmark).
I'm reiterating because it's a very important and super confusing for advanced git users: there is no uncommitted state in jj and yes, it does make sense, but you need to stop thinking in git.
jj doesn't have the concept of a non-committed file.
instead you don't track the HEAD as the tip of the branch (@ in jj), you track HEAD^ (jj: @-) or something earlier and since jj rebase isn't dumb as a rock you can relatively easily keep the working set of changes (as in, multiple commits/WIP branches; not necessarily the index or the working copy) on top of what you are pushing and squash or advance the branch (bookmark).
I'm reiterating because it's a very important and super confusing for advanced git users: there is no uncommitted state in jj and yes, it does make sense, but you need to stop thinking in git.