Git Commit Messages : 50/72 Formatting

Question

Tim Pope argues for a particular git commit message style in his blog post: http://www.tpope.net/node/106

Here is a quick summary of what he recommends:

• First line is 50 characters or less
• Then a blank line
• Remaining text should be wrapped at 72 characters

His blog post gives the rationale for these recommendations (which I will call "50/72 formatting" for brevity):

• In practice, some tools treat the first line as a subject line and the second paragraph as a body (similar to email)
• git log does not handle wrapping, so it is hard to read if lines are too long.
• git format-patch --stdout converts commits to email -- so to play nice it helps if your commits are already wrapped nicely.
• a point I would like to add that I think Tim would agree with: the act of summarizing your commit is a good practice inherently in any version control system. It helps others (or a later you) find relevant commits more quickly.

So, I have a couple of parts to my question:

• What chunk (roughly) of the 'thought leaders' or 'experienced users' of git embrace the 50/72 formatting style? I ask this because sometime newer users don't know or don't care about community practices.
• For those that don't use this formatting, is there a principled reason for using a different formatting style? (Please note that I'm looking for an argument on the merits, not "I've never heard of it" or "I don't care.")
• Empirically speaking, what percentage of git repositories embrace this style? (In case someone wants to do an analysis on GitHub repositories... hint, hint.)

My point here is not to recommend the 50/72 style or shoot down other styles. (To be open about it, I do prefer it, but I am open to other ideas.) I just want to get the rationale for why people like or oppose various git commit message styles. (Feel free to bring up points that haven't been mentioned, too.)

Answer 1

50/72 formatting seems interesting. When working with teams of developers it's a good pratice to establish commom indioms between them, like design patterns. The arguments that Tim Pope give us make sense. I think that the only reason for using a different formatting style may be best pratices imposed by the managers or the business.

Answer 2

I'd agree it is interesting to propose a particular style of working. However, unless I have the chance to set the style, I usually follow what's been done for consistency.

Taking a look at the Linux Kernel Commits, the project that started git if you like, http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=bca476139d2ded86be146dae09b06e22548b67f3, they don't follow the 50/72 rule. The first line is 54 characters.

I would say consistency matters. Set up proper means of identifying users who've made commits (user.name, user.email - especially on internal networks. User@OFFICE-1-PC-10293982811111 isn't a useful contact address). Depending on the project, make the appropriate detail available in the commit. It's hard to say what that should be; it might be tasks completed in a development process, then details of what's changed.

I don't believe users should use git one way because certain interfaces to git treat the commits in certain ways.

I should also note there are other ways to find commits. For a start, git diff will tell you what's changed. You can also do things like git log --pretty=format:'%T %cN %ce' to format the options of git log.