Is it that awful? Each option is nicely explained, and the documentation is exactly where you need it, when you need it. I personally found it extremely helpful during my first interactive rebase, and still give it a glance from time to time when I forget the difference between squash and fixup.

Provided rewording, reordering and squashing (or fixing up, same thing really) are all you need I think you could argue this is true. Trying to do anything else tends to be a bit of a pain.

On another note, is it possible not to lose the commit description when trying to split a commit? I'm talking about 1) marking commit as `e` to edit it 2) git reset HEAD~ to move back 3) split the change however you want 4) commit again whenever I do it I always lose the original commit message. I'm not sure if it's me being stupid or if there is just no simple way to do it.

> is it possible not to lose the commit description when trying to split a commit?

There's 2 cases: 1) extract changes into a commit that comes before the original commit, and 2) extract changes into a commit that comes after the original commit.

In both, instead of editing the commit you want to split, `break` before that commit, and then use `git checkout <hash_of_commit_to_edit> <path_to_files_of_interest>` to pull the changes of interest out into an new, earlier commit. `git checkout -p` is worth a look here. Alternatively if the changes are simple enough, you could use exec instead of break before the target commit.

For 1) you can commit those extracted changes with a new message and then `git rebase --continue`. The original commit will then lack the extracted changes, and have the original commit message. If you did want to adjust it, reword that commit.

e.g.

    pick c62dfe67 1
    pick 63dcd748 2
    exec git checkout eea68bb8 three.txt && git commit -m "3"
    reword eea68bb8 3+4

For 2) reference the target commit's message as the new, earlier commit's message. Keep in mind that the git invocation in this exec here still supports git aliases so if this was something you do often, you could create an alias for retrieving the next commit message and that last part of the exec could just be `.. && git getnextcommitmessage`

e.g.

    pick c62dfe67 1
    pick 63dcd748 2
    exec git checkout eea68bb8 four.txt && git commit -m "$(git log -1 eea68bb8 --format="%B")"
    reword eea68bb8 3+4

"edit" is useful for splitting a single commit into multiple. You couldn't do it with operations you just mentioned.

My only gripe is after 15 or so years with git I still sometimes forget the direction of the time arrow in the interactive rebase.

Me too. I have a branch with some commits on top of git-revise where I implemented this config option:

~/.gitconfig

    [sequence]
        presentation-order-head-on-top = true

Branch: https://github.com/anordal/git-revise/commits/rebasehappy-in...

I like that and use it a lot. It's very easy to rearrange stuff.