Reviewable changes Reviewable changes

.gitattributes support


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.

What's unreplied?


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!

File tab layout fixes


I released two small bug fixes that, put together, should improve the usability of file tabs:

1. The maximum path width is now computed correctly, so you don't end up with needlessly wasted whitespace between the file path and the revision boxes.

2. If space allows, file paths are displayed in full, without eliding … marks.

BTW, plenty of bugs get fixed every week, but I only announce the ones that affect a large number of users. 😊

Changing the base branch


GitHub recently introduced the ability to change the base branch of a pull request, and now you can also do this directly from Reviewable:

While GitHub warns you that changing the base branch may cause commits and comments to disappear, the operation is perfectly safe in Reviewable — it's treated exactly the same way as a new commit in the base branch.

"Review each commit" improvements


If you use the "review each commit separately" style then I just made some minor but useful improvements to this workflow. First, the file matrix header now indicates which revisions/commits have been rebased away by crossing them out, and simplifies the rebasing arcs so they're always readable (if potentially less accurate):

Second, the algorithm that picks which diffs to review next now focuses only on current revisions and makes better use of the rebasing relationships by following them transitively. So whereas before you'd always be reviewing every commit, now you'll automatically skip over any that have already been rebased away.

There's almost certainly new corner cases in the updated algorithm, so please open issues if you spot anything wonky. Thanks!

Wrapped line styling


Wrapped lines are now indicated with a left margin bar instead of italics, which should be easier to notice and figure out:

I also fixed some bugs that occasionally caused lines to wrap one or two characters before the configured margin. Sorry about that — browser font metrics are tricky and buggy!

Publishing errors fixed


I recently rewrote some key pieces of code that implement the publishing process, so if you've seen errors like "draft deleted while rendering markdown", "comment changed while rendering markdown" or (more recently and cryptically), "set" or "maxretry", these should now be a thing of the past. The root cause was some buggy corner cases in Firebase transactions so I ended up redesigning the schema to make transactions unnecessary.

You may still get a "Markdown rendering throttled to avoid triggering burst quota limits on GitHub" error, but it should be even more rare now, and you can just hit Publish again to keep making progress — your comments should go out after 2 or 3 tries at most.

As always, please don't hesitate to file and issue if you run into any errors or weirdness!

Squashed and fast forward merges


You can now squash your pull request before merging and edit the merge commit message, bringing Reviewable back to parity with the GitHub UI. And by way of apology for how long you had to wait for this I also threw in support for fast forward merges!

If the pull request's branch is out of date you can now update it by merging the target branch into it from the checks dropdown.

Finally, you can limit the kinds of merges allowed in your repos via the repository settings panel. (Unfortunately, GitHub doesn't expose their own equivalent settings via the API.)

Repository settings


You can now access all repo settings through a single panel, by clicking on the repo's name on the Repositories page:

You can also apply settings to multiple repos at once, and set a "prototype" repo whose settings will be copied every time Reviewable detects a new repo in the organization:

This new panel unblocks a bunch of upcoming features that needed a spot to add a setting before I could introduce them!

Multiple assignees in GitHub


Setting multiple assignees will now also set them in GitHub, since they've added this feature. One consequence is that Reviewable also enforces GitHub's limit of 10 assignees.

Note that assignees for existing reviews will be synced to GitHub lazily, only if the review is loaded or some related event occurs.

Quick quote


You can now quickly quote some text when replying to a comment by selecting it before clicking in the reply box or hitting 'r' (just like on GitHub).

Note that if you quote anything in your comment the automatic previous comment quote won't be inserted into the message that goes to GitHub.

PR author as reviewer


A PR's author is treated differently from other users when it comes to selecting default diffs, counting unreviewed files, etc. However, if they mark at least one file as reviewed (even just draft), they'll start to be treated as a normal reviewer. I just fixed some bugs that prevented this from applying consistently, but please let me know if you spot other related issues!

More review completion customization


Custom review completion conditions can now individually override the reviewed state of each revision of every file, on top of the overall review status. By default, a file revision is considered reviewed if at least one person has marked it as so, but you're now able to customize it to require more marks, or marks from specific people, etc. For more details please see the updated FAQ entry.

Quoting code


Sometimes it's useful to quote some code in a comment to make it clear what you're referring to -- this can often substitute for attaching a comment to a range of lines. But big chunks of code can also make comments hard to read, so Reviewable will now automatically collapse any long quoted code blocks.

For the exact Markdown syntax for quoting code blocks, see the original feature request.  



To ease onboarding for members of organizations with a private repo subscription, Reviewable will now present a nice welcome dialog with a clear call to action when they sign in the first time:

Let me know if you'd be interested in being able to customize this for your organization!

Review waiting on...


A perennially popular question is "who is this review waiting on?" aka "why can't I merge already?!" Reviewable now gives you an answer:

Note that the list may not be complete or precise; e.g., in a new, unassigned review, there's no way to tell who you're waiting for, and in multi-party reviews one person taking action may render another person's participation moot. Still, it should give you a pretty good idea who to nag!

The list is also included in the pull request's code-review/reviewable status, which I've shortened to fit as much information as possible into the 50 (!) character limit.

Both the pending reviewers and short description properties can also be filled out by custom completion conditions. I've updated the examples to show you how they work, and also took this opportunity to bump the execution environment to NodeJS 4.3.x for some modern JavaScript action. Enjoy!

Navigate to first/last X


I added commands to navigate to the first/last unreviewed file, unresolved discussion, etc. They're not bound by default but you can assign your own keyboard shortcuts if you'd like to take advantage of them!

Comment intents


Today the default "discussing" disposition becomes more intuitive and powerful:

1. Comments sent by reviewers now default to being "not OK", so the reviewee can't simply acknowledge the discussion away.

2. You can start a comment with OK (or LGTM) to accept the outcome and (usually) resolve the discussion.

3. You can start a comment with FYI (or BTW) to avoid affecting a discussion's resolution state, e.g., to comment on a resolved discussion or make a comment that won't block merging.

This gives you direct control over your "OK / not OK" status and reduces the need to use the explicit "satisfied" and "blocking" dispositions, reserving them for exceptional circumstances.

Do you have ideas for other keywords or "discussion intents"? Send them my way!

Comment context


Comments sent from within Reviewable now automatically include some extra context: the three preceding lines of code for new discussions, or a quote of the previous message for responses. This should make comments a lot easier to interpret in GitHub and email.

Note that a quoted message will be included only if your response doesn't quote anything itself, and will show up collapsed.

As always, please let me know if anything is buggy or could be improved!

Merged PR review status


There was a bug in GitHub that often showed the wrong ("pending") status for the code review after a PR was merged, even if the review was complete. The awesome GitHub devs fixed it quickly once I figured out the problem was on their end, so the post-merge status will be correct now.

Reviews by email


Good news if you like to work from your inbox: emailed replies now work correctly with Reviewable! Specifically, if you reply to a multi-comment message, your reply will be split up and attached to the individual discussions instead of being treated as a single top-level blob. You can even acknowledge or set your disposition on a thread by including the appropriate keyword on a line by itself.

Additionally, label, milestone, and assignee directives (e.g., -label, +@username) now work for comments posted from GitHub or by email as well, so you don't need to open up Reviewable (or GitHub) to change your PR's metadata.

Here's to smoother workflows!

Permission errors, round two


I have once again dug into the seedy underbelly of the permission system and wrestled more race conditions and broken error handling routines into submission. (BTW, they only produced false negatives -- security was never at risk.) Hopefully bogus "permission denied" failures and hanging permission requests are a thing of the past now... But please report an issue if you're still seeing them!

Limit to connected repos


If you're listing PRs for repos to which you can push on your Reviews page, you can now limit it to just those repos that are connected to Reviewable:

This can be useful if you have a lot of watched or starred repos, and need to keep it that way, but still want to constrain which repos are polled for PRs on this page.

Empty default diffs


When you load a review, Reviewable picks some default diffs that it thinks you might be interested in seeing. Sometimes, this can result in no diffs showing at all, because you're the review's author or because all files have been reviewed (by someone) or there are no unresolved discussions. This can be confusing, especially to new users.

A few small changes should improve the situation:

First, if no files at all are showing, an information bubble in the file area explains why and offers a button that will show a full diff of all files.

Second, whenever you're looking at an empty diff of the latest revision, a small button in the Changes box will offer to show you the full review diff instead.

Finally, for multi-party reviews "Include changes in files previously reviewed only by others" will default to true, unless your personal setting (based implicitly on the last time you clicked the toggle) or the repo's (hidden!) setting says otherwise.

Publishing failures


I you've run into a "permission denied" error when trying to publish, then had it work a few hours or a day later, I think I've got it fixed. The problem was caused by future-dated commits that prevented any "older" comments from being published.

By the way, if you're wondering why there hasn't been much activity here recently: I've been hard at work on an on-premises version of Reviewable. It'll be done soon and I expect to return to a regular schedule of features and improvements.

Filtering reviews


You can now filter "My Reviews" more effectively: multiple space-separated terms are ANDed ("+mine +private", but also works for plain words), and you can OR special +terms by separating them with commas ("+mine,private").

The currently available +terms are:

  • +mine: reviews created by you or assigned to you
  • +red: reviews with red counters (i.e., waiting on your action)
  • +open, +merged, +closed: reviews in the given state
  • +public, +private: reviews in public or private repos

It's easy enough to add more, just ask!

Rebased commit tracking


To make it easier to review rebased PRs commit-by-commit, Reviewable will now attempt to match up rebased commits with their older counterparts. This will affect the revision pairs it diffs for you by default, and also displayed as a miniature graph above the file matrix:

The graph can get pretty tricky (and unreadable!) if you're doing complex fixups or squashes, but should remain straightforward in the common case of a non-interactive rebase onto the target branch. If you're combining commits in your reviews you likely won't see a graph at all, since rebased commits will automatically be squashed into a single revision.

Note that the commit matching is based simply on commit messages, so any edits will break it. I'm sure there's lots of other ways to break the algorithm and the mini graph too, so please open an issue if you run into trouble, and ideally include a screenshot of the graph (like above) and a pointer to the PR. Thanks!

Multiple assignees


You can now assign more than one person to a review!

Use the +@ and -@ directives in your comments to manage assignees. GitHub only supports one assignee so if you set two or more then Reviewable will list them in the PR's description instead and set GitHub's to one of them.

The default review completion condition ignores assignees (because teams use the feature for all kinds of things) but if you'd like you can set a custom condition that requires all assignees to mark the files as reviewed or LGTM the review. If you have an existing script that uses review.pullRequest.assignee, please update it to use the new review.pullRequest.assignees property instead.

Grouped reviews on dashboard


To help manage your reviews, the list will now be divided into sections: "Assigned to me", "Created by me", "Involving me", "Mentioning my team" and "Unrelated to me".

 The sorting order within each section remains by creation date and you can still filter the entire list instantaneously via the search box. Enjoy!

Looks Good To Me redux


Per a user's suggestion, you can now customize the LGTM button to reply with a repo-specific approving comment.

The field is in the same dialog as the condition customization code, accessible by repo admins through here:

Looks Good To Me


I added a small LGTM button to the top-level discussion's reply field, similar to the Done button that shows up for the PR author.

This can be a convenient way to indicate that you think the PR is good to merge, but you can also configure your repository to require such an approval to complete a review. This will be reflect in Reviewable's status checks on the PR and, in turn, you can configure GitHub to require successful checks before permitting a merge.

This has actually been possible for a few months now but I figured I'd publicize it a bit more! :-)

A week of fixes


Lots of small fixes this week, including:

  • Top-level comments (both in-app and from GitHub) will now snapshot provisional revisions.
  • LGTM emojis in code blocks won't be rendered or counted any more.
  • Bulk permissions will be rechecked when upgrading authorization scopes, fixing the "my toggles are disabled" issue for new users on the Repositories page.
  • It's no longer possible to make a trial cover the whole organization and never expire! I'll be sweeping existing trials for this issue soon. Oops.
  • Changelog UI cleanup with hacks galore.
  • Forced confirmation before leaving review page when sending comments.
  • Protection against crashes in edge cases (e.g., navigation while request in progress, review with no files).
  • Layout fixes for small screens, weird z-index issues with menus.

Undo 'mark all files as reviewed'


If you marked all files as reviewed by mistake by clicking the "Mark as reviewed" button or via the default shift+X keyboard shortcut, you can now undo via a small link that appears under the button. But don't wait too long, most state changes will make the undo option go away.

Improved file sorting


I cleaned up the file sorting code so that files should now be reliably sorted, and files in a directory will always be sorted before any subdirectories.

Better @-mention completion


The @-mention completion list will now include everyone who participated or was previously mentioned in the PR, even if they're not a member of the organization or a repository collaborator.

Trying out a changelog


Even though I work on Reviewable all the time, sometimes it may seem that not much is happening so I'm going to try out this new changelog feature. You'll see a small red counter whenever there's an update or you can read the full log here.

Let me know whether you think this is useful or annoying!

No published changelogs yet.

Surely Reviewable will start publishing changelogs very soon.

Check out our other public changelogs: Respond by Buffer, JSFiddle, Ustream, ViralSweep, StartupThreads, Userlike, Unixstickers, Survicate, Envoy, Gmelius, Coiney, Streamable, Reviewable, Iubenda