How to use the default git commit message after re

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

Answer 1

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

1. is this a merge commit?
2. if so, does combined diff show files?
3. 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.

Answer 2

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.

Answer 3

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.

Answer 4

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

Answer 5

Just set the editor to a command that does nothing:

GIT_EDITOR=true git commit

Answer 6

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.