[motorest]

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

[Skinney]

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