FR: jj revert should have defaults

[turion]

I think it's a typical use case to use jj revert in at least one of these situations:

• I want to revert the latest change
• I want to put the reverted change on top of the latest one

It seems this could be achieved by letting jj revert default to jj revert -d @ -r @. This would be in line with many other commands having @ as default (describe, split, ...).

I'd be willing to give it a shot to implement.

[bnjmnt4n]

I don't think it's that straightforward to just default to jj revert -d @ -r @. This is because there are different workflows that people use.

If users want to revert the commit that they are working on:

• For the "squash" workflow, there would typically be an empty commit on top of that commit. The desired command is probably something like jj revert -r @- --before @ to insert the new revert commit before @.
• For the "edit" workflow, jj revert -d @ -r @ works fine. These users will then have to jj edit <revert_commit> to make it the working copy commit.

If users want to revert an arbitrary commit which they might not be editing or working on (e.g. reverting a change in another branch), the desired command is probably jj revert -r <commit> -d <commit>.

So, setting the default to -r @ -d @ would be intuitive only for some users (those with the "edit" workflow), and only if they want to revert commits that they are currently editing.

Note that jj backout, the predecessor to jj revert, does have the defaults that you mention. However, as mentioned, these defaults weren't regarded for those with the "squash" workflow: #2802.

[joyously]

Opinion: it shouldn't matter what workflow is being used, in order to have a default. Since other commands have the @ default, it makes sense to have it consistently across commands.
However, I often wonder what @ really is since I can interleave jj commands with git commands and with other commands that change files. This is probably a concept misunderstanding I have, but if so, then it's not explained clearly enough in the docs. I've read that jj does the snapshot at the beginning, and I assume that is @, but then what about the git import? (Or I guess the import is for internals, and that doesn't change the file tree.)

But creating a new @ and using that as the default seems counterintuitive for revert.

[martinvonz]

• I want to revert the latest change

This is very atypical in the way I work. Why would you want to do that instead of doing jj abandon or jj restore to get back to state from the parent commit?

(Jujutsu tries to make it easy to create clean commits. Creating a commit and then reverting it right after seems to go against that.)

[turion]

This is very atypical in the way I work. Why would you want to do that instead of doing jj abandon or jj restore to get back to state from the parent commit?

In my case I had pushed a commit to Github that I wish I had split up. To document the intended split, I reverted part of that pushed commit, and then reverted the revert again, and pushed these two.