sublime_merge icon indicating copy to clipboard operation
sublime_merge copied to clipboard

Drag & Drop support for cherry pick/reordering/squash

Open OlivierLDff opened this issue 4 years ago • 3 comments

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!

OlivierLDff avatar Jul 01 '21 08:07 OlivierLDff

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.

rokups avatar Jul 13 '21 05:07 rokups

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

ohcibi avatar Jul 23 '21 10:07 ohcibi

Currently to reorder commits i use "Edit Commit" menu which has an option to move a commit up or down

That's very tedious indeed, meanwhile you could assign a shortcut to this action, for example

{"keys":["ctrl+m"]	,"command":"move_commit","args":{"commit":"$commit","down":true ,}	,"context":[
  {"key":"control"	,"operator":"not_equal","operand":"text_control"},
  {"key":"control"  ,"operand":"commit_table"},]},
{"keys":["ctrl+,"] 	,"command":"move_commit","args":{"commit":"$commit","down":false,}	,"context":[
  {"key":"control"	,"operator":"not_equal","operand":"text_control"},
  {"key":"control"  ,"operand":"commit_table"},]},

eugenesvk avatar May 24 '24 08:05 eugenesvk

Anorher vote for this. I think it would made SM almost feature-complete. Specifically behavior like:

  • one commit, or a number of adjacent commits, can be the source of the drag
  • commits can be dragged across branches
  • while dragging render a drag target line between commits, dropping there moves commits (or copies them, if commits came from another branch - could use modifier keys to allow moving as well but that seems a bit much)
  • dragging on a commit squashes the commits, or with e.g. Shift held down does fixup instead

stinos avatar Mar 09 '25 08:03 stinos