Just found this: Keep my email address private
We will use *psudae...@users.noreply.github.com <psudae...@users.noreply.github.com>* when performing web-based Git operations and sending email on your behalf. If you want command line Git operations to use your private email you must set your email in Git <https://help.github.com/articles/setting-your-email-in-git>. On Fri, Apr 15, 2016 at 11:43 AM Leif Hedstrom <zw...@apache.org> wrote: > > > On Apr 15, 2016, at 11:22 AM, James Peach <jpe...@apache.org> wrote: > > > > > >> On Apr 15, 2016, at 10:09 AM, Leif Hedstrom <zw...@apache.org> wrote: > >> > >> > >>> On Apr 15, 2016, at 9:34 AM, Brian Geffon <bri...@apache.org> wrote: > >>> > >>> I'm not thrilled with it either. I agree that the email addresses are > >>> definitely not desireable, also I don't like how it also produces a > merge > >>> commit. > >> > >> > >> I can deal with the merge commit, but the email addressing issues are > not cool. We should come with an agreement on this, such that the workflow > is well defined. > > > > How about a merge/integrate script for PRs, so that committers can > review and test before pushing to master? It gives me the winkies to merge > code to master that hasn't run through regression testing ... > > > > Sure, but what would the script do other than just “git merge” of the PR? > Fwiw, I fully expect everyone (or at least committers) to have run code > through both regressions and clang-format before pushing the PR :). > > I think for now, as Phil suggested, we should keep merging like we used > to, manually git merge the PRs etc. and push that way. > > Cheers, > > - leif > >
