> The irony of that is that resolving conflicts in a complicated multi-commit rebase is much more easily/efficiently done in a good GUI than on the command line.
This is an argument for a good GUI diff/merge tool, which is not necessarily the same thing as an argument for a GUI Git client; I think the two uses are being conflated a lot throughout this comment thread. I have Kaleidoscope set as my default mergetool and difftool, but I'm still working with the git CLI nearly all the time. (I use Gitup on the occasions I want to stage changes to individual sets of lines in the same file as multiple commits, and exceedingly rarely if I'm trying to do something frightening with a local as-yet-unshared feature branch. There are times being able to undo with Cmd-Z is really helpful.)
You're right that there are two different parts to a these, but I think they both benefit from graphical tools.
I'm talking about a VCS tool telling me that the rebase had got to commit n of m and a conflict has been encountered, and which files have conflicts resolved (either automatically or I've manually resolved then so far in this tool), and which other files have conflicts outstanding. Then I can invoke the three way merge tool from there (which is indeed hugely better than a command line tool). Something like this (except this is for Hg):
This is an argument for a good GUI diff/merge tool, which is not necessarily the same thing as an argument for a GUI Git client; I think the two uses are being conflated a lot throughout this comment thread. I have Kaleidoscope set as my default mergetool and difftool, but I'm still working with the git CLI nearly all the time. (I use Gitup on the occasions I want to stage changes to individual sets of lines in the same file as multiple commits, and exceedingly rarely if I'm trying to do something frightening with a local as-yet-unshared feature branch. There are times being able to undo with Cmd-Z is really helpful.)