+1 to descriptive commit messages Done well they will save time on every post commit access to that commit.
-- Mike Stolz Principal Engineer - Gemfire Product Manager Mobile: 631-835-4771 On Sep 12, 2018 4:15 PM, "Alexander Murmann" <amurm...@pivotal.io> wrote: > 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? > > > > > > > > > >
