While our wiki page primarily calls out the 50/74 rule which is important, my bigger concern is in that I'd love to see commit messages that explain why a change was made. Sometimes that information is in the reference JIRA ticket, but not always. Especially with bug fixes we tend to not explain what actually caused the bug and how the code changes address it. It's also nice to minimize moving back and forth between editor and browsing JIRA and even better not to have to read 20+ messages long comment threads about a bug in JIRA to find out what the problem was. No hard rule can make sure we are doing that right, only human reviewers and care can. I don't think it's actually any extra work, since we are already reading the PR description and commit messages when we are doing a PR review. How else can you understand the PR? In fact better commit messages should save time here and not steal it.
I totally agree that we don't always need a long text. "Fix typo in XYZ output" is totally fine. Both the why and what are obvious. On Wed, Sep 12, 2018 at 4:07 PM, Helena Bales <hba...@pivotal.io> wrote: > I'm a fan of having useful commit messages. I would prefer this to be > another checkbox in our list of 6 things to do for Pull Requests as opposed > to something that is strictly enforced. There are cases where a simple > one-liner commit message is enough. I personally use commit messages often, > even when looking back at my own work. Additionally, I think it is a useful > exercise as it forces the dev to think back on the original problem and > think about how the solution addresses that. > > tl;dr -- +1 for commit messages > > ~Helena > > On Wed, Sep 12, 2018 at 11:50 AM, Pulkit Chandra <pchan...@pivotal.io> > wrote: > > > Have we thought about git hooks as a way to enforce policy > > https://git-scm.com/book/en/v2/Customizing-Git-An-Example- > > Git-Enforced-Policy > > ? > > > > *Pulkit Chandra* > > > > > > On Wed, Sep 12, 2018 at 2:46 PM Alexander Murmann <amurm...@pivotal.io> > > wrote: > > > > > Hi everyone, > > > > > > We have a wiki page > > > <https://cwiki.apache.org/confluence/display/GEODE/ > Commit+Message+Format > > > > > > that discusses why good commit messages matter and links to a even > better > > > article on the topic. In addition to what's described in those > documents, > > > better commit messages also would make it easier to have good PR > > messages. > > > Good commit and PR messages also provide more context to the reviewer > who > > > in turn now can do a better job at reviewing the pull request. > > > > > > Looking at our git log gives me the impression that we aren't always > > living > > > up to that standard. In fact we frequently aren't even close. > > > > > > I propose taking clear and well formatted commit messages into account > as > > > part of our PR review process. Lacking commit messages can be just as > bad > > > as bad naming in our code. > > > > > > Thoughts? > > > > > >
