Reviewable changes Reviewable changes reviewable.io

Automatically connect new repos

New

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

  Fix   

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

New

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

New

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

  Upd  

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

New

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

New

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

New

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

New

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?

  Upd  

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!

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