[Feature Request] Interactive Rebase allow Copy/Paste of commits

[joevt]

I have 400 commits. I want to use the latest 100 of them to fixup many of the earlier 300 commits.

The current UI requires that I drag commits to the commits that I want to fixup. Dragging the commits takes a long time.

There is currently no method for finding the destination commit. Reading every commit to find the destination commit takes a long time.

Therefore, it would be easier to do this work in a text editor. Something like this:

In the Interactive Rebase window:

1. Select All, and Copy.
2. Then in a text editor, Paste. The paste may include instructions on how to edit the text.
3. Edit the commits in the text: rearrange commits, set some to fixup, or edit, or whatever.
4. Copy all the text.
5. Lastly, in the Interactive Rebase window, Paste. This will replace all the selected commits in the Interactive Rebase window. Fork.app will verify the text is in the correct format, all the commits exist, no commit is missing (or set missing commits to Drop), and no commit is duplicated.

Usually the destination commit for a fixup commit is the one that has the original blame for a changed line in the fixup commit. It might be helpful to highlight those commits if they are included in the rebase list of commits.

[DanPristupov]

The current UI requires that I drag commits to the commits that I want to fixup. Dragging the commits takes a long time.

Use Cmd+Up/Down

Regarding your request, what you described, is exactly how git rebase -i <SHA> works in the command line. Try to use it.

[joevt]

That mostly works. It takes a small amount of effort to properly construct the git command line. Not as easy as using the Fork.app UI.
git rebase -i ce245f88859025fd74137fa089479c8961fb2306 --onto 38c4f1e4c

I wasn't sure I would be able to use the Fork.app UI with git rebase -i. There's some output to stdout until the first conflict - kind of messy. Then I can use the Fork.app UI to continue the interactive rebase.

If I had some commits marked with edit, would it use the terminal UI or Fork UI to do the edit? Actually, I think it would just stop like a conflict does and I can use the Fork.app UI to edit and continue.

What about reword? What does Fork.app do when it comes to a reword commit? My idea was that Fork.app could use a text format that would allow embedding commit subject and description for a reword commit.

Another thing: The Fork.app UI has commits listed from latest to earliest but git rebase -i has them listed from earliest to latest.