And what are the steps when you work on 3 things at the same time (you are working on PR #2 + fixing issues in PR#1 + a hotfix needs to be deployed for an issue)? Or when you need to continue fixing things on the PR?
On the absolute happy path what you do above is the same I do, where jj shines is when you het out of the happy path.
Isn't git-worktree designed for this kind of situation, where you could open each PR or branch in its own directory and switch your editor / other tooling between workspaces without losing state between them?
yeah, you could do this, but it gets kind of annoying in my experience. However it is another solution, most of what you do in jj you can do in git, its just more convenient
that's fine, what Im saying is that the above workflow is idealized and you have to do a lot more things overtime. If you look at the happy path it looks similar. With the unhappy path instead of keeping stashes and commiting trash then amending. You describe your change beforehand, and any change you do goes there. Thats it.
Hotfix? jj new main
go back to what you were working on? jj edit refA
need to solve some problems in another pr of youre? jj edit refB.
Theres no overhead at all in thinking these, you can never lose work by mistake, you can never mess it up. It just works
Personally I usually stash if it's partial work I'm going to return to soon. But you can create a commit if you want. Just name it 'WIP' or 'temp' or something. When you come back and finish it you can write the proper commit message.
And then you have to remember which branch the each entry of the stash was on, deal with unstashing conflicts, remember to drop the latest stash after fixing those, etc.
Tools like the stash are band aids that come with their own set of “fun” failure modes.
So when I say there a problems with stashing, you suggest wip commits. When I point out problems with wip commits, we go back to stashing?
jj needs neither because everything in your working copy is already part of a commit. You can’t accidentally push unfinished changes because jj will complain if it hasn’t been described (given a commit message). If you need to move changes between commits you don’t need to stash because you can easily move the contents of a commit around.
Stashing vs WIP commits have pros and cons. I've never hit any of these problems you're pointing out, so I don't have any particular strong opinion about which one you should use.
I can see that being nice I guess.
If jj's stashes are just regular commits, don't you have the problem where you accidentally push a stash just like you push a WIP commit?
> don't you have the problem where you accidentally push a stash just like you push a WIP commit?
Because jj doesn’t require commits to be on a branch, and the equivalent feature (bookmarks) don’t automatically advance, if you created a new commit to stash some stuff, the name wouldn’t move to it, and so when you push nothing would happen.
I don't think so. Like the OP, my everyday git usage is pretty straightforward. So "maybe this thing you do every once in a while could be a little nicer" doesn't feel very compelling.
Now let’s talk rebase/merge conflicts, stash conflicts, forgetting to un-wip, and on and on and on and then maybe acknowledge that all of these “but my git workflow is simple” comments are a convenient fiction that doesn’t actually exist in practice.
that's what I used to do, now I just use jj and I dont need to either keep a set of stashes nor create superfluous commits based on when I decided to change branches
On the absolute happy path what you do above is the same I do, where jj shines is when you het out of the happy path.