geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Helena Bales <hba...@pivotal.io>
Subject Re: [discuss] Should we evaluate at commit messages as part of PR review?
Date Wed, 12 Sep 2018 23:07:32 GMT
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 <pchandra@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 <amurmann@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?
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message