Well I don't know what makes things hard to implement.  I would think it just an extension of the blame functionality, but I don't know.

I gave a good suggestion on how to implement it.  Add a column to the main window (hidden by default if you want), that shows the date of the last commit for each existing file, so they can be sorted by date of last edit.

Issues described here: https://smartgit.userecho.com/topics/552-interactive-rebase-should-show-commit-information/#comment-1287

But the "Show More Commits" function in the Journal solves my problem!

This is fixed, right?  There's a ".." button in 17.1 that allows showing more commits!  Yay!

I don't think I can start Interactive Rebase from the Journal, since it only shows the last 11 commits in the current branch?

Ok, but I've never seen this before when rebasing normally or using the Journal.

> The interactive rebase is exactly made for the purpose of performing a couple of operations at once.

Yes, and I'm doing many operations at once, but I need to view the Log in-between each change.

Yes, I'm opening Interactive Rebase from the Log, which obscures the Log and doesn't allow me to view it anymore.

Is there another way to start Interactive Rebase that isn't a modal dialog that blocks the Log from being accessed?

When you're running interactive rebase and it fails, you end up in the index editor / conflict solver, and everything is red due to line ending changes.  You have to Hide Whitespace Changes to make any sense of it, but when you hide whitespace changes, the "Next Conflict" buttons stop working, so you have to manually look for the >>>>> sections.

In other words, there's no way to look at some commits, decide they should be squashed, squash them, look at some commits, decide they should be reordered, reorder them, look at a commit, decide it should be edited, edit it. 

Instead, you have to look at all the commits, make all the decisions about them, memorize those decisions, open the Interactive Rebase (which takes forever to open), make all the squash/reorder/edit changes (from memory) based only on the commit summaries, and then rebase.