Sam, I agree we have to make some clean up and add some more rule. My comments inline
Thank you Enrico 2017-10-10 0:01 GMT+02:00 Sam Just <sj...@salesforce.com>: > Last thursday, we a had a short discussion about possibly changing the > merge process to allow unsquashed commits > I don't think is the best way. The history of a pull request may have several minor commits and IMO it is better to hide such conversation in the official git history of the project If we think that the resulting commit is too big maybe we should split the patch into smaller parts. | and the use of the github merge button. I don't like the GitHub button, it is easy to use it even with the smartphone and it is very dangerous ! I would like to disable it at all. I am actually running very well with the bk-merge-script as it does all the validation we want. The checks from jenkins/travis/coveralls.io...could be flaky and it would be very annoying to have to wait for a full green light for a pull request to be merged > One sticking point is that we'd like an automatic way > to enforce some commit message metadata requirements and formatting. > Using the script actually enforces this and make every step automatic and error prone. We can enhance it > > Git lets you define some hooks for validating commits and commit > messages locally, see > https://git-scm.com/book/gr/v2/Customizing-Git-Git-Hooks. > Specifically, you can define a commit-msg hook which gets to validate > the file containing the commit message before allowing the commit. I > think https://developer.github.com/webhooks/ can be leveraged to do > the same checks on a github PR prior to allowing the PR to be merged, > but haven't had time yet to figure out precisely how. > > -Sam >
