+1 for that
On Wed, Aug 17, 2016 at 5:25 PM, Kirk Lund <kl...@pivotal.io> wrote: > The guidelines written by Chris Beams are designed to fit well within the > gui for github. He specifically says try for 50 but then try to keep 69 > chars as a hard-limit because the github gui will truncate at 69 chars and > append ellipse "..." at the end. This mostly affects non-apache committers > creating pull requests. > > I favor loose adherence to these guidelines: > > 1st line should be limited to 50-69 chars if possible. Subsequent lines > should be wrapped at 72 chars. > > -Kirk > > > On Wed, Aug 17, 2016 at 4:47 PM, Dan Smith <dsm...@pivotal.io> wrote: > > > 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 > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >> > > > > > > > > > > > > > >
