Q:

git rebase --continue, but modify commit message to document changes during conflict resolution?

Here is the scenario: 

I am rebasing a branch in git, I had conflicts and just resolved them (did git add and everything).
Normally, I would just run git rebase --continue to proceed with the rebase
I want to edit the commit message of this commit, to explain the changes I made when resolving the conflict

I don't usually do this, but this particular conflict required some serious recoding, which I feel needs to be documented.
How do I do this?  I'm hoping there is a git rebase --continue --let-me-edit-the-message-first command of some sort, but I have not been able to find it in the documentation
I know that:

I could run git commit, manually copying the existing commit message and then modifying it.  I don't want to do this.  git rebase must have the commit message stored somewhere, because when it commits it will put the original message in.  I just want to insert my edits in between.
I could just run git rebase --continue, and then use git rebase -i to go back and edit the commit messages in question later on.  This requires me to remember what I changed in which commits throughout the entire (potentially long) rebase process.  Yuck.

I'm a little surprised that I couldn't find an answer to this already... I'm hooping there's a way to do this.  If there is an answer for this I had difficulty finding it.  I found things like confusion that amounts to the need for git add or git rm after resolving changes (like this), general git rebase wisdom (like this and this), and lots of questions that seem very specific to a particular case (like this).
Since I'm so surprised I couldn't find this answer, I have a secondary question: is there a fundamentally better way to document changes made during rebase?

A:

After coming to this question with the exact same problem and being disappointed with the answer, I think I came up with a reasonably elegant solution for this, but see my note at the end.
git commit -t .git/rebase-apply/msg-clean
git rebase --skip

msg-clean appears to contain the original commit message, so doing a commit using it as a template gives you the original message in an editor.
After your commit, the skip moves the rebase along without trying to re-apply the commit you just made.
NOTE: I'm no guru, so someone please verify this. It seemed to work with a test repo I slapped together, but I wasn't brave enough to try it on my real work repo with many hours of conflict resolution work. Please don't hold me responsible if this blows something up.

A:

I never realized that this is an issue. (My Git Bash at work is a different version, so maybe it works differently.) 
Either way, until you find a solution to that problem you can do the following:
git reset --hard HEAD
git cherry-pick $(head -1 .git/rebase-apply/patch)

Resolve conflicts
git commit
git rebase --skip

You can make aliases as well:
git config alias.rebase2cherry "! git reset --hard HEAD; git cherry-pick $(head -1 .git/rebase-apply/patch)"
git config alias.commitskip "! git commit; git rebase --skip"

Interactive rebase does bring up an edit message screen when you have conflicts even if you chose pick for that commit. However, it does not use the same format as the cherry pick with the conflicting files included by default. (It is not even included in the commented out section.)
For interactive a different command is needed to emulate cherry pick
git cp $(cat .git/rebase-merge/stopped-sha)

and if you are using the --merge option you need to enter
git cherry-pick $(cat $DIR/rebase-merge/current)
Therefore, to simplify things it would be best to use this alias:
git config alias.rebase2cherry '! git reset --hard HEAD; DIR=$(git rev-parse --git-dir); if [[ -f $DIR/rebase-apply/patch ]]; then git cherry-pick $(head -1 $DIR/rebase-apply/patch); elif [[ -f $DIR/rebase-merge/current ]] ; then git cherry-pick $(cat $DIR/rebase-merge/current); else git cherry-pick $(cat $DIR/rebase-merge/stopped-sha); fi'

