Git: How to edit/reword a merge commit's message?

If you add the --preserve-merges option (or its synonym, -p) to the git rebase -i command then git will try to preserve the merges when rebasing, rather than linearizing the history, and you should be able to amend the merge commits as well:

git rebase -i -p HEAD~5

Note. --perserve-merges has been deprecated in favour of --rebase-merges as of git v2.22 (https://www.infoq.com/news/2019/07/git-2-22-rebase-merges/).

Note that, starting git1.7.9.6 (and git1.7.10+), git merge itself will always trigger the editor, for you to add details to a merge.

"git merge $tag" to merge an annotated tag always opens the editor during an interactive edit session. v1.7.10 series introduced an environment variable GIT_MERGE_AUTOEDIT to help older scripts decline this behaviour, but the maintenance track should also support it.

It also introduces an environment variable GIT_MERGE_AUTOEDIT to help older scripts decline this behavior.

See "Anticipating Git 1.7.10":

Recently in a discussion on the Git mailing list, Linus admitted (and I agreed) that this was one of the design mistakes we made early in the history of Git.
And in 1.7.10 and later, the git merge command that is run in an interactive session (i.e. both its standard input and its standard output connected to a terminal) will open an editor before creating a commit to record the merge result, to give the user a chance to explain the merge, just like the git commit command the user runs after resolving a conflicted merge already does.

Linus said:

But I don't really care deeply how it actually works - my main issue is that git makes it way too easy to have bad merge messages.
I think part of that is an even simpler idiocy: we never even fire up the editor by default for a "git merge", but we do for a "git commit".
That was a design mistake, and it means that if you want to actually add a note to a merge, you have to do extra work. So people don't.

Note that, before Git 2.17 (Q2 2018), "git rebase -p" mangled log messages of a merge commit, which is now fixed.

See commit ed5144d (08 Feb 2018) by Gregory Herrero (``).
Suggested-by: Vegard Nossum (vegard), and Quentin Casasnovas (casasnovas).
^{(Merged by Junio C Hamano -- gitster -- in commit 8b49408, 27 Feb 2018)}

rebase -p: fix incorrect commit message when calling git merge.

Since commit dd6fb00 ("rebase -p: fix quoting when calling git merge", January 2018, Git 2.16.0-rc2), the commit message of the merge commit being rebased is passed to the merge command using a subshell executing 'git rev-parse --sq-quote'.

Double quotes are needed around this subshell so that, newlines are kept for the git merge command.

Before this patch, following merge message:

"Merge mybranch into mynewbranchAwesome commit."

becomes:

"Merge mybranch into mynewbranch Awesome commit."

after a rebase -p.

With Git 2.23 (Q2 2019), A "merge -c" instruction during "git rebase --rebase-merges" should give the user a chance to edit the log message, even when there is otherwise no need to create a new merge and replace the existingone (i.e. fast-forward instead), but did not.
Which has been corrected.

See commit 6df8df0 (02 May 2019) by Phillip Wood (phillipwood).
^{(Merged by Junio C Hamano -- gitster -- in commit c510261, 13 Jun 2019)}

Another nice answer using only primitive commands -- by knittl https://stackoverflow.com/a/7599522/94687:

git checkout <sha of merge>git commit --amend # edit messagegit rebase HEAD previous_branch

or a better (more correct) final rebase command:

git rebase <sha of merge> previous_branch --onto HEAD

BTW, using the primitive commands might have the nice "feature" of not consuming too much CPU and making you wait unknown time until Git finishes thinking about the list of commits needing to be rebased in the case of git rebase -p -i HEAD^^^^ (such a command which would result in a list of only 4 last commits with the merge as last one in my case in my case took around 50 secs!).