Interactive Rebase should show commit information

Also it seems to not handle line endings the same as the Journal did?  On Windows my Index Editor is totally red from line ending differences until I Ignore Whitespace

What do you mean? How is the Index Editor related to the Interactive Rebase? Please note, that this is NO support forum here.

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.

This is no general interactive rebase problem but one with your particular repository - most likely you have committed line separator changes unintentionally. Again, userecho is NO support forum.

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

The reason is simple: the normal Journal just rejects the operation if there is a conflict.

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.

The interactive rebase is exactly made for the purpose of performing a couple of operations at once. Contrary to what you write, when squashing a commit there, you will already see the future single squashed commit. What exact information are you still missing here? Please note that we won't add a "log graph" to this dialog because commits will be only linear anyway.

> 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.

It is also possible to open the log before starting the interactive rebase.

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 starting the interactive rebase from the Journal, the log should remain operational.

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

Then I see only following options:

• duplicate all the information we show in the Log also to the modal interactive rebase dialog
• turn the interactive rebase dialog into some kind of temporary view and handle it with a mode of the project and log window where any command execution is prevented (because the interactive rebase command still is running)
• add a command to start the interactive rebase (which will fill a new temporary view with the selected commits similar to the Journal view), let you do the modifications in that view and then finally start the interactive rebase by feeding the information from the temporary view (or rejecting if the commits to be processed would have changed)

Honestly, neither of these options sounds right for me from the UX point of view.

Hi,

I would also like to be able to access commit log while editing interactive rebase strategy.

Maybe a solution would be to make it a simple window instead of a modal dialog. This way, while I'm editing my rebase strategy, I can change window and access commit log, view changes of each commit, which branch it comes from etc...

I use a lot interactive rebase, mainly to shape my commits so each one is a true complete changelog item for my final branch goal.

I usually will ensure tests pass, changes match the goal explained in the message, message is explaining what this commit adds for the branch goal etc...

As I'm not perfect, I build incomplete commits, and than fixup commits that will at the end make each commit complete.

This involve many fixup commits, and many interactive rebase where I have to check for each commit if content really matches the related commit, if it should be splited, ensure squash order etc...