TITLE: Commit message guidelines

The format of commit messages should be a short description of what you did.
After the short description, the bug ID, review ID or anything else such as a new line going more in-depth into your commit.

The commit log should not contain the obvious.
If you change file Foo.cpp:

 BAD:
    "Fixed bug in Foo.cpp"
 BAD:
    "Fixed #45"
 BAD:
    "Commited Foo.cpp"
 GOOD:
    "PathTo/Foo.cpp: Fixed buffer overflow (close #45)"
 EXAMPLE:
    "GUIApp/FindDuplicates.cpp: Added missing include file (#45)"

Format: "PathTo/FileName.*: <commit message here>"

Note:
If you change both the .h and .cpp of a file, in your commit split them up like so "PathTo/FileName.h|cpp: <commit message here>".

If you do a project wide change:

 BAD:
    "Removed /GM compiler flag from ProjectName"
 GOOD:
    "ProjectName: Removed /GM compiler flag"

Format: "ProjectName: <commit message here>"

Or if you do a general repo change:

 BAD:
    "Time to worship CMake!"
 GOOD:
    "Added CMake for build automation"
 GOOD:
    "CMake: Updated CMakeLists.txt"

Format*: <commit message here>
* Unless related to something within the repository such as CMake.

The above does not mean that when you do a complex change do not write a description of what you did, on the contrary.
When a long description is needed do add as much as needed to explain the change on a separate line, 
just do not add meaningless information (ex. "Committing Foo.cpp" etc.)

It is advisable to split complex commits to several smaller commits if possible. 
If you see that your commit massage contain more then one topic, you probably can, 
and should, split the commit into a few unrelated commits.