4 ms·

Phabricator rocks, primarily as a code review tool – we've been using it at Khan Academy since 2012. It's sad how much better it is than GitHub PRs, especially

Phabricator rocks, primarily as a code review tool – we've been using it at Khan Academy since 2012. It's sad how much better it is than GitHub PRs, especially for a large team. I'm looking forward to watching it continue to grow. :)

chralieboy 12y ago
Could you elaborate on its benefits vs. GitHub? Having used Phabricator in production for over a year and a half, I have been consistently disappointed by its horrendous user experience, lack of integrations, and overall difficulty of use. Compared to GitHub, it has really been night and day.
- spicyj 12y ago
  GitHub doesn't have a way to assign reviews to more than one person or to see the code reviews that you need to take action on (meaning code you need to review or reviews you authored that need updating, without showing reviews that you're waiting for another person on) on a single repo, let alone across all repos. GitHub's emails are incredibly noisy to the point that I'm reluctant to make inline comments for fear of spamming people's inboxes. When someone updates a PR, it's hard to see what's changed since the last version you saw. Phabricator also has other niceties like syntax highlighting within diffs, two-column diffs (which admittedly GitHub added about a month ago), and a solid command-line tool ("arc") for sending off reviews, etc.
  - chralieboy 12y ago
    GitHub does have the ability to assign to (https://help.github.com/articles/assigning-issues-and-pull-requests-to-other-github-users/ https://help.github.com/articles/assigning-issues-and-pull-r...) and filter by assignee (https://help.github.com/articles/filtering-issues-and-pull-requests-by-assignees/ https://help.github.com/articles/filtering-issues-and-pull-r...). If you want to pull in multiple reviewers, you can @mention them. Even in Phabricator, though, when you have multiple reviewers only one has to accept for it to be accepted. Oftentimes it is _more_ confusing to have multiple reviewers because you don't know who should have the final say. Github has Hub (https://github.com/github/hub https://github.com/github/hub) which is as powerful, if not more so, than arc. The commenting system is a matter of preference, but having forgotten to "Clowncopterize" (a great demonstration of the professionalism of those who hack on Phabricator) comments, and given that they thread in email, it hasn't been a problem for me. Though I understand where you're coming from.
    - gcb0 12y ago
      I have no idea where that help page took those screen shots from... but it is definitely not from github.com or github enterprise. I see no way to assign pull requests... i don't even see the checkbox they mention on the PR list!
      - stormbrew 12y ago
        That's really odd.. I see it on both the public github and the not completely up-to-date GH-enterprise setup I have access to...
      - frossie 12y ago
        You need to have someone to assign the PR to. Either you need a second contributor on the repo, or you need to be in an organisation with more than one member.
    - spicyj 12y ago
      > Even in Phabricator, though, when you have multiple reviewers only one has to accept for it to be accepted. Oftentimes it is _more_ confusing to have multiple reviewers because you don't know who should have the final say. Yeah, this depends on workflow. We generally send every piece of code to two reviewers but just wait for either one to accept, unless there's a particular reason that both should look at the review. This works well for us but I can see how it wouldn't work as well for people with other processes. > The commenting system is a matter of preference, but having forgotten to "Clowncopterize" (a great demonstration of the professionalism of those who hack on Phabricator) comments, and given that they thread in email, it hasn't been a problem for me. Though I understand where you're coming from. Yes, Phabricator's isn't perfect but it's the best of the ones I've tried, especially if everyone using it is familiar with the tool and uses it frequently (that is, you might forget to Clowncopterize once or twice ever, but then you'll know for the future). I used to use Kiln (http://www.fogcreek.com/kiln/ http://www.fogcreek.com/kiln/) which had a different approach for emails – they essentially debounce emails to have a half-hour delay and coalesce any emails within that timeframe together, so you get fewer emails but don't need to submit the collection of comments explicitly. Having tried all three choices, I'd say that they're all painful in different ways and I personally prefer Phabricator's approach.
  - piotrkaminski 12y ago
    A bit of hopefully useful self-promotion: for those interested in all* of these benefits without ditching GitHub, check out https://reviewable.io https://reviewable.io. It has batch comment support (as well as one-off instant send), incremental diffs between revisions (even when rebasing), syntax highlighting in diffs, responsive one- and two-column diffs, and more. And there's no new command-line tools to install and learn -- it hooks right into GitHub. * The review dashboard already shows all the reviews you're involved, but not yet which ones require action. This feature is coming soon -- I have all the data, just need to add some code to massage and display it appropriately.
stormbrew 12y ago
I prefer github, personally. Mostly because it doesn't fight the nature of git as much (though, surprisingly, it sort of does a bit). Particularly, if you have a back-and-forth of changes on a PR, the inline comments that relate to lines that haven't changed stick around (and references to no longer connected comments are available in the UI). I find this huge for progressively dealing with things. And it does this whether you've force pushed a rebased cleanup or just capped another change onto the PR's branch. And then there's the way phabricator manipulates your commit messages in rather elaborate ways that are often confusing or frustrating. It also shows that the authors don't have a lot of respect for the idea of using merge bubbles over squashing commits, and I much prefer bubbles. And because of using merge bubbles primarily, github can tell when you merge a PR even if you don't use its tools to do it. And while I like the ability to batch comments, I don't like that it makes you always batch them. Sometimes I really only have one thing to say and it's way too easy to forget to submit. Likewise I like the ability to do pre-review tests, but for a large codebase I also really love the commit-hook UI cycle of github's integrations with stuff like travis and circleci, because a lot of the things I've worked on in the last couple of years have full compile+test cycles in the 10s of minute ranges. Two column layout, the batch commenting, pre-review-tests, and the code highlighting are all great. But I really prefer tools that really strongly integrate with git. I'm not really interested in vcs portability at this point. I often wonder how many people who have really strongly negative opinions of GH PR workflows have been forced to use it with full forks instead of a shared repository. Honestly, github forks are terrible for anything but casual submission of open source patches (and even there I think there'd be better ways). I've seen people try to use them for more serious stuff and it never goes well.
- SEJeff 12y ago
  FWIW, I found a better (it isn't the default) workflow with phabricator. If you set: "immutable_history": true In your repo's .arcconfig, it will work this way: When creating a topic branch and you "arc land", it will only put that nasty phabricator formatted commit message in the merge commit that merged the topic branch into the master/develop branch. When you just submit a review against the branch you want to land to, you simply git push, and the review message doesn't go to the repo. This gives us the best of both in that phabricator doesn't overwrite our commit messages, or rebase squash things, but we get the phabricator metadata in the repo when we want it.

chralieboy 12y ago

Could you elaborate on its benefits vs. GitHub? Having used Phabricator in production for over a year and a half, I have been consistently disappointed by its horrendous user experience, lack of integrations, and overall difficulty of use. Compared to GitHub, it has really been night and day.

spicyj 12y ago
GitHub doesn't have a way to assign reviews to more than one person or to see the code reviews that you need to take action on (meaning code you need to review or reviews you authored that need updating, without showing reviews that you're waiting for another person on) on a single repo, let alone across all repos. GitHub's emails are incredibly noisy to the point that I'm reluctant to make inline comments for fear of spamming people's inboxes. When someone updates a PR, it's hard to see what's changed since the last version you saw. Phabricator also has other niceties like syntax highlighting within diffs, two-column diffs (which admittedly GitHub added about a month ago), and a solid command-line tool ("arc") for sending off reviews, etc.
- chralieboy 12y ago
  GitHub does have the ability to assign to (https://help.github.com/articles/assigning-issues-and-pull-requests-to-other-github-users/ https://help.github.com/articles/assigning-issues-and-pull-r...) and filter by assignee (https://help.github.com/articles/filtering-issues-and-pull-requests-by-assignees/ https://help.github.com/articles/filtering-issues-and-pull-r...). If you want to pull in multiple reviewers, you can @mention them. Even in Phabricator, though, when you have multiple reviewers only one has to accept for it to be accepted. Oftentimes it is _more_ confusing to have multiple reviewers because you don't know who should have the final say. Github has Hub (https://github.com/github/hub https://github.com/github/hub) which is as powerful, if not more so, than arc. The commenting system is a matter of preference, but having forgotten to "Clowncopterize" (a great demonstration of the professionalism of those who hack on Phabricator) comments, and given that they thread in email, it hasn't been a problem for me. Though I understand where you're coming from.
  - gcb0 12y ago
    I have no idea where that help page took those screen shots from... but it is definitely not from github.com or github enterprise. I see no way to assign pull requests... i don't even see the checkbox they mention on the PR list!
    - stormbrew 12y ago
      That's really odd.. I see it on both the public github and the not completely up-to-date GH-enterprise setup I have access to...
    - frossie 12y ago
      You need to have someone to assign the PR to. Either you need a second contributor on the repo, or you need to be in an organisation with more than one member.
  - spicyj 12y ago
    > Even in Phabricator, though, when you have multiple reviewers only one has to accept for it to be accepted. Oftentimes it is _more_ confusing to have multiple reviewers because you don't know who should have the final say. Yeah, this depends on workflow. We generally send every piece of code to two reviewers but just wait for either one to accept, unless there's a particular reason that both should look at the review. This works well for us but I can see how it wouldn't work as well for people with other processes. > The commenting system is a matter of preference, but having forgotten to "Clowncopterize" (a great demonstration of the professionalism of those who hack on Phabricator) comments, and given that they thread in email, it hasn't been a problem for me. Though I understand where you're coming from. Yes, Phabricator's isn't perfect but it's the best of the ones I've tried, especially if everyone using it is familiar with the tool and uses it frequently (that is, you might forget to Clowncopterize once or twice ever, but then you'll know for the future). I used to use Kiln (http://www.fogcreek.com/kiln/ http://www.fogcreek.com/kiln/) which had a different approach for emails – they essentially debounce emails to have a half-hour delay and coalesce any emails within that timeframe together, so you get fewer emails but don't need to submit the collection of comments explicitly. Having tried all three choices, I'd say that they're all painful in different ways and I personally prefer Phabricator's approach.
- piotrkaminski 12y ago
  A bit of hopefully useful self-promotion: for those interested in all* of these benefits without ditching GitHub, check out https://reviewable.io https://reviewable.io. It has batch comment support (as well as one-off instant send), incremental diffs between revisions (even when rebasing), syntax highlighting in diffs, responsive one- and two-column diffs, and more. And there's no new command-line tools to install and learn -- it hooks right into GitHub. * The review dashboard already shows all the reviews you're involved, but not yet which ones require action. This feature is coming soon -- I have all the data, just need to add some code to massage and display it appropriately.

stormbrew 12y ago

I prefer github, personally. Mostly because it doesn't fight the nature of git as much (though, surprisingly, it sort of does a bit). Particularly, if you have a back-and-forth of changes on a PR, the inline comments that relate to lines that haven't changed stick around (and references to no longer connected comments are available in the UI). I find this huge for progressively dealing with things. And it does this whether you've force pushed a rebased cleanup or just capped another change onto the PR's branch. And then there's the way phabricator manipulates your commit messages in rather elaborate ways that are often confusing or frustrating. It also shows that the authors don't have a lot of respect for the idea of using merge bubbles over squashing commits, and I much prefer bubbles. And because of using merge bubbles primarily, github can tell when you merge a PR even if you don't use its tools to do it. And while I like the ability to batch comments, I don't like that it makes you always batch them. Sometimes I really only have one thing to say and it's way too easy to forget to submit. Likewise I like the ability to do pre-review tests, but for a large codebase I also really love the commit-hook UI cycle of github's integrations with stuff like travis and circleci, because a lot of the things I've worked on in the last couple of years have full compile+test cycles in the 10s of minute ranges. Two column layout, the batch commenting, pre-review-tests, and the code highlighting are all great. But I really prefer tools that really strongly integrate with git. I'm not really interested in vcs portability at this point. I often wonder how many people who have really strongly negative opinions of GH PR workflows have been forced to use it with full forks instead of a shared repository. Honestly, github forks are terrible for anything but casual submission of open source patches (and even there I think there'd be better ways). I've seen people try to use them for more serious stuff and it never goes well.

SEJeff 12y ago
FWIW, I found a better (it isn't the default) workflow with phabricator. If you set: "immutable_history": true In your repo's .arcconfig, it will work this way: When creating a topic branch and you "arc land", it will only put that nasty phabricator formatted commit message in the merge commit that merged the topic branch into the master/develop branch. When you just submit a review against the branch you want to land to, you simply git push, and the review message doesn't go to the repo. This gives us the best of both in that phabricator doesn't overwrite our commit messages, or rebase squash things, but we get the phabricator metadata in the repo when we want it.