4 ms·

One thing to note if someone consider switching from GitHub to Phabricator: Phabricator use a pre-commit reviews based on patches rather than being branch-based

by sirn 8y ago

One thing to note if someone consider switching from GitHub to Phabricator: Phabricator use a pre-commit reviews based on patches rather than being branch-based like in GitHub/GitLab/BitBucket. Make sure to read the Phabricator Review Workflow[1] before making the switch, because everyone in your team have to change their workflow if they already used to Pull Request/Merge Request workflow. :-) That said, I always found Phabricator's issue tracker (Maniphest) to be superior to GitHub Issues, with ability to create task dependencies (parent/child) and ability to limit tasks permissions only to few selected groups (with spaces). It's possible to setup Phabricator to mirror other repositories if you want to use only its issue tracker. [1]: https://secure.phabricator.com/phame/post/view/766/write_review_merge_publish_phabricator_review_workflow/ https://secure.phabricator.com/phame/post/view/766/write_rev...

lima 8y ago
The patch-based workflow is very similar to how the Linux kernel review workflow works. Arguably, this is the way Git is supposed to work - submit patches, discuss them, then merge them once they're ready. Every idea is one commit, no checkpoints or "fix typo". Pull requests are used to merge other maintainer's trees that have many commits in them. It also ensures that there's a permanent link between a commit and its review, since there's a 1:1 mapping. Gerrit works similarly, but Phabricator's UI is much more friendly. For small projects or teams, the overhead of introducing a new tool may not be worth it, for for large projects with many contributors, the workflow is - in my opinion - strongly superior. If you set Github to "squash and rebase" and enforce a "one PR per idea" rule, you will get a pretty similar workflow. The tooling isn't quite as polished, but it's sufficient for many projects. Quote: > As far as code reviews go, this is pretty spot on. I was part of a a startup that was using GitHub pull requests for code reviews. As the team grew, it became more and more intractable, although not simply because of notifications. Side-by-side diffs and checkpointed diffs (so that you can see what changed since the last round of review and whether/how your comments were addressed) are handled very poorly by GitHub. We ultimately switched to Phabricator, and while there was a little friction as folks got acquainted with the new tool, it made code reviews a much more pleasant process. Recently, I had to go through a full code review back on GH pull requests, and it felt like pulling teeth in comparison. They're fine for interacting with contributors to an open source project, but compared to working with a tool like Phabricator that's built for a code reviewer's workflow (and for teams of engineers working together on a project), they just don't hold a candle, in my opinion. (from a previous discussion: https://news.ycombinator.com/item?id=7697132 https://news.ycombinator.com/item?id=7697132)
- zbentley 8y ago
  > Side-by-side diffs and checkpointed diffs (so that you can see what changed since the last round of review and whether/how your comments were addressed) are handled very poorly by GitHub. I've heard that complaint a lot. How are these things handled poorly by GitHub? It's an honest question; I've only used GH and a bad, ad-hoc, poorly-thought-through Perforce workflow, so I may not know what I'm missing, but it has always seemed quite simple for me to scroll through a pull request and see feedback (either tagged to lines of diff or general), and commits that address pieces of feedback. Then you can click on each commit to view it, or open the full hairball diff to see how those changes end up in the final result. What's missing there? It sucks when someone puts a bunch of unrelated changes in one commit, or when their commit message is bad ("code review"), but those seem like they'd be problems regardless of GitHub. I've looked at patch-submit-discuss/mailing-list-style workflows, and they seem fine. The discussion is definitely more front and center. However, when people submit updated patches it seems like I'd want to be able to easily tell what changed between their first iteration and second iteration of the patch--i.e. did they actually address the feedback they got? This can be hard to see, especially if a patch is substantial or to confusing/repetitive code. I can download all the submissions and run diff on each pair in sequence, but that seems like needless hassle when, unless the feedback was "throw it all out and do it a totally different way" (which, in a branching workflow, is often a good reason to start on a fresh branch), subsequent iterations could be submitted as a "patch to a patch", with an easy way to view the cumulative diff. At this point, it would basically be a branch workflow. Are there solutions for this in the patch-submit-discuss model?
  - u801e 8y ago
    > I've heard that complaint a lot. How are these things handled poorly by GitHub? Basically, when changes are requested, the patch based work flow is to submit a revised set of commits up for review. In Github, one can do that by either force-pushing to the branch that's currently attached to a pull request, or one can push up a new branch and open up a new pull request associated with that branch. But there isn't a way to view the "interdiff" between the version of the branch before review and the version of the branch after review. Review tools like Phabricator, Gerrit, and email lists allow one do view that diff.
optimuspaul 8y ago
That sounds horrible (to me). I have always preferred the branch/pull request/merge workflow. I always have always felt strongly that the history be maintained so we can see how the code evolved when a feature was being worked on. We can often get insight into what things may have been tried but didn't work.
- rimliu 8y ago
  It took some time to get used after moving from Atlassian Stash (which works quite well for code reviews, imho) to Phabricator/Arcanist. Still consider the latter inferior to Atlassian tools.
xtracto 8y ago
Another thing to consider on this is the management that has to be done to arc. When using arc, it has to be setup in every new computer, and it becomes messy if you want to use Client Certs. We had a big Wiki page for newcomers on how to setup arcanist, and it was not that funny.

by sirn 8y ago

lima 8y ago

The patch-based workflow is very similar to how the Linux kernel review workflow works. Arguably, this is the way Git is supposed to work - submit patches, discuss them, then merge them once they're ready. Every idea is one commit, no checkpoints or "fix typo". Pull requests are used to merge other maintainer's trees that have many commits in them. It also ensures that there's a permanent link between a commit and its review, since there's a 1:1 mapping. Gerrit works similarly, but Phabricator's UI is much more friendly. For small projects or teams, the overhead of introducing a new tool may not be worth it, for for large projects with many contributors, the workflow is - in my opinion - strongly superior. If you set Github to "squash and rebase" and enforce a "one PR per idea" rule, you will get a pretty similar workflow. The tooling isn't quite as polished, but it's sufficient for many projects. Quote: > As far as code reviews go, this is pretty spot on. I was part of a a startup that was using GitHub pull requests for code reviews. As the team grew, it became more and more intractable, although not simply because of notifications. Side-by-side diffs and checkpointed diffs (so that you can see what changed since the last round of review and whether/how your comments were addressed) are handled very poorly by GitHub. We ultimately switched to Phabricator, and while there was a little friction as folks got acquainted with the new tool, it made code reviews a much more pleasant process. Recently, I had to go through a full code review back on GH pull requests, and it felt like pulling teeth in comparison. They're fine for interacting with contributors to an open source project, but compared to working with a tool like Phabricator that's built for a code reviewer's workflow (and for teams of engineers working together on a project), they just don't hold a candle, in my opinion. (from a previous discussion: https://news.ycombinator.com/item?id=7697132 https://news.ycombinator.com/item?id=7697132)

zbentley 8y ago
> Side-by-side diffs and checkpointed diffs (so that you can see what changed since the last round of review and whether/how your comments were addressed) are handled very poorly by GitHub. I've heard that complaint a lot. How are these things handled poorly by GitHub? It's an honest question; I've only used GH and a bad, ad-hoc, poorly-thought-through Perforce workflow, so I may not know what I'm missing, but it has always seemed quite simple for me to scroll through a pull request and see feedback (either tagged to lines of diff or general), and commits that address pieces of feedback. Then you can click on each commit to view it, or open the full hairball diff to see how those changes end up in the final result. What's missing there? It sucks when someone puts a bunch of unrelated changes in one commit, or when their commit message is bad ("code review"), but those seem like they'd be problems regardless of GitHub. I've looked at patch-submit-discuss/mailing-list-style workflows, and they seem fine. The discussion is definitely more front and center. However, when people submit updated patches it seems like I'd want to be able to easily tell what changed between their first iteration and second iteration of the patch--i.e. did they actually address the feedback they got? This can be hard to see, especially if a patch is substantial or to confusing/repetitive code. I can download all the submissions and run diff on each pair in sequence, but that seems like needless hassle when, unless the feedback was "throw it all out and do it a totally different way" (which, in a branching workflow, is often a good reason to start on a fresh branch), subsequent iterations could be submitted as a "patch to a patch", with an easy way to view the cumulative diff. At this point, it would basically be a branch workflow. Are there solutions for this in the patch-submit-discuss model?
- u801e 8y ago
  > I've heard that complaint a lot. How are these things handled poorly by GitHub? Basically, when changes are requested, the patch based work flow is to submit a revised set of commits up for review. In Github, one can do that by either force-pushing to the branch that's currently attached to a pull request, or one can push up a new branch and open up a new pull request associated with that branch. But there isn't a way to view the "interdiff" between the version of the branch before review and the version of the branch after review. Review tools like Phabricator, Gerrit, and email lists allow one do view that diff.

optimuspaul 8y ago

That sounds horrible (to me). I have always preferred the branch/pull request/merge workflow. I always have always felt strongly that the history be maintained so we can see how the code evolved when a feature was being worked on. We can often get insight into what things may have been tried but didn't work.

rimliu 8y ago
It took some time to get used after moving from Atlassian Stash (which works quite well for code reviews, imho) to Phabricator/Arcanist. Still consider the latter inferior to Atlassian tools.

xtracto 8y ago

Another thing to consider on this is the management that has to be done to arc. When using arc, it has to be setup in every new computer, and it becomes messy if you want to use Client Certs. We had a big Wiki page for newcomers on how to setup arcanist, and it was not that funny.