Good point! Our commit workflow sidesteps the merge commit issue (we grab the patch from reviewboard and apply that to master in an atomic commit). I'm *hoping* at some point we can formalize these expectations with a hook on the git server.
-=Bill On Wed, Feb 5, 2014 at 11:12 AM, Henry Saputra <henry.sapu...@gmail.com>wrote: > Dont forget to use git rebase instead of git pull =) > > - Henry > > On Tue, Feb 4, 2014 at 1:53 PM, Bill Farner <wfar...@apache.org> wrote: > > First and foremost, please don't take committing on master lightly. > Every > > time you commit and push to master, i encourage you to triple-check your > > commit message, and run the build one last time. Remember, *once you've > > pushed to master, it's there forever*. > > > > Unfortunately we have some manual lint steps, which will hopefully be > > automated in the near future: > > > > - Wrap your commit message at 100 cols. > > > > - Remove any redundancy in the commit message (e.g. rbt pulls the summary > > and description, which often overlap) > > > > - Keep the commit message at a sane length. The "Testing Done" section > is > > rarely interesting, and should not include lengthy terminal output. > > > > > > Thanks! > > > > -=Bill >
