I think what comes up most often for me is when I want to fix something on a different branch than the one I'm at now, or when I want to fix something that feels like it should be separate commit.
In git you can `git stash`, commit the unrelated change and then run `git stash pop` to get your in-progress changes back.
In jj your work is already added to the current commit whenever you run a jj command, so you can simply switch to the other branch and do the work, and when you switch back your work is as you left it. It saves you the `git stash` commands. I also like that anonymous branches are completely normal in jj, so I don't need to create branches just to find my way back to a change.
Similarly, jj removes most usages of `git rebase --interactive` by allowing you to checkout a previous commit, and as you're making changes to it all descendant commits are being rebased automatically. This makes it easy to insert changes between two commits, simply create a new commit where you'd like it to go and then descendant commits will automatically be rebased on this new commit as you make changes.
To me this is more intuitive, and it removes `stash` and `rebase --interactive` as concepts.
> In git you can `git stash`, commit the unrelated change and then run `git stash pop` to get your in-progress changes back.
Not necessarily. You can just commit your changes, switch to whatever branch you want to work on, and then when you switch back to the old branch you can resume working as always.
This is not a Git thing. Even Mercurial advocated for this approach, and sold it as the only and true way of stashing changes. Mercurial only received support for a stash-like feature much later and in the form of an extension.
Also, even though git stash can be used in workflows that involve switching branches, it is suitable primarily for very short-lived tasks that prevent you from committing changes to a branch. Things like pulling changes from a remote branch or switching brsnched when you have random local changes in place (I.e., changed to config files for troubleshooting purposes)
> Not necessarily. You can just commit your changes...
Saves me from doing that extra commit, then.
> [...] it is suitable primarily for very short-lived tasks that prevent you from committing changes to a branch.
That's also a thing I like about jj. Nothing prevents me from committing changes. Even merge conflicts are commited, so I know I can always come back to it later.
I find I think less about when to commit my work in jj. In Git I find that I like to commit to avoid loosing work, in addition to commiting when I feel "done" with part of a change.
It's a small thing, really, but it feels quite big (for me).
I think what comes up most often for me is when I want to fix something on a different branch than the one I'm at now, or when I want to fix something that feels like it should be separate commit.
In git you can `git stash`, commit the unrelated change and then run `git stash pop` to get your in-progress changes back.
In jj your work is already added to the current commit whenever you run a jj command, so you can simply switch to the other branch and do the work, and when you switch back your work is as you left it. It saves you the `git stash` commands. I also like that anonymous branches are completely normal in jj, so I don't need to create branches just to find my way back to a change.
Similarly, jj removes most usages of `git rebase --interactive` by allowing you to checkout a previous commit, and as you're making changes to it all descendant commits are being rebased automatically. This makes it easy to insert changes between two commits, simply create a new commit where you'd like it to go and then descendant commits will automatically be rebased on this new commit as you make changes.
To me this is more intuitive, and it removes `stash` and `rebase --interactive` as concepts.