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
> > >>>
> > >>>
> > >>>
> > >>>
> > >>
> >
> >
>

Reply via email to