29

I usually write long commit messages in my git bash so that later some one reading my code could easily see what I done.for example in vs2013 in windows form application when designing a form I wrote following.

git commit -m "Add Name,age ,height,weight and salary labels with corresponding text boxes and more over a Submit Button..."

Problem was when I typed git log --oneline it did not display whole message and chopped off a part of it. My question is that what is the way to write long commit messages in git ,what is the limit and how to display them so that all message could easily be seen on git bash?

Naseer
  • 4,041
  • 9
  • 36
  • 72
  • 3
    See also [Git Commit Messages : 50/72 Formatting](http://stackoverflow.com/questions/2290016/git-commit-messages-50-72-formatting). –  Mar 29 '14 at 12:47
  • 1
    Possible duplicate of [How to wrap git commit comments?](http://stackoverflow.com/questions/2119942/how-to-wrap-git-commit-comments) –  Mar 29 '14 at 12:54
  • Search about "git commit formatting" and you should get hundreds of explanations. This one is pretty good and short: https://stackoverflow.com/a/50397345/134044 – NeilG Jun 02 '23 at 01:40
  • I don't understand why some people find it difficult to use consistent spacing with their commas in prose? Since you spend so much effort finding out about proper git commit message formatting, how come you can't be bothered to type "Add name, age, height, weight and salary" instead of "Add Name, age ,height,weight and salary"? I think you've got one of every possible variation and only 1 out of 4 is correct. You haven't even used consistent casing for the nouns. I'm not trying to be rude, I'd just like to understand, because quite a few people do this. Can you please explain @naseer? – NeilG Jun 02 '23 at 01:46

1 Answers1

35

The way git displays log messages is that it will take the 1st line and use that in git log --oneline, and then anything else is displayed when using the normal git log, as long as there's a blank line between the first and second parts:

Add summary line here

An example of how to write long commit messages.
Blah blah blah blah blah.
SKADOOSH!

A standard that a lot of people use it to use the first line as a summary of the changes in the commit, and to keep it at a max of 50 characters in length so that it can fit when using git log --oneline --graph. This is actually the standard that the Linux kernel and git project maintainers themselves use (GitHub promotes it as well).

You might feel that 50 characters is too short though, so another standard that you could use is to keep the summary to a max of 72, 78, or 80 chars.

For the rest of the commit message, keeping the max line length to 72, 78, or 80 chars max can also be helpful, like if you often split your monitor screens with a terminal in one half and a browser or editor in the other half. Many editors have shortcuts that will auto-wrap long lines to a max column length for you.

For example, in Sublime Text, the command is ALT + CMD + q. Vim also has a few shortcuts to do this (gq is one of them), but you need to configure the max line length for it to work. The same goes for Sublime Text.

user541686
  • 205,094
  • 128
  • 528
  • 886
  • 10
    Also, keeping it to 50 chars encourages smaller commits, which can make debugging easier. – f1lt3r Sep 02 '15 at 19:09
  • @f1lt3r “[Great Git Commit Messages Are Not Shorter Than 50 Characters](https://betterprogramming.pub/an-advice-for-developers-great-git-commit-messages-are-not-shorter-than-50-characters-2becf8fd481a)” – Jason Sparc May 20 '23 at 02:59
  • This answer doesn't seem to be informed by historical practice and recommendations. The original recommendation was 50 chars in the initial line, then a blank line, then subsequent lines restricted to 72 chars. This is known as the "50/72 formatting". Here's a better answer about that: https://stackoverflow.com/a/50397345/134044 – NeilG Jun 02 '23 at 01:42