You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by Duo Zhang <zh...@apache.org> on 2016/09/13 01:24:33 UTC
Consider adding the issue number in commit message
https://github.com/apache/hbase/commit/1cdc5acfd456688f106287c19ae9af62fd03a3af
I can not find the related issue of this commit...
Thanks.
Re: Consider adding the issue number in commit message
Posted by Ted Yu <yu...@gmail.com>.
Clearly documented:
http://hbase.apache.org/book.html#hbase.commit.msg.format
On Tue, Sep 13, 2016 at 4:05 PM, Andrew Purtell <an...@gmail.com>
wrote:
> I believe we have the commit format documented in our online book. If not,
> lets.
>
> > On Sep 13, 2016, at 2:30 PM, Xi Yang <al...@gmail.com> wrote:
> >
> > +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
> we
> > don't need to say any other words except Jira issue number and the title.
> >
> > The whole commitment message should be "HBASE-<number> xxxxxxxxx"
> >
> > That will make our got history looks clear
> >
> > Thanks
> > Alex
> >
> >> On Tuesday, 13 September 2016, Dima Spivak <di...@apache.org>
> wrote:
> >>
> >> +1 to that, Enis.
> >>
> >> -Dima
> >>
> >> On Tue, Sep 13, 2016 at 2:15 PM, Enis Söztutar <enis@apache.org
> >> <javascript:;>> wrote:
> >>
> >>> +1 on not force pushing. The git repo is sync'ed to multiple places
> (like
> >>> github, etc) so force pushes should be avoided unless a feature branch.
> >>>
> >>> Should we extend the list of no-force-pushes to all active release
> >> branches
> >>> (branch-1, branch-1.2, branch-1.1, etc)?
> >>>
> >>> Enis
> >>>
> >>>> On Tue, Sep 13, 2016 at 1:46 PM, Ted Yu <yuzhihong@gmail.com
> >>> <javascript:;>> wrote:
> >>>
> >>>> Interesting.
> >>>>
> >>>> I can try to write a script which:
> >>>> given JIRA number (e.g. 16491), emits HBASE-xyz Description (author)
> >>>>
> >>>> The output can then be copy-pasted in commit.
> >>>>
> >>>> Cheers
> >>>>
> >>>> On Tue, Sep 13, 2016 at 12:57 PM, Jerry He <jerryjch@gmail.com
> >> <javascript:;>> wrote:
> >>>>
> >>>>> 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.
> >>>>>
> >>>>> On Tue, Sep 13, 2016 at 11:18 AM, Andrew Purtell <
> >> apurtell@apache.org <javascript:;>>
> >>>>> wrote:
> >>>>>
> >>>>>> Big +1
> >>>>>>
> >>>>>> JIRA identifiers in commit issues must be mandatory.
> >>>>>>
> >>>>>> Occasionally a committer makes a mistake. We're human. Simply
> >> revert
> >>>> and
> >>>>>> push up a fixed commit.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Tue, Sep 13, 2016 at 10:16 AM, Sean Busbey <busbey@cloudera.com
> >> <javascript:;>>
> >>>>> wrote:
> >>>>>>
> >>>>>>> On Tue, Sep 13, 2016 at 10:00 AM, Gary Helmling <
> >>> ghelmling@gmail.com <javascript:;>
> >>>>>
> >>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> 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.
> >>>>>>>>
> >>>>>>>> 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.
> >>>>>>>
> >>>>>>> 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.
> >>>>>>>
> >>>>>>> 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.
> >>>>>>>
> >>>>>>> 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).
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> busbey
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Best regards,
> >>>>>>
> >>>>>> - Andy
> >>>>>>
> >>>>>> Problems worthy of attack prove their worth by hitting back. - Piet
> >>>> Hein
> >>>>>> (via Tom White)
> >>
>
Re: Consider adding the issue number in commit message
Posted by Andrew Purtell <an...@gmail.com>.
I believe we have the commit format documented in our online book. If not, lets.
> On Sep 13, 2016, at 2:30 PM, Xi Yang <al...@gmail.com> wrote:
>
> +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 we
> don't need to say any other words except Jira issue number and the title.
>
> The whole commitment message should be "HBASE-<number> xxxxxxxxx"
>
> That will make our got history looks clear
>
> Thanks
> Alex
>
>> On Tuesday, 13 September 2016, Dima Spivak <di...@apache.org> wrote:
>>
>> +1 to that, Enis.
>>
>> -Dima
>>
>> On Tue, Sep 13, 2016 at 2:15 PM, Enis Söztutar <enis@apache.org
>> <javascript:;>> wrote:
>>
>>> +1 on not force pushing. The git repo is sync'ed to multiple places (like
>>> github, etc) so force pushes should be avoided unless a feature branch.
>>>
>>> Should we extend the list of no-force-pushes to all active release
>> branches
>>> (branch-1, branch-1.2, branch-1.1, etc)?
>>>
>>> Enis
>>>
>>>> On Tue, Sep 13, 2016 at 1:46 PM, Ted Yu <yuzhihong@gmail.com
>>> <javascript:;>> wrote:
>>>
>>>> Interesting.
>>>>
>>>> I can try to write a script which:
>>>> given JIRA number (e.g. 16491), emits HBASE-xyz Description (author)
>>>>
>>>> The output can then be copy-pasted in commit.
>>>>
>>>> Cheers
>>>>
>>>> On Tue, Sep 13, 2016 at 12:57 PM, Jerry He <jerryjch@gmail.com
>> <javascript:;>> wrote:
>>>>
>>>>> 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.
>>>>>
>>>>> On Tue, Sep 13, 2016 at 11:18 AM, Andrew Purtell <
>> apurtell@apache.org <javascript:;>>
>>>>> wrote:
>>>>>
>>>>>> Big +1
>>>>>>
>>>>>> JIRA identifiers in commit issues must be mandatory.
>>>>>>
>>>>>> Occasionally a committer makes a mistake. We're human. Simply
>> revert
>>>> and
>>>>>> push up a fixed commit.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Sep 13, 2016 at 10:16 AM, Sean Busbey <busbey@cloudera.com
>> <javascript:;>>
>>>>> wrote:
>>>>>>
>>>>>>> On Tue, Sep 13, 2016 at 10:00 AM, Gary Helmling <
>>> ghelmling@gmail.com <javascript:;>
>>>>>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>
>>>>>>>> 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.
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> 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).
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> busbey
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Best regards,
>>>>>>
>>>>>> - Andy
>>>>>>
>>>>>> Problems worthy of attack prove their worth by hitting back. - Piet
>>>> Hein
>>>>>> (via Tom White)
>>
Re: Consider adding the issue number in commit message
Posted by Stack <st...@duboce.net>.
On Wed, Sep 14, 2016 at 10:05 AM, Stack <st...@duboce.net> wrote:
> On Tue, Sep 13, 2016 at 2:30 PM, Xi Yang <al...@gmail.com> wrote:
>
> Let me update the refguide with our agreement here on no forced-pushes to
> any branch. I thought it in the guide already but it is not.
>
>
There is this: http://hbase.apache.org/book.html#git.best.practices It
needs a tuneup?
St.Ack
>
>
>> Thanks
>> Alex
>>
>> On Tuesday, 13 September 2016, Dima Spivak <di...@apache.org> wrote:
>>
>> > +1 to that, Enis.
>> >
>> > -Dima
>> >
>> > On Tue, Sep 13, 2016 at 2:15 PM, Enis Söztutar <enis@apache.org
>> > <javascript:;>> wrote:
>> >
>> > > +1 on not force pushing. The git repo is sync'ed to multiple places
>> (like
>> > > github, etc) so force pushes should be avoided unless a feature
>> branch.
>> > >
>> > > Should we extend the list of no-force-pushes to all active release
>> > branches
>> > > (branch-1, branch-1.2, branch-1.1, etc)?
>> > >
>> > > Enis
>> > >
>> > > On Tue, Sep 13, 2016 at 1:46 PM, Ted Yu <yuzhihong@gmail.com
>> > <javascript:;>> wrote:
>> > >
>> > > > Interesting.
>> > > >
>> > > > I can try to write a script which:
>> > > > given JIRA number (e.g. 16491), emits HBASE-xyz Description (author)
>> > > >
>> > > > The output can then be copy-pasted in commit.
>> > > >
>> > > > Cheers
>> > > >
>> > > > On Tue, Sep 13, 2016 at 12:57 PM, Jerry He <jerryjch@gmail.com
>> > <javascript:;>> wrote:
>> > > >
>> > > > > 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.
>> > > > >
>> > > > > On Tue, Sep 13, 2016 at 11:18 AM, Andrew Purtell <
>> > apurtell@apache.org <javascript:;>>
>> > > > > wrote:
>> > > > >
>> > > > > > Big +1
>> > > > > >
>> > > > > > JIRA identifiers in commit issues must be mandatory.
>> > > > > >
>> > > > > > Occasionally a committer makes a mistake. We're human. Simply
>> > revert
>> > > > and
>> > > > > > push up a fixed commit.
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > On Tue, Sep 13, 2016 at 10:16 AM, Sean Busbey <
>> busbey@cloudera.com
>> > <javascript:;>>
>> > > > > wrote:
>> > > > > >
>> > > > > > > On Tue, Sep 13, 2016 at 10:00 AM, Gary Helmling <
>> > > ghelmling@gmail.com <javascript:;>
>> > > > >
>> > > > > > > wrote:
>> > > > > > > >
>> > > > > > > >> 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.
>> > > > > > > >
>> > > > > > > > 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.
>> > > > > > >
>> > > > > > > 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.
>> > > > > > >
>> > > > > > > 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.
>> > > > > > >
>> > > > > > > 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).
>> > > > > > >
>> > > > > > >
>> > > > > > > --
>> > > > > > > busbey
>> > > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > --
>> > > > > > Best regards,
>> > > > > >
>> > > > > > - Andy
>> > > > > >
>> > > > > > Problems worthy of attack prove their worth by hitting back. -
>> Piet
>> > > > Hein
>> > > > > > (via Tom White)
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
>
Re: Consider adding the issue number in commit message
Posted by Stack <st...@duboce.net>.
On Tue, Sep 13, 2016 at 2:30 PM, Xi Yang <al...@gmail.com> wrote:
> +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 we
> don't need to say any other words except Jira issue number and the title.
>
> The whole commitment message should be "HBASE-<number> xxxxxxxxx"
>
> That will make our got history looks clear
>
>
You bring up an interesting item Xi Yang.
Commit messages that have just 'HBASE-XXXX <Subject>' are not enough IMO.
The patch for sure should start with this one-liner -- for all the reasons
given above -- but it should be followed by a succinct description of what
the patch does. Going to JIRAs that are often pages long w/ a back and
forth on how a fix should be done are a time-consuming parse and in the
end, may have little relation to what is actually committed. Better
all-around -- from forcing the contributor to gather their thoughts to make
a terse summary, to the downstreamer backporting trying to make an
assessment on whether a patch important or not -- that we do like any other
project of substance and take the time to do decent, descriptive commit
messages.
Let me update the refguide with our agreement here on no forced-pushes to
any branch. I thought it in the guide already but it is not.
On writing scripts to check the format of commits, we already have a very
fine one. See ./dev-support/submit-patch.py All should be using it, at
least all committers (contributors have the excuse that they don't know of
it). Not only does this script save the contributor time, because it does
git format-patch auto-adding the jira subject and id as well as
auto-posting review board, it makes the committers life easier too as they
can just git am the patch if all looks good (and it will includes, whole,
any commit message a dev might have written up too).
St.Ack
> Thanks
> Alex
>
> On Tuesday, 13 September 2016, Dima Spivak <di...@apache.org> wrote:
>
> > +1 to that, Enis.
> >
> > -Dima
> >
> > On Tue, Sep 13, 2016 at 2:15 PM, Enis Söztutar <enis@apache.org
> > <javascript:;>> wrote:
> >
> > > +1 on not force pushing. The git repo is sync'ed to multiple places
> (like
> > > github, etc) so force pushes should be avoided unless a feature branch.
> > >
> > > Should we extend the list of no-force-pushes to all active release
> > branches
> > > (branch-1, branch-1.2, branch-1.1, etc)?
> > >
> > > Enis
> > >
> > > On Tue, Sep 13, 2016 at 1:46 PM, Ted Yu <yuzhihong@gmail.com
> > <javascript:;>> wrote:
> > >
> > > > Interesting.
> > > >
> > > > I can try to write a script which:
> > > > given JIRA number (e.g. 16491), emits HBASE-xyz Description (author)
> > > >
> > > > The output can then be copy-pasted in commit.
> > > >
> > > > Cheers
> > > >
> > > > On Tue, Sep 13, 2016 at 12:57 PM, Jerry He <jerryjch@gmail.com
> > <javascript:;>> wrote:
> > > >
> > > > > 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.
> > > > >
> > > > > On Tue, Sep 13, 2016 at 11:18 AM, Andrew Purtell <
> > apurtell@apache.org <javascript:;>>
> > > > > wrote:
> > > > >
> > > > > > Big +1
> > > > > >
> > > > > > JIRA identifiers in commit issues must be mandatory.
> > > > > >
> > > > > > Occasionally a committer makes a mistake. We're human. Simply
> > revert
> > > > and
> > > > > > push up a fixed commit.
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Tue, Sep 13, 2016 at 10:16 AM, Sean Busbey <
> busbey@cloudera.com
> > <javascript:;>>
> > > > > wrote:
> > > > > >
> > > > > > > On Tue, Sep 13, 2016 at 10:00 AM, Gary Helmling <
> > > ghelmling@gmail.com <javascript:;>
> > > > >
> > > > > > > wrote:
> > > > > > > >
> > > > > > > >> 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.
> > > > > > > >
> > > > > > > > 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.
> > > > > > >
> > > > > > > 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.
> > > > > > >
> > > > > > > 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.
> > > > > > >
> > > > > > > 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).
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > busbey
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Best regards,
> > > > > >
> > > > > > - Andy
> > > > > >
> > > > > > Problems worthy of attack prove their worth by hitting back. -
> Piet
> > > > Hein
> > > > > > (via Tom White)
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Consider adding the issue number in commit message
Posted by Xi Yang <al...@gmail.com>.
+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 we
don't need to say any other words except Jira issue number and the title.
The whole commitment message should be "HBASE-<number> xxxxxxxxx"
That will make our got history looks clear
Thanks
Alex
On Tuesday, 13 September 2016, Dima Spivak <di...@apache.org> wrote:
> +1 to that, Enis.
>
> -Dima
>
> On Tue, Sep 13, 2016 at 2:15 PM, Enis Söztutar <enis@apache.org
> <javascript:;>> wrote:
>
> > +1 on not force pushing. The git repo is sync'ed to multiple places (like
> > github, etc) so force pushes should be avoided unless a feature branch.
> >
> > Should we extend the list of no-force-pushes to all active release
> branches
> > (branch-1, branch-1.2, branch-1.1, etc)?
> >
> > Enis
> >
> > On Tue, Sep 13, 2016 at 1:46 PM, Ted Yu <yuzhihong@gmail.com
> <javascript:;>> wrote:
> >
> > > Interesting.
> > >
> > > I can try to write a script which:
> > > given JIRA number (e.g. 16491), emits HBASE-xyz Description (author)
> > >
> > > The output can then be copy-pasted in commit.
> > >
> > > Cheers
> > >
> > > On Tue, Sep 13, 2016 at 12:57 PM, Jerry He <jerryjch@gmail.com
> <javascript:;>> wrote:
> > >
> > > > 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.
> > > >
> > > > On Tue, Sep 13, 2016 at 11:18 AM, Andrew Purtell <
> apurtell@apache.org <javascript:;>>
> > > > wrote:
> > > >
> > > > > Big +1
> > > > >
> > > > > JIRA identifiers in commit issues must be mandatory.
> > > > >
> > > > > Occasionally a committer makes a mistake. We're human. Simply
> revert
> > > and
> > > > > push up a fixed commit.
> > > > >
> > > > >
> > > > >
> > > > > On Tue, Sep 13, 2016 at 10:16 AM, Sean Busbey <busbey@cloudera.com
> <javascript:;>>
> > > > wrote:
> > > > >
> > > > > > On Tue, Sep 13, 2016 at 10:00 AM, Gary Helmling <
> > ghelmling@gmail.com <javascript:;>
> > > >
> > > > > > wrote:
> > > > > > >
> > > > > > >> 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.
> > > > > > >
> > > > > > > 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.
> > > > > >
> > > > > > 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.
> > > > > >
> > > > > > 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.
> > > > > >
> > > > > > 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).
> > > > > >
> > > > > >
> > > > > > --
> > > > > > busbey
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best regards,
> > > > >
> > > > > - Andy
> > > > >
> > > > > Problems worthy of attack prove their worth by hitting back. - Piet
> > > Hein
> > > > > (via Tom White)
> > > > >
> > > >
> > >
> >
>
Re: Consider adding the issue number in commit message
Posted by Dima Spivak <di...@apache.org>.
+1 to that, Enis.
-Dima
On Tue, Sep 13, 2016 at 2:15 PM, Enis Söztutar <en...@apache.org> wrote:
> +1 on not force pushing. The git repo is sync'ed to multiple places (like
> github, etc) so force pushes should be avoided unless a feature branch.
>
> Should we extend the list of no-force-pushes to all active release branches
> (branch-1, branch-1.2, branch-1.1, etc)?
>
> Enis
>
> On Tue, Sep 13, 2016 at 1:46 PM, Ted Yu <yu...@gmail.com> wrote:
>
> > Interesting.
> >
> > I can try to write a script which:
> > given JIRA number (e.g. 16491), emits HBASE-xyz Description (author)
> >
> > The output can then be copy-pasted in commit.
> >
> > Cheers
> >
> > On Tue, Sep 13, 2016 at 12:57 PM, Jerry He <je...@gmail.com> wrote:
> >
> > > 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.
> > >
> > > On Tue, Sep 13, 2016 at 11:18 AM, Andrew Purtell <ap...@apache.org>
> > > wrote:
> > >
> > > > Big +1
> > > >
> > > > JIRA identifiers in commit issues must be mandatory.
> > > >
> > > > Occasionally a committer makes a mistake. We're human. Simply revert
> > and
> > > > push up a fixed commit.
> > > >
> > > >
> > > >
> > > > On Tue, Sep 13, 2016 at 10:16 AM, Sean Busbey <bu...@cloudera.com>
> > > wrote:
> > > >
> > > > > On Tue, Sep 13, 2016 at 10:00 AM, Gary Helmling <
> ghelmling@gmail.com
> > >
> > > > > wrote:
> > > > > >
> > > > > >> 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.
> > > > > >
> > > > > > 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.
> > > > >
> > > > > 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.
> > > > >
> > > > > 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.
> > > > >
> > > > > 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).
> > > > >
> > > > >
> > > > > --
> > > > > busbey
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Best regards,
> > > >
> > > > - Andy
> > > >
> > > > Problems worthy of attack prove their worth by hitting back. - Piet
> > Hein
> > > > (via Tom White)
> > > >
> > >
> >
>
Re: Consider adding the issue number in commit message
Posted by Enis Söztutar <en...@apache.org>.
+1 on not force pushing. The git repo is sync'ed to multiple places (like
github, etc) so force pushes should be avoided unless a feature branch.
Should we extend the list of no-force-pushes to all active release branches
(branch-1, branch-1.2, branch-1.1, etc)?
Enis
On Tue, Sep 13, 2016 at 1:46 PM, Ted Yu <yu...@gmail.com> wrote:
> Interesting.
>
> I can try to write a script which:
> given JIRA number (e.g. 16491), emits HBASE-xyz Description (author)
>
> The output can then be copy-pasted in commit.
>
> Cheers
>
> On Tue, Sep 13, 2016 at 12:57 PM, Jerry He <je...@gmail.com> wrote:
>
> > 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.
> >
> > On Tue, Sep 13, 2016 at 11:18 AM, Andrew Purtell <ap...@apache.org>
> > wrote:
> >
> > > Big +1
> > >
> > > JIRA identifiers in commit issues must be mandatory.
> > >
> > > Occasionally a committer makes a mistake. We're human. Simply revert
> and
> > > push up a fixed commit.
> > >
> > >
> > >
> > > On Tue, Sep 13, 2016 at 10:16 AM, Sean Busbey <bu...@cloudera.com>
> > wrote:
> > >
> > > > On Tue, Sep 13, 2016 at 10:00 AM, Gary Helmling <ghelmling@gmail.com
> >
> > > > wrote:
> > > > >
> > > > >> 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.
> > > > >
> > > > > 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.
> > > >
> > > > 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.
> > > >
> > > > 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.
> > > >
> > > > 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).
> > > >
> > > >
> > > > --
> > > > busbey
> > > >
> > >
> > >
> > >
> > > --
> > > Best regards,
> > >
> > > - Andy
> > >
> > > Problems worthy of attack prove their worth by hitting back. - Piet
> Hein
> > > (via Tom White)
> > >
> >
>
Re: Consider adding the issue number in commit message
Posted by Ted Yu <yu...@gmail.com>.
Interesting.
I can try to write a script which:
given JIRA number (e.g. 16491), emits HBASE-xyz Description (author)
The output can then be copy-pasted in commit.
Cheers
On Tue, Sep 13, 2016 at 12:57 PM, Jerry He <je...@gmail.com> wrote:
> 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.
>
> On Tue, Sep 13, 2016 at 11:18 AM, Andrew Purtell <ap...@apache.org>
> wrote:
>
> > Big +1
> >
> > JIRA identifiers in commit issues must be mandatory.
> >
> > Occasionally a committer makes a mistake. We're human. Simply revert and
> > push up a fixed commit.
> >
> >
> >
> > On Tue, Sep 13, 2016 at 10:16 AM, Sean Busbey <bu...@cloudera.com>
> wrote:
> >
> > > On Tue, Sep 13, 2016 at 10:00 AM, Gary Helmling <gh...@gmail.com>
> > > wrote:
> > > >
> > > >> 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.
> > > >
> > > > 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.
> > >
> > > 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.
> > >
> > > 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.
> > >
> > > 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).
> > >
> > >
> > > --
> > > busbey
> > >
> >
> >
> >
> > --
> > Best regards,
> >
> > - Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
> >
>
Re: Consider adding the issue number in commit message
Posted by Jerry He <je...@gmail.com>.
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.
On Tue, Sep 13, 2016 at 11:18 AM, Andrew Purtell <ap...@apache.org>
wrote:
> Big +1
>
> JIRA identifiers in commit issues must be mandatory.
>
> Occasionally a committer makes a mistake. We're human. Simply revert and
> push up a fixed commit.
>
>
>
> On Tue, Sep 13, 2016 at 10:16 AM, Sean Busbey <bu...@cloudera.com> wrote:
>
> > On Tue, Sep 13, 2016 at 10:00 AM, Gary Helmling <gh...@gmail.com>
> > wrote:
> > >
> > >> 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.
> > >
> > > 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.
> >
> > 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.
> >
> > 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.
> >
> > 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).
> >
> >
> > --
> > busbey
> >
>
>
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>
Re: Consider adding the issue number in commit message
Posted by Andrew Purtell <ap...@apache.org>.
Big +1
JIRA identifiers in commit issues must be mandatory.
Occasionally a committer makes a mistake. We're human. Simply revert and
push up a fixed commit.
On Tue, Sep 13, 2016 at 10:16 AM, Sean Busbey <bu...@cloudera.com> wrote:
> On Tue, Sep 13, 2016 at 10:00 AM, Gary Helmling <gh...@gmail.com>
> wrote:
> >
> >> 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.
> >
> > 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.
>
> 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.
>
> 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.
>
> 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).
>
>
> --
> busbey
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: Consider adding the issue number in commit message
Posted by Sean Busbey <bu...@cloudera.com>.
On Tue, Sep 13, 2016 at 10:00 AM, Gary Helmling <gh...@gmail.com> wrote:
>
>> 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.
>
> 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.
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.
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.
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).
--
busbey
Re: Consider adding the issue number in commit message
Posted by Ted Yu <yu...@gmail.com>.
bq. the original commit is still there, so nothing is really fixed.
Though 3 commits didn't look good, the contributor's identity would be
retrievable when looking at git history.
Consider this:
$ git blame
hbase-rsgroup/src/main/java/org/apache/hadoop/hbase/rsgroup/RSGroupInfoManagerImpl.java
| grep 'se.classification.InterfaceAud'
552400e5 (tedyu 2016-09-12 12:16:26 -0700 60) import
org.apache.hadoop.hbase.classification.InterfaceAudience;
552400e5 would lead to:
HBASE-16491 A few org.apache.hadoop.hbase.rsgroup classes missing
@InterfaceAudience annotation (Umesh Agashe)
The downside with force push is that everyone who had the corresponding
branch checked out needs to re-check out.
This morning I moved a few pending patches out of old work space for master
branch (not to lose them when I do rm -rf in the future) and cloned master
branch again.
My two cents.
On Tue, Sep 13, 2016 at 10:00 AM, Gary Helmling <gh...@gmail.com> wrote:
> >
> > Please never force push to any non-feature branch. I thought we had
> > protections to stop force pushes on master and
> > have filed INFRA-12602 to get them in place.
> >
> >
> Yeah, I shouldn't have done it. But I think the protection against force
> pushes only applies to the "rel/*" namespace.
>
>
> > 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.
>
> 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.
>
Re: Consider adding the issue number in commit message
Posted by Gary Helmling <gh...@gmail.com>.
>
> Please never force push to any non-feature branch. I thought we had
> protections to stop force pushes on master and
> have filed INFRA-12602 to get them in place.
>
>
Yeah, I shouldn't have done it. But I think the protection against force
pushes only applies to the "rel/*" namespace.
> 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.
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.
Re: Consider adding the issue number in commit message
Posted by Sean Busbey <bu...@cloudera.com>.
Please never force push to any non-feature branch. I thought we had
protections to stop force pushes on master and
have filed INFRA-12602 to get them in place.
To fix erroneous commit messages, please revert the offending commits
and then reapply them with a correct commit message.
You can see a recent example of this in master when Ted corrected
himself on missing the contributor for HBASE-16491.
On Tue, Sep 13, 2016 at 12:53 AM, Gary Helmling <gh...@gmail.com> wrote:
> Yes this is one commit message where the JIRA number was left off. I only
> noticed it was missing after I pushed to master. Mea culpa.
>
> I've rebased to amend the commit message and force pushed. However, there
> were two intervening commits in the meantime, which also got included in
> the rebase:
>
> commit 77b327320a72ca01b35f655c42f8c13f659dff31
> Author: anoopsamjohn <an...@gmail.com>
> Date: Tue Sep 13 11:43:26 2016 +0530
>
> HBASE-16229 Cleaning up size and heapSize calculation.
>
> commit 2566cfeb60de644f287ac192d360f3fc15376c8f
> Author: chenheng <ch...@apache.org>
> Date: Tue Sep 13 10:07:45 2016 +0800
>
> HBASE-16592 Unify Delete request with AP
>
>
> I like a clear commit history as much as anyone, but let's consider the
> consequences of "fixing" this. Unfortunately anyone who pulled master
> between the original commit and the fix may now need to re-checkout master
> to avoid divergent commits. In hindsight, I think the fix may create more
> pain than the original problem. My apologies if you have to re-checkout
> master as a result.
>
> Anoop and Heng, you will both likely fall into this camp. Again, my
> apologies.
>
> This reaffirms my prejudice against force pushing to shared branches.
>
>
> On Mon, Sep 12, 2016 at 6:24 PM Duo Zhang <zh...@apache.org> wrote:
>
>>
>> https://github.com/apache/hbase/commit/1cdc5acfd456688f106287c19ae9af62fd03a3af
>>
>> I can not find the related issue of this commit...
>>
>> Thanks.
>>
--
busbey
Re: Consider adding the issue number in commit message
Posted by Gary Helmling <gh...@gmail.com>.
Yes this is one commit message where the JIRA number was left off. I only
noticed it was missing after I pushed to master. Mea culpa.
I've rebased to amend the commit message and force pushed. However, there
were two intervening commits in the meantime, which also got included in
the rebase:
commit 77b327320a72ca01b35f655c42f8c13f659dff31
Author: anoopsamjohn <an...@gmail.com>
Date: Tue Sep 13 11:43:26 2016 +0530
HBASE-16229 Cleaning up size and heapSize calculation.
commit 2566cfeb60de644f287ac192d360f3fc15376c8f
Author: chenheng <ch...@apache.org>
Date: Tue Sep 13 10:07:45 2016 +0800
HBASE-16592 Unify Delete request with AP
I like a clear commit history as much as anyone, but let's consider the
consequences of "fixing" this. Unfortunately anyone who pulled master
between the original commit and the fix may now need to re-checkout master
to avoid divergent commits. In hindsight, I think the fix may create more
pain than the original problem. My apologies if you have to re-checkout
master as a result.
Anoop and Heng, you will both likely fall into this camp. Again, my
apologies.
This reaffirms my prejudice against force pushing to shared branches.
On Mon, Sep 12, 2016 at 6:24 PM Duo Zhang <zh...@apache.org> wrote:
>
> https://github.com/apache/hbase/commit/1cdc5acfd456688f106287c19ae9af62fd03a3af
>
> I can not find the related issue of this commit...
>
> Thanks.
>