Git commit messages

Remya Vava
2 min readJun 8, 2018

--

This should be the only one situation where you shouldn’t be worried about your commit messages !!

There has already been lot of discussions about writing good commit messages. Here’s my turn summarizing them.

Like almost all code reviewers I too used to get annoyed seeing inappropriate commit messages.

A few examples of bad commit messages.

  • Fix issue
  • Bug fix
  • Resolved conflicts
  • Completed task

There's no point in adding these one liners if you're not explaining what changes you've actually made to the ni repo with the commit.

Structure of a good commit message

  • A brief summary as the first liner.
  • A blank line after the first line.
  • A detailed description of the change you have made, break this into paragraphs if necessary.
  • Reference links

A few points to consider while writing commit messages.

  • Keep in mind you have made changes to the existing repo and you’re going to help someone understand that.

Your commit messages should answer a Why (why a change is being made), How (how did you address the issue) and What (what’s the impact of this commit)

  • Divide your commit messages into several sections. It should contain a summary, description, reference links if any
  • Summarize your commit message in one line and keep it separate from the description that follows.
  • Don’t go for lengthy descriptions which would take the whole page. Instead break it down as short paragraphs explained with bullet points.
  • Descriptions should also include any limitations in the current code which you’ve identified
  • Add reference links if any. This could be a reference link to your task id or a link pointing to a forum from where you got the solution.

An example of a good commit message:

commit 3114a97ba188895daff4a3d337b2c73855d4632d
Author: [removed]
Date: Mon Jun 11 17:16:10 2012 +0100

Update default policies for KVM guest PIT & RTC timers

The default policies for the KVM guest PIT and RTC timers
are not very good at maintaining reliable time in guest
operating systems. In particular Windows 7 guests will
often crash with the default KVM timer policies, and old
Linux guests will have very bad time drift

Set the PIT such that missed ticks are injected at the
normal rate, ie they are delayed

Set the RTC such that missed ticks are injected at a
higher rate to "catch up"

This corresponds to the following libvirt XML

<clock offset='utc'>
<timer name='pit' tickpolicy='delay'/>
<timer name='rtc' tickpolicy='catchup'/>
</clock>

And the following KVM options

-no-kvm-pit-reinjection
-rtc base=utc,driftfix=slew

This should provide a default configuration that works
acceptably for most OS types. In the future this will
likely need to be made configurable per-guest OS type.

Closes-Bug: #1011848

Change-Id: Iafb0e2192b5f3c05b6395ffdfa14f86a98ce3d1f

For more details please refer this article: https://wiki.openstack.org/wiki/GitCommitMessages#Information_in_commit_messages

--

--

Remya Vava

Speaker, WomenTechmakers, Tech enthusiast, Still a Passionate Developer