You write whatever the convention is for commit messages in your team.
Many teams have certain conventions for commit messages because you use them to create a change log, something like this one:
If you don't have a convention, then think about the rest of the messages you use to commit. What do you write for those? Something useful, no doubt.
For example, Git generates a default message that tells you the files that were in conflict. I find that default message very useful and keep it. I find it useful because sometimes (in the project I used to work) bugs were introduced by my team members by badly resolving some conflicts. Later when I chased some bug and wanted to know what has happened with the source code lately, I first looked for the "usual suspects" inside the commit message, before doing anything else.
So think about what would be useful for you (or your team) as a conflict message, then go with that. If you resolve the conflict with minor changes then "Resolving conflict" is enough otherwise (emphasis mine):
If you think it would be helpful to others looking at this merge in the future, you can modify this commit message with details about how you resolved the merge and explain why you did the changes you made if these are not obvious.