Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
From: Andrew Purtell <andrew.purtell@gmail.com>
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Subject: Re: Consider adding the issue number in commit message
Message-Id: <B45D4B71-30A0-4CB5-AF87-5915CA6FC316@gmail.com>
Date: Tue, 13 Sep 2016 16:05:41 -0700
References: <CAAAYAnOKiC4=Wx2VJZB1MBGzBab8eV8Dj=1CwGp63yjH=8pYHw@mail.gmail.com> <CADfYSXQ9bQQKojRB9WRiE=aWc6MKgOq6yGRP+kdKn_8f6yo4xw@mail.gmail.com> <CAGHyZ6+RkQeDOOf99zwwOnZ234tirUa7FZfVHsmd1ce_1mjMnw@mail.gmail.com> <CADfYSXR8fS9crLTjQo0-qkq38=0pBmgAp+8-8N4uUsS31j6vLw@mail.gmail.com> <CAGHyZ6KVJe2TYBuh7M7320reA+CDekOjnNwuCZtVyUW0b1uT_A@mail.gmail.com> <CA+RK=_Ajv_EPJTd1osYq7BO=A3gGk6vkDOST=C5Fcj_YYO9FMg@mail.gmail.com> <CAHkeaHVQKqOt81VWx=m9+gD-oRp9Mm-z0auqn9dXzZv_u-scVQ@mail.gmail.com> <CALte62xvSahhqQJsKawxj8-45cMgxJiGQfdU==nAyDGVhMtN1w@mail.gmail.com> <CAMUu0w-MVYQX6UiWgAscQX_GmPc3LbtKzOekgL49f82ex-jWSg@mail.gmail.com> <CAKYcnAuVe02cyzHJumpYJGqwN3FLokndOs3uMh=iyxkBbgTwRw@mail.gmail.com> <CAGyfEV__A-V7T=Jr4RvZnprqWORSOLz55+ttvUckju2_WCgokA@mail.gmail.com>
In-Reply-To: <CAGyfEV__A-V7T=Jr4RvZnprqWORSOLz55+ttvUckju2_WCgokA@mail.gmail.com>
To: dev@hbase.apache.org
archived-at: Tue, 13 Sep 2016 23:05:50 -0000

I believe we have the commit format documented in our online book. If not, l=
ets. =20

> On Sep 13, 2016, at 2:30 PM, Xi Yang <alex.xi.yang@gmail.com> wrote:
>=20
> +1
> If I don't put Jira issue number in commit message then I don't know
> whatelse I can put. Jira issue number already contain all the information
> of your commitment and it makes the commitment traceable .  So I suggest w=
e
> don't need to say any other words except Jira issue number and the title.
>=20
> The whole commitment message should be "HBASE-<number> xxxxxxxxx"
>=20
> That will make our got history looks clear
>=20
> Thanks
> Alex
>=20
>> On Tuesday, 13 September 2016, Dima Spivak <dimaspivak@apache.org> wrote:=

>>=20
>> +1 to that, Enis.
>>=20
>> -Dima
>>=20
>> On Tue, Sep 13, 2016 at 2:15 PM, Enis S=C3=B6ztutar <enis@apache.org
>> <javascript:;>> wrote:
>>=20
>>> +1 on not force pushing. The git repo is sync'ed to multiple places (lik=
e
>>> github, etc) so force pushes should be avoided unless a feature branch.
>>>=20
>>> Should we extend the list of no-force-pushes to all active release
>> branches
>>> (branch-1, branch-1.2, branch-1.1, etc)?
>>>=20
>>> Enis
>>>=20
>>>> On Tue, Sep 13, 2016 at 1:46 PM, Ted Yu <yuzhihong@gmail.com
>>> <javascript:;>> wrote:
>>>=20
>>>> Interesting.
>>>>=20
>>>> I can try to write a script which:
>>>> given JIRA number (e.g. 16491), emits HBASE-xyz Description (author)
>>>>=20
>>>> The output can then be copy-pasted in commit.
>>>>=20
>>>> Cheers
>>>>=20
>>>> On Tue, Sep 13, 2016 at 12:57 PM, Jerry He <jerryjch@gmail.com
>> <javascript:;>> wrote:
>>>>=20
>>>>> I have made similar mistakes on the commit messages previously, (and
>>>> people
>>>>> here on this thread had kindly reminded me on the JIRA before).
>>>>> I was wondering if some automatic enforcement could be set up, on the
>>>>> server side, or on the client side.
>>>>>=20
>>>>> On Tue, Sep 13, 2016 at 11:18 AM, Andrew Purtell <
>> apurtell@apache.org <javascript:;>>
>>>>> wrote:
>>>>>=20
>>>>>> Big +1
>>>>>>=20
>>>>>> JIRA identifiers in commit issues must be mandatory.
>>>>>>=20
>>>>>> Occasionally a committer makes a mistake. We're human. Simply
>> revert
>>>> and
>>>>>> push up a fixed commit.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> On Tue, Sep 13, 2016 at 10:16 AM, Sean Busbey <busbey@cloudera.com
>> <javascript:;>>
>>>>> wrote:
>>>>>>=20
>>>>>>> On Tue, Sep 13, 2016 at 10:00 AM, Gary Helmling <
>>> ghelmling@gmail.com <javascript:;>
>>>>>=20
>>>>>>> wrote:
>>>>>>>>=20
>>>>>>>>> To fix erroneous commit messages, please revert the offending
>>>>> commits
>>>>>>>>> and then reapply them with a correct commit message.
>>>>>>>> Honestly, I don't see the point of this.  In this case the
>>> original
>>>>>>> commit
>>>>>>>> is still there, so nothing is really fixed.  Instead we wind up
>>>> with
>>>>> 3
>>>>>>>> commits muddying up the change history for the affected files.
>>>>>>>>=20
>>>>>>>> I would much rather preserve a clean change history at the cost
>>> of
>>>> a
>>>>>> few
>>>>>>>> bad commit messages.  I don't think it's really that big a
>> deal.
>>>>>>>=20
>>>>>>> We rely on the commit messages in git for both authorship and as
>> a
>>>>>>> sanity check against the information in JIRA. It may not seem
>> like
>>> a
>>>>>>> big deal in the small when one of these is missing, but it adds
>> up
>>> to
>>>>>>> making more work for folks who are trying to do necessary and
>>> already
>>>>>>> unpopular tasks.
>>>>>>>=20
>>>>>>> The authorship information is mostly a nice-to-have for checking
>> on
>>>>>>> activity levels in the project. As a PMC member that information
>> is
>>>>>>> important to me. I can get it from JIRA as well, but that's more
>>>> work.
>>>>>>>=20
>>>>>>> The JIRA key in the commit message is a key part of how we do
>>> sanity
>>>>>>> checks on the information in JIRA come release time. Please make
>>> sure
>>>>>>> you correct erroneous commits that miss it or use the wrong JIRA
>>> key.
>>>>>>> Otherwise you put a bunch more work on folks doing RM duty (or
>>>> atleast
>>>>>>> me when I do RM duty), because we have to do a lot more to track
>>> down
>>>>>>> what's going on when JIRA says an issue is fixed but git doesn't
>>>> agree
>>>>>>> (or vice versa).
>>>>>>>=20
>>>>>>>=20
>>>>>>> --
>>>>>>> busbey
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> --
>>>>>> Best regards,
>>>>>>=20
>>>>>>   - Andy
>>>>>>=20
>>>>>> Problems worthy of attack prove their worth by hitting back. - Piet
>>>> Hein
>>>>>> (via Tom White)
>>=20