Improve usability of "interactive rebase"

[ZaLiTHkA]

my workflow often involves creating temporary branches to reorder commits before I push to remotes, and often I use interactive rebase to move some commits from one branch to another (much quicker than cherry picking them, especially when there are multiple to move).

however SourceGit has only ever allowed me to use an interactive rebase if the target is inline with my current branch, so I found myself continuously switching to another Git GUI for nothing more than just this step.

turns out this was quite easy to change, it actually took me longer to find the code that handles this than it did to change it... probably since this is the first time I've ever touched a C++ project (JetBrains Rider helped me big time here).

---

for reference, here are some screenshots of the change in action.

first the "Histories" panel, showing the context menu with the "Interactivly Rebase on Here" option:

then the "Interactive Rebase" window, scrolled to show the first commit to be moved:

the current.Head != commit.SHA condition was retained so that SourceGit doesn't allow anyone to try an interactive rebase to the current HEAD...

@love-linger, do you have any objection to including this change?

[love-linger]

Currently, Interactive Rebase collects the target commits via new Commands.QueryCommitsWithFullMessage(repoPath, $"{on.SHA}...HEAD").Result() which can not handle cherry-picked commits properly.

That's the reason why this feature is limited to the current branch.

[ZaLiTHkA]

is that something you might consider changing at some point? I often swithch between Windows, Linux and macOS for different projects, being able to use the same Git GUI client across all of them is super convenient. but since there no Linux version of Fork, this limitation in SourceGit means I end up needing to use three different clients overall.

---

(edit) ok, so I just reproduced the scenario where I would normally use interactive rebase in this way, and I think I see why this would be an issue..

with my change in SourceGit, the commits that already exist in the target branch are also listed in the "rebase" window's commit list. when I do the same thing in Fork, these commits are not listed there.

[love-linger]

(edit) ok, so I just reproduced the scenario where I would normally use interactive rebase in this way, and I think I see why this would be an issue..

with my change in SourceGit, the commits that already exist in the target branch are also listed in the "rebase" window's commit list. when I do the same thing in Fork, these commits are not listed there.

Yes. Fork runs the git rebase -i command directly when opening Interactive Rebase. I don't want to do that. but I've found the way to resolve this problem. And compared with Fork, its performance has been consistent with Fork in my various tests.

[love-linger]

You can test the latest CI build from Github Action.

[ZaLiTHkA]

You can test the latest CI build from Github Action.

looks good to me, thank you! checked a few different scenarios, and it does seem to be filtering the list of commits correctly.

I also realise now that the screenshots I shared above actually did show the problem you highlighted, I just didn't notice it at first.. apologies for that.

[love-linger]

Very strange. In your screenshot, I can see the columns did not aligned perfectly. This is how it looks like on my Mac:

And I can not reproduce this issue on both Windows and macOS.

[ZaLiTHkA]

Very strange. In your screenshot, I can see the columns did not aligned perfectly.

And I can not reproduce this issue on both Windows and macOS.

strange indeed.. I haven't been using SourceGit for interactive rebases, so I'm not sure when this started happening.. I assumed it was from some change that was still "in progress", since I started on the develop branch.

it does still happen in the artifact I downloaded from GitHub Actions just now.

should I log a new issue with a screenshot for reference so we can dig into it a bit more?