On Tue, 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 > > 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 <[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) > > > > > > > > > > > > > > > > > > > > >
