If you've ever gotten stuck on a bare "200 OK" page when trying to sign in — particularly in mobile browsers — the issue should be fixed now. I've made the process more robust and implemented a fallback onto a redirect-based method if the popup window approach doesn't complete for any reason.
More robust logins
Copy head branch name
A teeny-tiny new feature while I keep plugging away at the rewrite: there's a small button in the Changes box to copy the PR's head (source) branch name. This can be useful if you want to check out the branch from the repo, and if you do it often there's also a new
copyHeadBranch() command for binding a keyboard shortcut.
Reviewable now respects the
diff settings in your
.gitattributes files. For example, to disable diffs for any files in the
vendor directory and use PHP higlighting for all
.phpt files, you could put a
.gitattributes file like this in the root of your repo:
/vendor/** -diff *.phpt diff=php
For details on the file's syntax please refer to the git docs on the topic.
Designated badge comment author
For those of you who switched badge placement from PR descriptions to comments, you may be glad to know that you can now designate a specific account to create these comments.
This can be useful if you'd rather have a dedicated "bot" account that won't mind getting spammed by notifications from each and every PR.
A quick survey
We're looking over the upcoming priorities for Reviewable and want to know what you think. Please help out by answering an ultra-quick 5 question feedback survey.
Reviewable badge placement
By popular demand, you can now have the "This change is " badge appear in a comment rather than in the PR's description. The new option appears in repository settings:
On the upside, switching to in-comment badges means that Reviewable will never accidentally clobber your PR description edits, and you'll get a notification with a link directly to the review. On the downside, the badge will no longer always appear in a predictable spot in the PR (especially for backfills), and the comments will impersonate repo admins (often but not always the user who connected the repo). Your call!
Note that PRs that already have the badge in the description will not have it moved to a comment to avoid spamming notifications.
You can now also turn off badges altogether in private repos — this used to be a hidden flag.
Performance improvement plan
TL;DR: I'll be focusing on improving Reviewable's performance for the next little while. If you're interested in the technical details, I wrote a blog post about it.
Rebase & merge
You can now rebase and merge a branch in Reviewable just like in GitHub, as long as there are no conflicts:
This supersedes the previous "fast forward" option, though Reviewable will still indicate to you whether the rebase would, in fact, be a no-op.
Also, control over what merge styles are available in your repo is now fully ceded to GitHub since they've made the flags available via the API.
I've tweaked who sees a discussion as "unreplied" to improve workflows and ensure a discussion is always red for someone:
1. If a discussion was initiated by somebody other than the PR author, and there's only one active participant, then the PR author will always see it as unreplied until they or somebody else join the discussion. This is so even if the PR author has acknowledged the discussion.
2. If a discussion is unresolved with at least two active participants, and everybody has acknowledged the last comment, then all participants who are blocking resolution will see the discussion as unreplied.
Let me know if you run into any corner cases I failed to consider!
Connection load balancing
If you connected a busy repo to Reviewable, you may have run into a situation where it used up all your GitHub API quota and both you and the repo connection were stuck until it replenished. As of a couple weeks ago this should no longer happen! Reviewable will now try to avoid using more than 80% of your hourly quota, and automatically switch to using the credentials of other repo admins (who have signed in to the app) when your quota is getting low.
I'm still tweaking the algorithm for corner cases and to account for GitHub's undocumented burst quota limits, so you may get occasional spurious warnings about event processing being delayed but overall things should be much better. Don't hesitate to get in touch if you have any questions, though!
No published changelogs yet.
Surely Reviewable will start publishing changelogs very soon.
Check out our other public changelogs: Buffer, Mention, Respond by Buffer, JSFiddle, Olark, Droplr, Piwik Pro, Prott, Ustream, ViralSweep, StartupThreads, Userlike, Unixstickers, Survicate, Envoy, Gmelius, CodeTree