reorder commits using mouse drag

[thediveo]

Is your feature request related to a problem? Please describe.

Commits can be moved up and down using the keyboard, but not using the mouse. Also ctrl+j/k don't work in VSCode terminals and reconfiguring each and every devcontainer is a PITA.

Currently, clicking in the commits pane selects the appropriate commit, but dragging simply make the single selection move instead of dragging the commit.

Describe the solution you'd like

Click+drag to move a commit in the commits pane to its new location.

[stefanhaller]

I don't think this works, for two reasons:

• it's true that currently dragging simply moves the selected line, but I want to change this so that it creates a range selection; this is consistent with how it behaves in the staging view. For people who expect this to happen, moving commits would be confusing and annoying.
• it would have to indicate where the insertion position is, and in a GUI application this would be indicated by a thick black line between the rows where it would go; drawing such a line is not possible in a TUI app, and it would be hard to find an equivalent visualization that works well.

Also ctrl+j/k don't work in VSCode terminals

Huh? Works for me. Also, I prefer the recently added <alt+up>/<alt+down> bindings; these don't work out of the box in VS Code, but if you delete VS Code's terminalFocus bindings for these, they do.

[thediveo]

• ctrl-k is part of many multi-key bindings that also work in terminals; ctrk-k, v opens markdown preview, etc.
• underlining could be used to Mark the Inseln point, or a responsive design that gives a live preview.

[stefanhaller]

• ctrl-k is part of many multi-key bindings that also work in terminals; ctrk-k, v opens markdown preview, etc.

Ah, that's on Linux or Windows; true. It works for me on Mac because there it's Command-K. Still, the <alt+up>/<alt+down> should work once you unassign them in VS Code.

• underlining could be used to Mark the Inseln point, or a responsive design that gives a live preview.

True, or a design where a blank row indicates the destination, or maybe one showing only a <-- move commits here marker.

Moving commits with the mouse would actually be useful for the case that you want to move them a longer distance, because that's slow when doing it one by one, and you don't want to resolve conflicts at every step. The standard workaround for that is to enter an interactive rebase first and then continue it afterwards, but that's a bit cumbersome; dragging would solve that nicely.

Also, the range selection conflict could be solved by creating a range selection when dragging an unselected commit, but moving commits when dragging a selected one; maybe that's intuitive enough.

So thanks for the suggestion, I'll look into it when I find the time.

[stefanhaller]

@thediveo Here's a PR, please test: #5857.

It uses the logic I described above: dragging an unselected row creates a range selection, dragging a selected row moves it. I'm slightly undecided about this: for moving a selection of multiple commits it's fine, but when moving a single commit I sometimes find it annoying that I have to select it first. I don't have a good idea how to resolve this; range selection by dragging is now available in all lists, so it would we weird if it isn't in the commits panel, and always moves the clicked commit.

[thediveo]

@stefanhaller 👩‍🍳👌 works like a charm!