[katello-devel] Commit Messages

[David Davis]

As a user of git log and git shortlog, I was going to bring this up too. I see a lot of people going over 70 characters for the short message in commit messages. The git tools are really based around a short message and long message and this makes it hard to read commits in git log and git shortlog. Also, I think we should limit the short message to 50 chars which is what Linus and other git gurus recommend. More information below.

http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
https://github.com/torvalds/subsurface/blob/master/README#L231

Regarding adding components though, I think it's generally a good idea as well. I would prefer to move to colons which Linus uses in his example (and it's also one char shorter) but dashes are fine too.

David

----- Original Message -----
> From: "Eric D Helms" <ericdhelms at gmail.com>
> To: "katello-devel" <katello-devel at redhat.com>
> Sent: Tuesday, May 14, 2013 9:11:38 AM
> Subject: [katello-devel] Commit Messages
> 
> I was reading over our Development Process wiki page, and while there are
> some out of date items that need cleaning up on it, there is one item that I
> wanted to encourage developers to follow. This is a rule of thumb I try to
> follow with regards to commit messages that I think helps when reading
> through the git log, looking through previous changes or when seeing a pull
> request opened up. To quote the page [1]:
> 
> "Commit messages should take the form:
> 
> Component: Short summary with no more than 70 characters
> 
> The next lines of your commit can contain more lines with paragraphs
> separated by a blank line in between each paragraph. These should also be
> wrapped at 74 or so characters. Why do this? Because it displays better
> in git log and on github.
> 
> The component is actual user story being worked on. Keep it same for multiple
> commits. You can also use dash instead of colon, example:
> 
> packagegroups - system test
> packagegroups - unit test for CLI
> packagegroups - unit test
> packagegroups - adding support in CLI
> packagegroups - adding support in backend
> "
> 
> The part of that I think we could benefit more from is the inclusion of the
> component name (just like we do bugzilla and github issue numbers to preface
> bug fixes) as part of commit messages. For example:
> 
> Menu -
> Content View Definition -
> Comps -
> Rel-eng -
> API -
> Systems -
> 
> Ref:
> https://fedorahosted.org/katello/wiki/DevProcess#CommitMessages:DescribeYourChanges
> 
> 
> - Eric
> 
> _______________________________________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/katello-devel