I've found that a lot of CI failure JIRA titles don't conform to the width limit, and I like to use those in my commit message title. Otherwise I have no problem with this.
Le jeudi 18 août 2016, Kenneth Howe <kh...@pivotal.io> a écrit : > +1 to Kirk’s proposal > > > On Aug 17, 2016, at 6:09 PM, Kevin Duling <kdul...@pivotal.io > <javascript:;>> wrote: > > > > +1 for that > > > > > > On Wed, Aug 17, 2016 at 5:25 PM, Kirk Lund <kl...@pivotal.io > <javascript:;>> 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 > <javascript:;>> 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 > <javascript:;>> 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 <javascript:;>> > >>>> 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 <javascript:;>> > >>>> 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 <javascript:;>> > >>>> 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 > <javascript:;>> > >> 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 > <javascript:;>> > >>> 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 > <javascript:;>> > >> 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 > <javascript:;>> > >>> 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 <javascript:;>> > >>>>>>>> Date: Wed, Aug 5, 2015 at 3:18 PM > >>>>>>>> Subject: git commit messages > >>>>>>>> To: dev@geode.incubator.apache.org <javascript:;> > >>>>>>>> > >>>>>>>> > >>>>>>>> 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 > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>> > >>>>> > >>>> > >>> > >> > >
