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

Question

How do I edit or reword a merge commit\'s message?

git commit --amend works if it\'s the last commit made (HEAD), but what if it comes befo

Answer 1

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 mynewbranch

Awesome 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 existing one (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)}

Answer 2

git merge --edit
Allows you to give the comment even in case of non-interactive merge.

git merge --edit --no-ff can be useful if you follow git flow with rebasing on development branch and merging into it with no fast forward.

Answer 3

For current Git versions (Mai 2020):

git rebase -i -r <parent>,

then replace in the editor merge -C ... with merge -c ....

This will open the commit message in the editor during rebasing, where you can change it.

(Thanks to VonC for the hint.)

Answer 4

The git rebase -i HEAD~5 command pops up the editor. It lists the specified commits (in this case five of them). The first column contains pick for every commit. Just replace pick with reword in that editor and save+close the editor. Then git will pop up the editor for every commit where you changed pick to reword and will let you edit the commit message.

Answer 5

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

Answer 6

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

git checkout <sha of merge>
git commit --amend # edit message
git 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!).