Yeah, 50 chars seems a bit short. I think I've been aiming for 72 personally.
-Dan On Wed, Aug 17, 2016 at 4:37 PM, Kirk Lund <kl...@pivotal.io> wrote: > 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 > > >>> > > >>> > > >>> > > >>> > > >> > > > > >
