jj-vcs
FR: Abolish `jj next/prev`, split its functionalities into `jj edit --next/prev` and `jj rebase --next/prev`.
Is your feature request related to a problem? Please describe.
Commands for changing the working copy revision shan't be lumped together with commands that edit the change graph. It is confusing and against jj's philosophy. And there is already another command for updating working copy revision - jj edit.
Describe the solution you'd like
Deprecate next/prev --edit, and add --next/prev to jj edit.
Describe alternatives you've considered
Although to me they are in different categories of operations (i.e. one is a read-only operation that does not change the change graph, it only changes the current view; whereas the other modifies the change graph), other people could indeed be conceptually grouping the behavior of jj next and jj next --edit together. In that case nothing should be changed.
I'm interested to see whether people agree/disagree.
Since jj next/prev is basically a short for jj new/edit NEXT/PREV_REV, I think the user can define next()/prev() revset aliases and use them as jj edit 'next()'. I don't feel strongly whether jj next/prev --edit should be removed, but I don't think jj edit --next/prev is needed.
that feels like more reasons to remove jj next/prev --edit.
Edit: the thing is, jj next --edit lets you choose which child you want to move to in case there are multiple. can user defined revsets do the same?
Edit: the thing is,
jj next --editlets you choose which child you want to move to in case there are multiple. can user defined revsets do the same?
No this isn't possible today and I think some people really like it.
In the past we talked about refiling https://github.com/jj-vcs/jj/pull/3689 as a custom revset function, e.g prompt(revs=[revs]) in the Discord.
I have another point against jj next/prev. Unlike all other commands that make modifications to the repository (e.g. new, desc, abandon, edit, undo, ...), "next" and "prev" aren't verbs. At first glance it's unclear what operation jj next/prev performs, only the direction of that operation. A better option would be like jj graft --to-prev/--to-next or something.
Oh wait, don't we already have a command for "grafting"?