I am very well aware of that. Doesn’t change the usefulness of the feature or the fact it’s there by default and for some odd reason it was removed.
In which way is it important for the project what contributors do with branches on their forks?
What reason is there to remove it in the first place?
How is this option removed? I checked on a repo I owned and I can find it. Isn’t this just offered if the person who merges it also owns the fork the branch originates from?
Something I’ve noticed was that it’s not possible to add reviewers for a PR if you don’t have commit bits, e.g. if you’re submitting a first-time contribution.
According to the GitHub docs:
Note: Pull request authors can’t request reviews unless they are either a repository owner or collaborator with write access to the repository.
I can’t find any mention of a setting that would control this, but I thought it might be worth flagging.
Now that the fire hose has been turned on, has anyone identified good strategies for filtering email notifications? I see that the Pull Request Migration project acknowledges the need for a guide for filtering GitHub notifications, but that item is still marked as Todo and the linked issue sadly has nothing to say about it other than “GitHub sends out a lot of notifications” which, I suspect everyone agrees with.
I’ve been looking at email headers and there are some GitHub specific ones present; at least for emails I directly receive (these don’t seem to be present in emails that are sent to cfe-commits).
X-GitHub-Sender: <github-username>X-GitHub-Recipient: <github-username>X-GitHub-Reason: review_requested
Unfortunately, these don’t suffice for my purposes. What I need is a mechanism to prioritize notifications for:
- Issues where I’m specifically listed as a reviewer (by name, not due to being a member of, e.g.,
pr-subscribers-clang). - Comments where I’m specifically mentioned (by @<github-username>).
I use a threaded mail reader on multiple devices and rely on server-side filtering to direct incoming messages to dedicated folders (or /dev/null). My mail server is able to filter on message contents, but I don’t know if that is true in general (e.g., I think older versions of Exchange might not support that).
I’m going to experiment with message body filtering; it looks like it might be possible to catch initial review request notifications and explicit mentions by looking for the following text, but this still doesn’t suffice to filter all notifications for a PR that one is specifically assigned to.
- “requested review from @<github-username>”
- “@<github-username>”
What are others trying?
2 Likes
If we ever do get to a point where new comments on Phabricator will be blocked, we need some recommended practice for adding post-commit review comments on commits tied to Phabricator reviews.
Do people have any experience with commenting on commits (not PRs) on GItHub?
1 Like
You know, I forgot that was still possible. I was figuring, since I have my own fork anyway, the way to do a post-review commit was to create the PR as usual and then immediately merge it (ticking the box to bypass review). Then there’d always be a PR.
I wonder if email filtering tactics ought to be in its own thread, instead of here. This is already a very busy thread.
1 Like
I filter based on the CC field. For mentions there will be Mention <mention@noreply.github.com> or Team mention <team_mention@noreply.github.com> and for explicit review requests, there will be Review requested <review_requested@noreply.github.com>
2 Likes
Except that catches actions on items where you were mentioned in the past. It does not bug you only for new mentions.
1 Like
Unless I’m mistaken, Review requested <review_requested@noreply.github.com> doesn’t suffice to distinguish between being explicitly listed as a reviewer vs being a member of a review group like pr-subscribers-clang.
This should get better once we move to our new notification system, where you will get a team mention rather than a team review request on the PRs. See Changes to Pull Request Subscription System.
Yes, we have discussions in commits sometimes: [NFC][sanitizer] Add a few missed RTSanitizerCommonSymbolizerInternal · llvm/llvm-project@edb211c · GitHub
There you can also comment on a line of code as during PR review.
Do we know that commit author gets notifications from GitHub for these? I see that the comments did not explicitly @mention the author.
I’m seeing that also for comments by the author,.
I left a test comment in [Driver][AIX] Change UNSUPPORTED to XFAIL system-aix · llvm/llvm-project@6ace52e · GitHub.
I think how it works is that the value in the CC field is the reason why you are getting a notification, not what the current notification is. So if someone requests that you review a PR, you will see Review requested <review_requested@noreply.github.com> in the CC field in all subsequent notifications coming from that PR.
I got the notification. Seems the author@noreply.github.com cc can be used to filter for these (although it will also net activity for issues, etc. that one created).
@BradSmith : I just merged one of my PR and the UI offered me to delete the branch. So it seems enabled.
1 Like