Some examples from feature/GEODE-1781-02 which are my latest unmerged
commits...
1) 1st line is 62 chars. To shorten to 50: "GEODE-1799: fix javadocs on
CacheServerStats" or "GEODE-1799: change javadocs from Bridge to Cache"
commit 0a07db189c8b928976ed6554499f15b6a64e1633
Author: Kirk Lund <kl...@apache.org>
Date: Wed Aug 17 16:27:52 2016 -0700
GEODE-1799: change javadocs from Bridge Server to Cache Server
2) 1st line is 80 chars. To shorten to 50: "GEODE-1781: exclude class from
AnaylzeSerializableJUnitTest"
commit 55c5df5e4cd6228be1617fb1e92d8d955a703b08
Author: Kirk Lund <kl...@apache.org>
Date: Tue Aug 16 09:25:33 2016 -0700
GEODE-1781: exclude LinuxProcFsStatistics$CPU from
AnaylzeSerializableJUnitTest
3) 1st line is 59 chars. To shorten to 50: "GEODE-1782: fix stat resource
equals"
(the later lines meet our guidelines)
commit 7dc1ce68a483f993adeb613893073d8a7c88a9b7
Author: Kirk Lund <kl...@apache.org>
Date: Mon Aug 15 18:35:45 2016 -0700
GEODE-1782: include start timestamp in stat resource equals
* stat resources with different time stamps should not be equal
* StatArchiveWithConsecutiveResourceInstGenerator generates gfs with
multiple stat resources of same name but different times
* StatArchiveWithConsecutiveResourceInstIntegrationTest confirms
existence of bug GEODE-1782: StatArchiveReader ignores later stats
resource with same name as closed stats resource
* ResourceInstTest verifies the underlying issue and fix in
StatArchiveReader.ResourceInst.equals and the fix
4) I got this one down to 48 chars!
(the later lines meet our guidelines)
commit 115070123ec15638ca1189a7349938c35e0d51e0
Author: Kirk Lund <klund@Kirks-MacBook-Pro.local>
Date: Mon Aug 15 18:26:16 2016 -0700
GEODE-1781: refactor internal statistics classes
* move internal statistics classes into com.gemstone.gemfire.internal.
statistics
* move statistics tests into com.gemstone.gemfire.internal.statistics
* modify tests to include integration and distributed in names
* modify tests to use TemporaryFolder and TestName rules
On Wed, Aug 17, 2016 at 4:22 PM, Kenneth Howe <kh...@pivotal.io> wrote:
> Agree with Kirk, 50 chars is really short by the time you use up the first
> 12 characters for the Jira tag. If we’re going to have a guideline, I’d
> rather be longer - somewhat arbitrarily I’d probably make it 20-30 chars
> more. It’s been a long time since text listings were intended to fit on a
> 80x24 dumb terminal, so I don’t see a need to restrict the commit message
> headers so severely.
>
> I do use the —online option embedded in a local alias I use to look at a
> history list of my local repo.
>
> Ken
>
> > On Aug 17, 2016, at 3:45 PM, Kevin Duling <kdul...@pivotal.io> wrote:
> >
> > The format is very similar to the one most other git shops I've worked in
> > before use. I don't believe we ever had formal length limits.
> Typically,
> > it was:
> >
> > <JIRAPROJECT>-####: <Jira Ticket Summary>
> >>
> > blank line
> >
> > <brief description of fix, usually matching what was placed in the
> ticket>
> >
> >
> > The Atlassian plugin for IDEA automates a lot of this. There are limits
> on
> > the length of a jira ticket summary, but I'm not sure what that is. I
> ran
> > in to it when I did my round of CI.
> >
> > I don't see a reason to change anything except maybe stress that he
> lengths
> > are a guideline, not a hard & fast rule. If more room is needed to write
> > good information, it shouldn't be truncated as it's not unknown to move
> > away from a given ticket system.
> >
> > On Wed, Aug 17, 2016 at 3:38 PM, Kirk Lund <kl...@pivotal.io> wrote:
> >
> >> 50 chars including "GEODE-nnnn: " is awfully short.
> >> http://chris.beams.io/posts/git-commit/ does say that's just a general
> >> rule
> >> of thumb and not a hard limit. The author's reasoning seems to be
> >> specifically for using "git log --oneline" -- does anyone use that
> option
> >> with git log? I don't.
> >>
> >> I guess another option is to not have to have a guideline if we don't
> want
> >> one... our current git log messages are reasonable and make sense.
> >>
> >> -Kirk
> >>
> >>
> >> On Wed, Aug 17, 2016 at 3:21 PM, Kirk Lund <kl...@pivotal.io> wrote:
> >>
> >>> Here's the git commit message guidelines we discussed and voted on last
> >>> year. I just checked and my own git commit message line lengths have
> >> grown
> >>> beyond what we decided to use. Most other are also not following this
> >>> guideline.
> >>>
> >>> Here's the list of folks who voted last year along with their vote:
> >>>
> >>> Anthony Baker +1
> >>> Vincent Ford +1
> >>> William Markito +1
> >>> arghya sadhu +1
> >>>
> >>> Do we want to reaffirm this guideline or should it change?
> >>>
> >>> -Kirk
> >>>
> >>> ---------- Forwarded message ----------
> >>> From: Kirk Lund <kl...@pivotal.io>
> >>> Date: Wed, Aug 5, 2015 at 3:18 PM
> >>> Subject: git commit messages
> >>> To: dev@geode.incubator.apache.org
> >>>
> >>>
> >>> Several of us were discussing http://chris.beams.io/posts/git-commit/
> --
> >>> there are a couple other really good articles about git commit messages
> >> and
> >>> below is the message style I've been trying to follow.
> >>>
> >>> http://chris.beams.io/posts/git-commit/
> >>> http://www.laurencegellert.com/2013/07/how-to-write-a-proper-commit-
> >>> message/
> >>> http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
> >>>
> >>> GEODE-nn: Begin capitalized and 50 chars or less
> >>>
> >>> More detailed explanation with linefeeds to wrap at 72 characters after
> >>> a blank line following the summary.
> >>>
> >>> Further paragraphs come after blank lines.
> >>>
> >>> - Bullet points are okay, too
> >>>
> >>> - Typically a hyphen or asterisk is used for the bullet, followed by a
> >>> single space, with blank lines in between, but conventions vary here
> >>>
> >>> - Use a hanging indent
> >>>
> >>>
> >>>
> >>>
> >>
>
>
