jj
jj copied to clipboard
jj-vcs
FR: Some `jj next/prev` improvements
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
prevandnext - Moving onto a branch, like
git-branchlessdoes - Some notion of a
stack
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.
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.
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.
I'm going to close this, as it was the canonical issue for merge commit handling for prev/next and prev/next --conflict, if you disagree we can always reopen it.