Drag & Drop support for cherry pick/reordering/squash

[OlivierLDff]

Problem description

Drag & Drop support for cherry pick/reordering/squash. Like Github desktop support:

• https://docs.github.com/en/desktop/contributing-and-collaborating-using-github-desktop/managing-commits/cherry-picking-a-commit
• https://docs.github.com/en/desktop/contributing-and-collaborating-using-github-desktop/managing-commits/reordering-commits
• https://docs.github.com/en/desktop/contributing-and-collaborating-using-github-desktop/managing-commits/squashing-commits

This really is a killer feature, right now to do so i'm using interactive rebase.
And i think about opening github desktop just to do those operation in the future.

Preferred solution

Drag & Drop support for cherry pick/reordering/squash.

Thanks, have a good day!

[rokups]

I second this request. Currently to reorder commits i use "Edit Commit" menu which has an option to move a commit up or down. Needing to move a commit down by 10 commits gets tedious fast.

[ohcibi]

I'd also like to see this feature. Moving commits is really tedious with merge. It would help a lot if moving was supported for a selection of commits because then we could move the ten commits above/below the one commit that should get as a fast workaround. Cherry-pick was made multiselect-able. Drop commits was always mutliselect-able, so why not rebase? The implementation for moving one commit should be the exact same as for several commits because the simple interface of rebase -i

ux wise 'move', 'squash', 'edit' and 'drop' should be available only within a special interactive rebase interface/mode otherwise its doing the same mistake as most git guis which is hiding the git interface and the - in this case pretty severe - implications of how git works. Why not just use the commit message editor for the rebase -i editor. The biggest problem with command line interactive rebase is that many people have no clue about vim