The tale of the one-word commit message

One morning a programmer came into the office. They got a cup of coffee, sat down and updated their local repository.

Their email notified about a crash bug had just been assigned to them. It was logged a few months prior, and only recently triaged. They read the reproduction steps and reviewed the attached crash dump.

A few minutes later they verified the steps work, and the dump matched their call stack.

It was time to check version control. There was only one change in the history for the file where the crash happened in the last year. They read the commit message.

Their heart sank.

The message was: “Fixes”.

One word. No details. Did it fix some other crash, or something else? Right now it seemed like it caused the crash they were investigating, instead of fixing anything.

It got even better: the author was no longer at the company.

Have you encountered this? Commit messages should be present, long enough, and descriptive. In this case it’s unclear what this change fixed and if there are implications to simply reverting it. This wasn’t an impossible situation, but it’s much more difficult than it had to be.

Include a description of the bug that was fixed. Ideally describe what was done to fix it, and why. Even if you include a link to a bug tracking ticket, the bug tracker might disappear in the future, so at the very least include the title text.

Do other developers and your future self a favour, and write more descriptive commit messages, especially describing fixes.