You already can do a lot of those commands in the Outgoing or Journal view. What commands you are missing - please create a new topic for each missing command.
Unless I'm missing something, the limitation of the Outgoing view is that
it starts "rebasing" as soon as try to move commits around, in a true "interactive rebase" mode it needs to wait until I finished rearranging the commits
it cancels the operation if there are conflicts, while interactive rebasing should offer to fix the conflicts, as normal rebasing does
What if upon "Rebase HEAD to...", instead of simple confirmation, SmartGit would show the dialog with the commits to be applied, and the user could rearrange/exclude them (and potentially annotate as squashing/fixup). This kind of thing is really missing in SmartGit and I have to use command line interactive rebase.
Indeed it misses the ability to resolve "interactive" rebase conflicts. That's the major missing piece that requires me to use the command line to rebase.
Also, additionally to the "squash commits" command, there could be a "fixup into (previous commit)" command (most of my squashes are fixups).
I don't feel the need to schedule multiple changes simultaneously like in the git CLI. In a GUI, reorganizing commits as I move them around seems more appropriate.
From my point of view interactive rebase provides these features I miss in SmartGit GUI:
Ability to alter commits during rebase, not before, so if anything goes wrong, I still can go back to unchanged original branch easily.
In interactive mode I can quickly prepare changes (reorganize, ignore, squash..) to commits and then start it all at once. Sure I can reorganize commits one by one in Outgoing view, but that's slow (as I need to wait for rebase to finish before I can reorganize another commit and do it x times)
Also there is option to "squash"/"fixup" (they differ just by either appending the log message to the new commit, or ignoring the log message). I read squash should be possible in Outgoing view when I use same commit message for some commit and then move it to another - so that should upply the fixup, but it doesn't sound very comfortable.
Very interesting and useful command from interactive mode is "edit". It "pause" rebasing at the selected commit so user can make changes to it - edit files, edit commit message, I think also split this commit to more commits,...
As Alyst mentioned, in case of conflict, it should "pause" rebasing (as above with "edit") and let user fix the conflicts as usual. (Actually right now I don't remember how SmartGit behaves in case of conflict during rebase. Maybe it allows to fix the conflicts already?)
So basically how the whole interactive rebase works, and especially the ability to "edit" commit in history is probably most wanted feature for me :)
My reasons for 'Outgoing' window not being enough:
Anything with conflicts! That totally doesn't work in SmartGit, while being a very typical use case.
Sometimes, the commit to be affected is omitted in Outgoing.
Fixup requires the other commit to have exactly same name. I prefer to make future-fixup commits with @@@@ mark and a short note where it should be fixed up, cleaning up everything later. Doing fixup at once causes unwanted 5 min rebuild for my project and distracts me from what I'm currently doing in code. Having commit with same name will not catch my attention in Log as @@@@ does.
Squash (fixup + rename) requires two actions in Outgoing, which is twice as slow.
You can't Edit commit, which is essential if you want to split commit into multiple commits.
We plan to add Interactive Rebase for batch processing larger history rewrite actions, additionally to the existing Journal-operations, for version 17.1.
Haven't tried the 17.1 preview yet, but from the Interactive Rebase UI screenshot, it looks like it would not be possible to duplicate the same commit. One can do it in `git rebase --interactive`, and sometimes I do it to split a commit into several ones (and optionally rearrange with the others). Of course, most of the time it would require conflict resolution.
For splitting commits there is a different command and the latest build 11129 (Help | Check for Latest Build) implements the split using duplicate commits (according to your suggestion), stopping at the first to discard unwanted parts.
You already can do a lot of those commands in the Outgoing or Journal view. What commands you are missing - please create a new topic for each missing command.
Unless I'm missing something, the limitation of the Outgoing view is that
What if upon "Rebase HEAD to...", instead of simple confirmation, SmartGit would show the dialog with the commits to be applied, and the user could rearrange/exclude them (and potentially annotate as squashing/fixup). This kind of thing is really missing in SmartGit and I have to use command line interactive rebase.
Indeed it misses the ability to resolve "interactive" rebase conflicts. That's the major missing piece that requires me to use the command line to rebase.
Also, additionally to the "squash commits" command, there could be a "fixup into (previous commit)" command (most of my squashes are fixups).
I don't feel the need to schedule multiple changes simultaneously like in the git CLI. In a GUI, reorganizing commits as I move them around seems more appropriate.
Could you please explain the difference between "squash commits" and "fixup into (previous commit)"? Thanks in advance.
From my point of view interactive rebase provides these features I miss in SmartGit GUI:
For version 8.1 (preview will be available after version 8 has been released) you will at least be able to Commit during Rebase.
My reasons for 'Outgoing' window not being enough:
We plan to add Interactive Rebase for batch processing larger history rewrite actions, additionally to the existing Journal-operations, for version 17.1.
Haven't tried the 17.1 preview yet, but from the Interactive Rebase UI screenshot, it looks like it would not be possible to duplicate the same commit. One can do it in `git rebase --interactive`, and sometimes I do it to split a commit into several ones (and optionally rearrange with the others). Of course, most of the time it would require conflict resolution.
For splitting commits there is a different command and the latest build 11129 (Help | Check for Latest Build) implements the split using duplicate commits (according to your suggestion), stopping at the first to discard unwanted parts.