How to use the default git commit message after resolving merge conflicts?

Question

After doing a merge and resolving conflicts, is there an "easy" way to just accept the default generated commit message from the command line? One of our developers will resolve all the conflicts, and then do a git commit -m"Merge Commit" which replaces the generated commit message that listed all the conflict files. I would like to have a different flag that would just take the current file without modification. I know there is a -F or --file= option, but that requires knowing the file name all the time.

Thank you

score 164 · Answer 1 · answered Mar 23 '16 at 21:57

164

Per the docs, I just tried this simple command and it worked for me:

git commit --no-edit

Afterward, run git log to confirm that the default message has been used.

answered Mar 23 '16 at 21:57

gMale

17,147
17
91
116

5

Or with shorter output: `git log -1`. – Lyubomyr Shaydariv Feb 04 '17 at 02:08
This seems to also work for the `merge` command as in `git merge master --no-edit`. – amoebe Jul 29 '19 at 09:00

Maic López Sáenz · Answer 2 · 2015-06-29T22:45:01.287

By default when a merge fails the commit message that was to be used is saved in a file in the git folder, usually .git/MERGE_MSG. After the conflicts are resolved running git commit will feed this saved message to the default editor.

If the message is not being picked up on its own it could be feed to the git command using the --file option, which reads the commit message from a file:

git commit --file .git/MERGE_MSG

score 19 · Answer 3 · answered Dec 19 '12 at 22:23

19

Just set the editor to a command that does nothing:

GIT_EDITOR=true git commit

answered Dec 19 '12 at 22:23

Chronial

66,706
14
93
99

I like this one. :) Though I still argue that the question is evidence of a deeper problem in the development process. If the coders are in a situation where they "want" a nonsense merge message, they probably aren't really merging two forks and are just integrating new changes from upstream. That's a rebase. – Andy Ross Dec 19 '12 at 22:28
1

Oh, I agree that you probably want your coders to think about their merge messages – but that wasn’t the question ;). But also you often need to do trivial merges because you can’t do a rebase as your branch is published. – Chronial Dec 19 '12 at 22:37
I am not quite sure how this works. How does changing the editor prevent the git commit -m"Merge Commit" syntax from over writing the default generated commit message? My problem is that I want to keep all the merge conflict files listed in the commit message. – yoyodyn Jan 30 '13 at 22:26
It doesn’t – there is no way in git (or most other tools for that case) to stop it from doing what it’s been explicitly told. If you don’t want to set a commit message, don’t use `-m`. My answer will just prevent an editor to pop up. – Chronial Jan 30 '13 at 23:15
This is extremely useful for scripting "experiments" with git. Eg., https://gist.github.com/jhoblitt/6bb4305e0b548e8e0de9 – Joshua Hoblitt May 13 '15 at 23:15

score 5 · Accepted Answer · answered Dec 19 '12 at 22:26

5

Obviously the "right" answer here is to get your developer to follow correct practice for your team when generating merge commits. Note that the behavior you want used to be the default, and that only recently has git begun demanding "human generated" commit messages for merges. That was for a reason, and it wasn't so that developers would short-circuit the process with a meaningless message.

Maybe the developer is generating merge commits when s/he should be rebasing instead?

That said, the merge commit is the output of git fmt-merge-msg, to which you would have to feed the parents of the merge commit.

answered Dec 19 '12 at 22:26

Andy Ross

11,699
1
34
31

2

How is this command used? Documentation says that it expects the merge objects to be provided by stdin. I tried piping into it, and also providing through a file, the revision numbers of the parents, but it kept throwing back a `fatal: Error in line 1:...`. – Maic López Sáenz Dec 19 '12 at 23:51
1

How exactly would a rebase not also cause conflict, versus a merge? – randombits May 02 '20 at 00:37
1

@randombits it would still require conflict resolution, but would not generate a merge commit. – RJFalconer Aug 10 '20 at 21:54

Lyubomyr Shaydariv · Answer 5 · 2017-02-26T08:19:47.617

git commit --file .git/MERGE_MSG as already mentioned is fine but it ignores a few points:

The current directory is not the top-most directory
The current repository is a Git submodule thus having no the .git directory but a file .git.

And optionally:

MERGE_MSG contains some information about files with conflicts.

The first two points can be used with git rev-parse:

git commit -F "$(git rev-parse --git-dir)/MERGE_MSG"

Or, alternatively, with a Git alias:

commit-merge = !cat $(git rev-parse --git-dir)/MERGE_MSG | git commit -F -

This works both in "normal" repositories and submodules. If the #-marked conflict markers should be discarded, for simplicity, only the first line for the merge message could be taken:

git commit -m $(head -1 $(git rev-parse --git-dir)/MERGE_MSG)

Or another alias:

commit-merge = !head -1 $(git rev-parse --git-dir)/MERGE_MSG | git commit -F -

I had to use the -F key in aliases because I couldn't make Git emit quotes to be processed in the generated commands with bash (otherwise git commit would complain for partial commits during merges).

Git 2.12.0 that was released two days ago introduces git merge --continue to make a merge commit that was stopped on conflicts during the merge. It works fine for submodules as well, but does not accept --no-edit, at least yet, so an editor is suggested to change the commit message before concluding the merge.

score 2 · Answer 6 · answered Feb 11 '21 at 15:12

You can use a default "git commit" with no message. This will trigger the VIM editor in your console. The default message will appear in VIM, just use the command ":wq" to apply the merge and exit VIM.

Walkthrough of steps below:

git commit (hit enter)

:wq (to exit and apply merge in VIM editor)

score 1 · Answer 7 · answered May 19 '21 at 11:55

$git commit --amend --no-edit

It will take your previously committed message and nothing will change.
It will be helpful when you're resolving any merge conflict and want to take your previously committed message and apply master code in your feature branch to avoid the conflict.

score 0 · Answer 8 · answered Jun 26 '15 at 18:47

If you really want to enforce this rule, then there might be a way to force this using git hooks.

Every time there is a merge conflict, then a 'combined diff' will show you which files were conflicted: git diff HEAD HEAD^1 HEAD^2 --name-only. I do not know if technically it's possible for a combined diff to show more files than just conflicted ones.

But, assuming it works like we want (which is an assumption), then you can have a git commit-msg hook which checks the message that the user typed in and assert

is this a merge commit?
if so, does combined diff show files?
if so, does the string "Conflicts:" followed by those file names?

If those conditions fail, then have the script print to screen an explanation of what's wrong, and then return non-zero to abort the commit. You can have developers install this commit hook, or you can also install it on the server to enforce it for sure.

How to use the default git commit message after resolving merge conflicts?

8 Answers8

Linked