Clearly documented: http://hbase.apache.org/book.html#hbase.commit.msg.format
On Tue, Sep 13, 2016 at 4:05 PM, Andrew Purtell <[email protected]> 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 <[email protected]> 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 <[email protected]> > wrote: > >> > >> +1 to that, Enis. > >> > >> -Dima > >> > >> On Tue, Sep 13, 2016 at 2:15 PM, Enis Söztutar <[email protected] > >> <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 <[email protected] > >>> <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 <[email protected] > >> <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 < > >> [email protected] <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 <[email protected] > >> <javascript:;>> > >>>>> wrote: > >>>>>> > >>>>>>> On Tue, Sep 13, 2016 at 10:00 AM, Gary Helmling < > >>> [email protected] <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) > >> >
