I agree Allen. Sometimes the commit messages are more confusing than helpful. I agree with the approach of relaxing Pre-Commit to run on closed jiras.
If i am to understand the system correctly, there is currently a jenkins job which triggers the Pre-Commit job. Is the discussion here to make that more permissive, or is there a check in precomit.sh I have overlooked? Either way, I agree that relaxing Pre-commit is a good idea. And I can volunteer some time to help if a jira is filed. -Suraj Acharya On Mon, May 1, 2017 at 8:06 PM, Allen Wittenauer <[email protected]> wrote: > > > On May 1, 2017, at 4:47 PM, suraj acharya <[email protected]> wrote: > > > > One thing I can think of if the project is very good about entering the > > JIRA number in the commit is : > > * we take the JIRA number from the git log. > > FWIW: People typo these numbers or skip it all the time, even for > projects like Hadoop where that has been a key component of committing. > Before even writing RDM, this was going to be my first plan of attack. I > took a long, hard look at hadoop and other's commit logs and it was just > incredibly awful. Human nature just gets in the way here. > > ... and that's even before you get to the issues of "which commit > is the first commit to report?" (branch comparison doesn't work that well, > esp due to cherry-picking and branch merges, even in a normal repo. > Hadoop's is especially jacked since 2.x came from 0.23 and not trunk.) > > In a perfect world... no, wait... in a world where this data can > be corrected easily in case of mistakes: this would be the ideal solution. > However, git's model really only supports fail forward without forcing > everyone to resync their entire history. Better commit tooling would > probably help here, but that's likely a bigger uphill battle. > >
