FR: Some jj next/prev improvements

[PhilipMetzger]

Soon™, we'll have jj prev and jj next. Although the commands look eerily similar to git-branchless or sl next/prev, they do not understand dependant commits (stacks) and branches.

Notable missing features:

• Prompting the user for resolution on merge commits for both prev and next
• Moving onto a branch, like git-branchless does
• Some notion of a stack

[arxanas]

For reference, here is the Wiki page for the stack-related operation of git-branchless prev/next: https://github.com/arxanas/git-branchless/wiki/Command:-git-next,-git-prev#moving-to-the-top-or-bottom-of-the-stack. Switching to the bottom of a stack doesn't require understanding what a "stack" is (as it switches to a descendant head), but switching to the top of a stack does (as it switches to an ancestor root that is not an ancestor of the main branch).

I have sometimes wanted to move into the "next commit in <revset>". For example, I would want to move to the next commit that touched file foo, the next commit authored by me (or not me), or the next commit with a failing test. This could be done with revsets, strictly speaking, but so could jj prev/next in general. Maybe it's a common enough operation to consider adding to jj prev/next.

[arxanas]

For example, I would want to move to the next commit that touched file foo, the next commit authored by me (or not me), or the next commit with a failing test.

Or — particularly useful in jj — to switch to the next commit with a conflict.

[rslabbert]

I think supporting a config option for --edit as the default default would be useful and as far as I understand more closely matches the git-branchless/sapling behaviour. Selfishly it also more closely matches my workflow (having had next/prev aliased to `edit @+/@-'). Though maybe I should try and get used to the new + squash workflow instead.