Completion conditions and obsolete revisions

In Reviewable, a revision becomes obsolete if any of the commits it covers are no longer part of the PR; this usually happens because of a force push. Those revisions are shown crossed out in the file matrix:

While Reviewable dealt with this just fine, until now custom review completion condition code couldn't tell whether if any of the review's revisions were obsolete. This could lead to unexpected outcomes, especially if you rolled back a branch making the last revision obsolete.

If your completion condition code ever assumed that the last revision is the latest / current one (this includes the sample conditions, if you copied them!), you'll need to fix it like so:

_.last(revisions)                       // BAD OLD WAY
_(revisions).reject('obsolete').last()  // NEW WAY

This goes for both review.revisions and individual file.revisions. I updated the samples so you can safely crib from them again.

BTW, another way to fix this would have been to simply redact obsolete revisions from the data structure passed to the condition code. I decided against this approach because it would preclude some potentially useful condition logic.

Collapsing discussions

Collapsing a long discussion (e.g., by clicking Acknowledge) will no longer scroll you to some seemingly random spot on the page. If the top of the discussion is off-screen, Reviewable will automatically counter-scroll the window so it'll look like the discussion is collapsing from the top down and remain within the viewport.

BTW, the rewrite is making good progress! The end isn't quite in sight yet but it's just over the horizon. :)

Sample commit status in new repos

When you connect a repo, Reviewable will now automatically create a sample commit status (not associated with any PR). This way, you can include Reviewable in the branch protection settings in GitHub even before you've opened your first PR!

This also works nicely in conjunction with the repo auto-connect feature announced a couple days ago.

Automatically connect new repos

If you often create new repos in your organization and forget to connect them to Reviewable — good news! If you're an organization owner, just switch on this toggle on the Repositories page and it'll happen automatically:

Repos should be connected within seconds of being created and will copy the prototype repo's settings as usual. If you manually disconnect a repo it will be opted out of the mechanism forevermore so you can easily make case-by-case exceptions.

You can also automatically connect personal repos but there will be a delay of up to a few minutes after a new one is created since GitHub doesn't send webhooks for this event so Reviewable has to poll instead.

As ever, please let me know if something's broken. :)

More robust logins

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.

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.

.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.

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