You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Kirk Lund <kl...@pivotal.io> on 2015/08/06 00:18:03 UTC
git commit messages
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
Re: git commit messages
Posted by arghya sadhu <ar...@gmail.com>.
+1
On Thu, Aug 6, 2015 at 9:15 AM, William Markito <wm...@pivotal.io> wrote:
> +1
>
> On Wed, Aug 5, 2015 at 4:49 PM, Vincent Ford <vf...@pivotal.io> wrote:
>
> > +1
> >
> > *Vince Ford*
> > GemFire Sustenance Engineering
> > Beaverton, OR USA
> > 503-533-3726 (office)
> > http://www.pivotal.io
> > Open Source Project Geode https://geode.incubator.apache.org/
> > <https://network.pivotal.io/products/project-geode>
> >
> > On Wed, Aug 5, 2015 at 3:59 PM, Anthony Baker <ab...@pivotal.io> wrote:
> >
> > > +1
> > >
> > > Anthony
> > >
> > >
> > > > On Aug 5, 2015, at 3:18 PM, Kirk Lund <kl...@pivotal.io> wrote:
> > > >
> > > > 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
> > >
> > >
> >
>
>
>
> --
>
> William Markito Oliveira
> Enterprise Architect
> -- For questions about Apache Geode, please write to
> *dev@geode.incubator.apache.org
> <de...@geode.incubator.apache.org>*
>
Re: git commit messages
Posted by William Markito <wm...@pivotal.io>.
+1
On Wed, Aug 5, 2015 at 4:49 PM, Vincent Ford <vf...@pivotal.io> wrote:
> +1
>
> *Vince Ford*
> GemFire Sustenance Engineering
> Beaverton, OR USA
> 503-533-3726 (office)
> http://www.pivotal.io
> Open Source Project Geode https://geode.incubator.apache.org/
> <https://network.pivotal.io/products/project-geode>
>
> On Wed, Aug 5, 2015 at 3:59 PM, Anthony Baker <ab...@pivotal.io> wrote:
>
> > +1
> >
> > Anthony
> >
> >
> > > On Aug 5, 2015, at 3:18 PM, Kirk Lund <kl...@pivotal.io> wrote:
> > >
> > > 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
> >
> >
>
--
William Markito Oliveira
Enterprise Architect
-- For questions about Apache Geode, please write to
*dev@geode.incubator.apache.org
<de...@geode.incubator.apache.org>*
Re: git commit messages
Posted by Vincent Ford <vf...@pivotal.io>.
+1
*Vince Ford*
GemFire Sustenance Engineering
Beaverton, OR USA
503-533-3726 (office)
http://www.pivotal.io
Open Source Project Geode https://geode.incubator.apache.org/
<https://network.pivotal.io/products/project-geode>
On Wed, Aug 5, 2015 at 3:59 PM, Anthony Baker <ab...@pivotal.io> wrote:
> +1
>
> Anthony
>
>
> > On Aug 5, 2015, at 3:18 PM, Kirk Lund <kl...@pivotal.io> wrote:
> >
> > 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
>
>
Re: git commit messages
Posted by Anthony Baker <ab...@pivotal.io>.
+1
Anthony
> On Aug 5, 2015, at 3:18 PM, Kirk Lund <kl...@pivotal.io> wrote:
>
> 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
Re: git commit messages
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Wed, Aug 5, 2015 at 11:18 PM, Kirk Lund <kl...@pivotal.io> wrote:
> 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.
Even though it's on Subversion's site, the conventions we adopted as a
community are more generic and applicable to git as well:
http://subversion.apache.org/docs/community-guide/conventions.html#log-messages
Cheers. -- justin
Re: git commit messages
Posted by Bruce Schuchardt <bs...@pivotal.io>.
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 <kduling@pivotal.io
> <javascript:;>> wrote:
> >
> > +1 for that
> >
> >
> > On Wed, Aug 17, 2016 at 5:25 PM, Kirk Lund <klund@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 <dsmith@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 <klund@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 <klund@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 <klund@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 <klund@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 <kl...@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 <khowe@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 <kduling@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 <klund@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 <klund@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 <klund@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
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
>
>
Re: git commit messages
Posted by Kenneth Howe <kh...@pivotal.io>.
+1 to Kirk’s proposal
> On Aug 17, 2016, at 6:09 PM, Kevin Duling <kd...@pivotal.io> wrote:
>
> +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 <ds...@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 <kl...@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 <kd...@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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
Re: git commit messages
Posted by Kevin Duling <kd...@pivotal.io>.
+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 <ds...@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 <kl...@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 <kd...@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
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>
> > > >
> > > >
> > >
> >
>
Re: git commit messages
Posted by Kirk Lund <kl...@pivotal.io>.
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 <ds...@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 <kl...@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 <kd...@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
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>
> > >
> > >
> >
>
Re: git commit messages
Posted by Dan Smith <ds...@pivotal.io>.
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 <kl...@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 <kd...@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
> > >>>
> > >>>
> > >>>
> > >>>
> > >>
> >
> >
>
Re: git commit messages
Posted by Kirk Lund <kl...@pivotal.io>.
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 <kl...@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 <kd...@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
> >>>
> >>>
> >>>
> >>>
> >>
>
>
Re: git commit messages
Posted by Kenneth Howe <kh...@pivotal.io>.
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 <kd...@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
>>>
>>>
>>>
>>>
>>
Re: git commit messages
Posted by Dan Smith <ds...@pivotal.io>.
To me, having a meaningful short summary line is still pretty useful. I use
git oneline and github and my ide also use that summary line.
-Dan
On Wed, Aug 17, 2016 at 3:45 PM, Kevin Duling <kd...@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
> > >
> > >
> > >
> > >
> >
>
Re: git commit messages
Posted by Kevin Duling <kd...@pivotal.io>.
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
> >
> >
> >
> >
>
Re: git commit messages
Posted by Kirk Lund <kl...@pivotal.io>.
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
>
>
>
>
Fwd: git commit messages
Posted by Kirk Lund <kl...@pivotal.io>.
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