I've been using jj for a month, coming from mercurial. I have settled into a usage pattern slightly different than the article describes, so that all of those `jj edit` commands made me a little itchy. I prefer to nearly always use a separate @ commit to hold any changes I make. The mental model is that there's a graph of commits, and then @ is an auto-updated commit to hold any changes I make in an editor or whatever. Actually modifying anything in the core graph is then a conscious decision, and I might decide to update a commit with my changes (`jj squash` or `jj squash --into X`) or make the changes into a commit of their own (`jj describe` if I haven't already, followed by `jj new` to return to the stable state of having an @ commit for collecting changes).
The reason why I don't like using `jj edit` on something in the graph is that every change I make is conceptually applied immediately to all descendants. It's sort of like plucking a commit out of the graph (the commit you're editing), entering a mode where you can only modify that commit and don't have the option to use the changes in a different way (as in, squash some of them to some other commit or make a new branch or whatever).
It makes jj modal, and one of the things I most appreciate about jj is that it is not modal, you don't have a separate staging area or stash or anything, it's always in the same consistent state where you can do the same set of things.
Also, having a separate commit makes it easy to see how you've modified things, rather than only being able to see the sum total of the original commit contents plus your recent modifications. (It does make it a little harder to see that sum: `jj diff --from @--`.)
This is also the default behavior of `jj next` and `jj prev`, which are very confusing if you're expecting to be editing nodes in the graph directly. You can totally do that, by passing `--edit` to them, and if that's your preference you can default the flag in the config.
I do still use `jj edit` from time to time, but for the most part `jj new` gives me a better feeling of control. It was difficult initially to not want the "extra empty change" to go away, but once I accepted that there's really only one and it corresponds to a meaningful concept (it's the auto-updated container for any changes you make), I made peace with it.
> It makes jj modal, and one of the things I most appreciate about jj is that it is not modal, you don't have a separate staging area or stash or anything, it's always in the same consistent state where you can do the same set of things.
Staging and stash are modal--YES! I'm going to steal this.
I've been trying (and failing) to explain what I hate about staging and stash for years and this explains the issue so succinctly.
Sorry, I knew I remembered reading about the two somewhere but could not figure out where. I searched through the jj page for it. Only later did I remember that it came from your jj guide, which I still had open in a tab. I wish I had pointed to your explanation, it's much more clear.
I think I agree for the most part in practice. The vast majority of changes I make are on the nondescript (or actually description-containing) @ changes / "branch" tips, and then either become described changes, or get squashed / split / rebased / etc. into the right place.
The reason why I don't like using `jj edit` on something in the graph is that every change I make is conceptually applied immediately to all descendants. It's sort of like plucking a commit out of the graph (the commit you're editing), entering a mode where you can only modify that commit and don't have the option to use the changes in a different way (as in, squash some of them to some other commit or make a new branch or whatever).
It makes jj modal, and one of the things I most appreciate about jj is that it is not modal, you don't have a separate staging area or stash or anything, it's always in the same consistent state where you can do the same set of things.
Also, having a separate commit makes it easy to see how you've modified things, rather than only being able to see the sum total of the original commit contents plus your recent modifications. (It does make it a little harder to see that sum: `jj diff --from @--`.)
This is also the default behavior of `jj next` and `jj prev`, which are very confusing if you're expecting to be editing nodes in the graph directly. You can totally do that, by passing `--edit` to them, and if that's your preference you can default the flag in the config.
I do still use `jj edit` from time to time, but for the most part `jj new` gives me a better feeling of control. It was difficult initially to not want the "extra empty change" to go away, but once I accepted that there's really only one and it corresponds to a meaningful concept (it's the auto-updated container for any changes you make), I made peace with it.