Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Email pull requests #284
In the Git for Windows project, our workflow is more mailing list-centric than in other projects, so we would really love to get mails whenever somebody issues a pull request or opens/modifies an issue.
So here is an attempt to support that: the Email service hook is augmented by the check boxes "Send pull requests" and "Send issues", for backwards-compatibility, they are unchecked by default.
Please let me know if I did something wrong; if things look good, we could enhance the mail body and probably it would also be a good idea to add handlers for issue_comments, commit_comments, gollum, download, fork and fork_apply.
I actually thought so, too. So I added such a user.
The big problem is that the password emails go to the same address. Big bummer, as the user needs sufficient permissions to wreak havoc.
Second problem is that the link sent with those notifications (as well as the reply-to address) know that the notification was sent to that user. As a consequence, every single reply is attributed to that user rather than the real author of the reply.
So while it is a cute idea, adding a dedicated user with the public mailing list's address is unfortunately not good enough...
I fear if you make them more mailing list friendly, then all the advantages for regular users will be gone. For example, it is a super-cool thing that you can reply to notifications and the replies are connected with your GitHub account (which might not know the mail address from which you reply).
Also: just adding an account to use it only for notifications (something that the GitHub API and the Service Hooks clearly were designed for) appears to me as the wrong thing. It would incur a serious technical debt to violate the separation of concerns so blatantly...
So I would like to ask you not to change the mails being sent to GitHub accounts. Pretty please. I really like them the way they are.
And if you don't want the Email Service Hook to be able to notify via mail of anything else than push events, please say so now. Because then I can avoid beating on a dead horse by pouring more time into the issue.
That last commit is not tested at all since I ran out of time budget for this issue. However, I did not want to leave it in an awkward state, in spite of the reluctance to tell me how to move forward.
In the meantime I made another solution and that's it for me. It is just a great pity that everybody and her dog has to make their own solutions for mailing out issues and pull requests. Whatever.
It has been pointed out to me that it is not obvious without context why I closed this pull request. After all, quite a number of people have indicated to me in private (and some even in public) that they would love to have the option of enabling an Email hook for reporting issues and pull requests in addition to pushes, without the need for an own, external server and a lot of configuration.
So here is my explanation of the context:
A couple of months ago, I asked a Hubbernaut who offered his help publicly for all issues relating to GitHub whether there was any chance to get what I need: email notifications about pull requests.
The following workarounds were suggested:
After implementing all that I was at my wits' end for a while.
Then I found out that github-services could handle more than just push events. I have to admit that I was pretty disappointed that I had to stumble upon this, instead of being pointed to it, after asking an insider to help me.
So I asked for help in the msysGit community (for which those notifications are intended) because I did not speak Ruby. To make it short: the users of Git for Windows are not known to volunteer much else than less-than-flattering comments and demands for others to scratch their itches. Certainly no programming for free, why should they do that?
I finally decided to learn enough Ruby to do it myself. It turned out to be an easier exercise than I hoped, Ruby is quite a nice language, although I am sure that there are enough issues with my coding that a Ruby expert could help me with.
In total, I had already invested a lot of time into investigating and trying to solve this issue. But that coding came along nicely, I even managed to write and run the corresponding tests to make sure that my changes were not completely wrong.
So I was happy: after such a lot of work -- only a small part of which being the thing I like most: coding -- I finally saw the end of the tunnel. I opened this pull request. Only a few more steps to go, and I would finally have what I need and could go back to fun stuff.
Just imagine how frustrating that first comment was: ''Not saying we won't accept this ...''. I am German, used to direct communication (which sometimes comes over as rude to non-Germans), so I had to learn quite a bit to be able to read between the lines when Americans try to tell me something politely and therefore phrase it much more positively than they mean it. Therefore my assumption might be wrong that nobody in GitHub was willing to 1) integrate my changes, or 2) work with me to improve my code so it could be merged. That was my interpretation, though.
In the end, I decided to avoid the Bus Stop problem and just write off the time I spent so far. I invested another 20+ hours (way less than I had spent before on this frustrating business) to write a .php script to subscribe to the events I so dearly want to be forwarded to the mailing list.
Now I have to abuse a server that was definitely not meant for that job. But at least it works. And after writing this comment, I will try not to waste any more of my time on this issue.
Do not get me wrong: I really, really, really like GitHub. That is the reason why the disappointment sits so deep.
Sorry, I hadn't seen @dscho reply until just now. I saw that the issue was closed and assumed a different solution was being pursued.
That was actually not a read between the lines type of statement at all. "Not saying we won't accept this" meant exactly that - I didn't want my comment to deter from pursuing the hook solution in this PR further. I was simply suggesting that trying an alternative approach may be a quicker solution for people that were trying to get something working here. While it's true that Americans sometimes try to soften communications, it's pretty rare that they mean the opposite of what is stated, especially in online communication.
I'm open to accepting a patch here. I certainly agree that some kind of ML friendly system for pull requests makes a lot of sense. If this diff is still in good shape, feel free to reopen. After a quick pass the only thing that seems to be missing is maybe options for whether messages should be sent for issues/PRs in addition to commits since I don't think everyone is going to want that behavior. I'm also curious how closely the PR messages mimic git-request-pull(1) format, which should probably be emulated as closely as possible.
That for sure is a job for the Github team.