Select a range of revisions

[arnold-c]

Is there a way to select a range of revisions when in the default view? I appreciate it's possible to select revisions one-by-one with space, but it would be useful to be able to use a keybind like shift-v to select the start and then just navigate up and down the log/file list (if in the details view) to quickly select a range. This would be nice to abandon a selection of changes quickly when iterating on an idea, for example.

Really enjoying learning jj, and jjui is going a long way towards making this a smooth process, so thanks for the TUI!

[vic]

hey, having shift+v to select multiple revisions is an interesting idea and might be a familiar movement from some editors.

afaik, there's currently no way to select multiple revisions visually like shift+v would do as you move.

while I like the idea of shift+v to select multiple revisions, I'm wondering how it would work visually, when active and when you move (say pressing up key) the revisions you get over will be marked right ?

I can imagine a problem with this, imagine if I activate shift+v and move upwards, it might happen and is quite possible that the commit graph is non linear, and moving up would select a revision on another branch. this is unlike using shift+v on editors where lines being selected are always continuous and makes sense to work on continuous ranges of text.

however, I can imagine other alternatives:

the one with less changes (and the one possible right now) is just to use : jj exec. given that the graph is visible, you can easily use : abandon x:: to abandon x and all it's descendants. this is what I'd currently do, previous to using jjui I had to use jj log and memorize the change_ids to use on a revset. but now that we can invoke any jj command directly from jjui and having the graph always visible has made it easier for me to run jj commands over revsets without me forgetting ids.

so the first option is to just use : abandon x. where x is the revset you define, it can be a continuous range or just some revisions (a|b|c).

another option would be to use our current L key to change the revset, and then when you have the graph containing the revisions you want, we could have a "select all" key binding. that would toggle selection on all revisions being shown.

then if you needed to abandon them all you could do that directly.

or if you needed to squash them all into say the last one, you just deselect the last one and use squash as you'd normally use.

probably there are other options but this what comes to my mind now.

[vic]

Additional note for me: There's currently a $revset placeholder for : jj exec commands that gets replaced with the current revset. so : abandon $revset is also possible once you have set the revset and confirmed those are the revisions you want to forget.

[arnold-c]

while I like the idea of shift+v to select multiple revisions, I'm wondering how it would work visually, when active and when you move (say pressing up key) the revisions you get over will be marked right ?

Yes, I was thinking that it would work similar to shift-v in vim. JJUI has some vim-like navigation keymaps, so it feels like a natural extension for selecting revisions, though I appreciate that the underlying mechanics are likely quite complicated to implement. To maybe address your comment about non-linear graphs, I guess there could be two modes that can be flipped between with a Tab key once in the selection mode? One that just selects on the branch that is currently being edited (this assumes @ is above a branching point) - effectively x::y where x is the starting revision and y is the ending revision. The other mode could select across all visible heads, switching to something like x::visible_heads() & ~y+:: once above the branching revision. See the screenshots below for what the revset may look like.

The full log

A revset filtered across branches

the one with less changes (and the one possible right now) is just to use : jj exec. given that the graph is visible, you can easily use : abandon x:: to abandon x and all it's descendants.

I definitely think that this is probably the simplest solution out of the three as for a new user to JJ and JJUI learning all the intricacies of how to filter the revset you want is harder than just visually selecting items that appear on the log. While revsets would be a nice way to do this, the Revset language page of the documentation is a little too far down and nested, and when combined with it being incredibly dense, the discoverability might be an issue with this approach (maybe this would be a good documentation video for JJUI to walk through how they can be used simply for a very powerful usecase)? Steve's tutorial is certainly clearer, but requires a bit of work to find that section as it exists under merging and conflicts.

[idursun]

Thanks for the suggestion @arnold-c,

Would it help if the selection with space moved down automatically? This is already the default behaviour with the details view; when you select a file, it moves to the next one. It's handy especially if you have the preview pane open, so you quickly skim and select the file and perform an operation on the selected ones.

I see that this would work with revisions too. If the user is selecting a revision, it's very likely that they want to include another, as otherwise they would just do it on the highlighted revision.

I think this would mostly cover your use case and fit nicely with the rest of the app.

As for the shift+v suggestion, it could also work, but it requires a different representation to indicate that selection mode is active. (Vim's visual mode is doing that by selecting the lines as the cursor moves.) Then the following action needs to be performed on the selected revisions while the mode is active. Currently, jjui's modes have their own dedicated actions, which are limited to that mode. The visual mode would be an exception to this to allow any action while a mode is active, which is not possible with the current implementation. It's totally doable, but I would like to explore alternatives first, especially if there's a cheaper and less complicated solution.