My experience with Phabricator is with the code review system (Differential), rules system (Herald), CLI (Arcanist), and API (Conduit). I can't speak to other functionality like repo hosting or task management.
I joined Eventbrite shortly after they moved from Review Board to Phabricator for code review about 4 years ago. It took me a little while to adjust, but once I did I found it to be superior to what Github provided. The CLI provides a nice way to standardize on a workflow company-wide. The UI for composing a review has a few quirks but a lot of functionality, and the patch-based aspect makes it easy to track the evolution of a diff. Herald is very powerful for making sure the right people review a diff. Conduit provided what we need to integrate with Jenkins for CI.
Github has gotten better since then, but I'd still lean toward Phabricator as the better tool for code review, especially for larger projects.
I eventually partially inherited running Phabricator at Eventbrite, and found it overall to be straightforward to configure and troubleshoot. We were only running a single node and using git for repositories, though. Now I'm at Mozilla, and we recently switched from Review Board to Phabricator for Firefox code review. Some of my teammates run the service, and I know that running a multinode setup with mercurial as the repo format has proven challenging.
I only tried out Phabricator briefly, and it was pretty good. But the data model bothered me in how it introduces its own abstraction of patches on top of the git branch model. It seems redundant, and also seems like an SVN-inspired model that just felt like a step backwards from having the power of plain git (as in the ability to create diff objects and branch and rearrange them arbitrarily in a pretty simple way, and have multiple people working on these branches at the same time and keeping in sync with each other). I know you can still use plain git locally with Phabricator, but the extra layer of abstraction seemed to only add complexity since now you basically have different data models locally as you do on the server whereas previously they were the same. And what you gain from it didn't seem big enough to justify this, because at the end of the day you can accomplish a lot of the same things in git (like using the squash & merge strategy in github) without introducing any new primitives.
I didn't use it long enough to really figure out if this is a purely aesthetic concern and I'm just being stubborn about the way I'm used to or if it leads to real problems in practice. I'm curious what people who really like Phabricator think about this.
"as in the ability to create diff objects and branch and rearrange them arbitrarily in a pretty simple way, and have multiple people working on these branches at the same time and keeping in sync with each other"
I can't truly speak for them, but I suspect these are both (reworking the history of code while its in review, and multiple people working on a branch) things that the Phabricator authors would say are bad practices that your tools should discourage. The arguments that come to my mind are
1) Reworking history during review makes it near for your reviewers to understand what is changing. That should be reserved until its time to merge your code, at which point all the revisions along the way should be squashed.
2) Shared development on a branch means the scope of the change is large, and the branch is probably long-lived too. Both of these are arguably bad; I don't have time to argue why, but chapter 13 of Continuous Delivery lays it out well.
Mercurial's Queues extension had an interesting solution to this. Basically, WIP branches would instead be stored as patch files under version control in a separate per-PR repository. To merge you'd apply each patch as a commit and then archive/delete the queue repository. This would let you organize commits logically, while also letting reviewers query by chronological order. As a PR author it was effectively a `git rebase -i` that you could walk back and forth as you pleased, without destroying any history.
I like the abstraction of patches, because some of our projects still runs SVN and HG, and because we're all on Phab, we're all using the same flow. We actually don't feel any urge to move to git at all (it's probably going to happen some day anyway)
In practice when using Phabricator, you (or at least, I) begin to just think of branches more or less as a way of backing things up to a safe location, local incremental development, and cross-developer collaboration -- not as an actual mechanism of reviewing things that will go into the tree.
Really, it's a lot like the mailing list model: you may develop incrementally in whatever way you want, probably between multiple people, but at the final stage you're going to need a clean set of delineated patches to submit for review and someone takes ownership of that part (90% of the time that's you, maybe not you if you're on a multi-person feature). These are more or less two different steps in the development cycle.
This basically happens anyway in my experience at a certain point, even if using GitHub, depending on how your team develops... For example, we recently had a long-lived (~2 month) branch open that accumulated about 300 commits and diverged from our upstream master at $WORK. It implemented a large feature, between many components, and during that time had to be revised in a few ways, due to unforeseen (but minor) things. We didn't just do a direct merge; we assigned individual people subsets of the work, and they were responsible for bringing in the changes in a reliable way. This turned 300 commits into something like 30 or 40. This part of the development is basically the last step, and it took time for us to bite-size the pieces. But then the actual review step -- and submitting the patches -- is a very small part at the end.
A lot of projects like LLVM follow basically the same model (they use Phabricator too but that's more a coincidence, nothing to do with the general flow): the final patch stage is a very separate part from the development stage, all things considered, and posted patches for big features rarely reflect actual development. So, I think putting yourself in this mindset helps. GitHub completely ties the notion of a branch to be both "A thing you use for development" and "The thing that the reviewer finally sees" by way of PR, but clearly this is more a design choice on their part -- rather than a fundamental property of git.
Regarding abstraction, there is a thing about this, which is that you mostly interact through Arcanist to submit patches. This admittedly adds complexity and can confuse people if they think `arc` is just identical to `git`. We had to teach a lot of people to use Arcanist for Haskell.org. This can absolutely be considered a real downside. Admittedly though, Arcanist is an abstraction, and it also works for SVN and Mercurial, so if you have multiple types of repos -- that's arguably very useful! For homogeneous VCS setups, though, I can see how it only seems to add complexity. Realistically, the review stage where you interact with Arcanist is pretty small in the overall development cycle with most changes, but people are still sensitive to it.
---
Honestly I don't think it's a big deal at all, and in fact I find Phabricator's model quite a bit nicer than GitHub's in some incidental ways too, because of it. One nice thing is that you don't have a trillion dead forks of popular repos, search across all patches is unified, stuff like that...
I used Phabricator for 4 years in a previous company. I used also Differential, Arcanist (for pre-commit code reviews), herald, Maniphest, Paste among others.
Personally, I really liked it, except for the fact that the interface feels clunky and outdated. When I was leaving, the company was moving to GitLab mainly to use the "pull request" flow, which is not available in Phabricator.
Agreed on all points - I think Phab is awesome, easy to use, and most of all easy to manage. I loved it during my time at EB. I think it’s an insanely powerful tool and I have no idea how I could have done my job without the automated herald rules system.
- One of the main repo is a monorepo in Git with over 40~ services
- We have a lot of smaller repos that are outdated or depreciated.
- We have an extensive pipeline that builds Docker images using Google Cloud Container Builder
Here's the pros:
- Speed. Gitlab is so slow; it's actually one of the main reasons why we moved out of it.
- Phabricator's Maniphest > Gitlab Issues by a long shot
- We prefer patch-based workflow. It makes Git history pretty.
- Code review is so much better in Phabricator, again, by a long shot. It's faster and the experience is a lot better.
- Herald (if-this-then-that for source code) is the bomb. We have a big list of rules, example: detecting `dangerouslySetInnerHTML` in our frontend service and adding blocking reviewers.
- Git management is pretty dope, setting it up so that it mirrors somewhere else is pretty easy. In our case, we just made it so that it mirrors to Google Cloud Repository (for GCCB to work)
- Cluster mode is included, which is useful because we're setting up a mirror Phab Repo in Russia for our team there
- Meme editor makes things more fun (but its kinda shitty that it doesn't accept GIF =\)
- The dashboard editor is very powerful and useful.
- We had teams using SVN and teams using HG. Phab supports them all. That's pretty cool.
Here's the cons:
- Harbormaster, the CI, is the worst. It's seriously super complicated and not powerful at all.
- To replace Gitlab CI, we moved to Buildkite since there's an integration with Phab. Buildkite is a lot more powerful than Gitlab CI, and the syntax is similar.
- The concept of "staging" repo is super confusing.
- Setting up "merge" from the UI is very complicated and buggy
I love buildkite and I wish they had better pricing model -- we would definitely love to pay for more.
Pros of buildkite:
- Very powerful. Plugin system is amazing and easy to extend. We wrote our own buildkite-docker executor, and I merged a lot of parts from it to the docker plugin upstream
- UI is a lot prettier and responsive than Gitlab's
- Dynamic pipelines !
- Hooks are extensive and powerful. Precheckout, Checkout, PostCheckout, precommand, command, postcommand. You got it all.
- The GraphQL API is amazing, and probably one of the best API I've used in my life.
- Pipelines are composable. You can make a yaml include another yaml. This was our biggest gripe with Gitlab since we use a monorepo and it got pretty big
- I know for a lot of people it doesn't mean a lot, but I like emojis in the output
- Agents are not stored like Gitlab. In Gitlab, once an agent connects, it gets stored in the database and never disappear until you delete it. It's problematic for our use case, because we use pre-emptibles node to save cost. It's 30% of the real price, and it dies every 24 hours. after 3 months, our Gitlab got super slow because it retained all the infos on all runners that existed. I had to make a script that deleted it from the database.
However, if you add your own CI runners, you'd have to clean them up periodically. This was the biggest issue for us, because even after cleaning them up from all docker images once a week, builds would get stuck.
We run buildkite-agents in its own kubernetes cluster, and the nodes are pre-emptible on Google Cloud so 30% of the price and it dies everyday, so it gets cleanup automatically
When I looked at Gogs, the code was really messy, had trivial SQL injection vulnerabilities in the past and the maintainer actively resisted efforts to implement basic features like OAuth2.
I hear that's exactly the reason why Gitea forked from Gogs.
In the past month, Gitea merged ~110 pull requests and got 70 new issues, and Gogs 7 and 18. Gitea also has 1500 (30%) more commits. All of this indicates to me that Gitea is further along than Gogs. Mainly based on that I went for Gitea and I like it so far, but I didn't install Gogs so I can't compare directly.
And Phab is written in PHP, if some of the posters from previous HN discussions about PHP were to be believed there would be no point even looking at this software compared to one written in Ruby.
Since then php got faster, laravel copied many Rails concepts and improved in many areas. PHP is getting more popular while Ruby/rails is losing marketshare.
We prefer patch-based workflow.
It makes Git history pretty.
What is wrong with the feature branch approach? Before you merge a feature branch, you can squeeze all its commits into one. That leads to a pretty history too.
This is basically how you use Phabricator locally. Phabricator looks at patches to do code review, but the "arc land" CLI command takes your feature branch, squashes the commits, rebases onto master, and pushes that. So local development can use feature branches and the main repo has a normal git history. (Github added support for "squash and merge" maybe a year or so ago; same idea)
> Before you merge a feature branch, you can squeeze all its commits into one. That leads to a pretty history too.
With Github, you'll end up with a history like:
Implement feature A
Merge #1 Implement feature A
Implement feature B
Merge #2 Implement feature B
...
you basically end up with twice as many commits than you would otherwise. The other problem is that each commit ends up being rather big and the commit message is a combination of all the commits that were squashed, including ones that don't really contain any useful information (e.g., "Addressing comments").
A big commit is harder to revert (without encountering conflicts).
In either case, you end up with commits that have large diffs and touch many parts of the code base. Most features require multiple commits to implement. As far as I know, Github does not provide a facility to squash into multiple commits.
GitHub has a similar workflow - you can use "squash and rebase" as merge strategy, which adds a reference to the PR to the subject and combines the text of all commits into one.
But like the parent said, it's not nearly as fancy.
Of note is that in this workflow, the commit message is not subject to the same review process as the code and (hopefully) documentation etc, since it's in effect written by the user merging rather than the user committing.
Somewhere around 2016 and 2017, Gitlab made many performance improvement. May be OP was referencing slightly earlier? ( Or not )
Depending on who you are ask, Gitlab today is usable or Ok. I don't think anyone would call it fast. I wish they could write up where those bottlenecks are.
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.
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.
> 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?
> 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.
> 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.
Yes there is. You even get a link to view that exact diff whenever someone updates a PR. It shows changes since you last viewed the PR, up to its current state.
That's only the case if someone pushes up a commit like "Addressing comments" or "Fixed bug". If you rebase locally and force push the branch to maintain the clean set of commits after addressing review comments, Github does not provide a way to see the diff between the previous branch head commit and the current head commit.
> If you rebase locally and force push the branch to maintain the clean set of commits after addressing review comments
Why would you do that, in general? That seems needlessly hostile to reviewers, since then they have to go through your diff and make sure you caught every place their comment applied (e.g. "did they actually handle the else-case everywhere they're testing on $var?").
Is this common practice in situations* where it harms diff readability? If so, why?
* There are totally cases where that's necessary, but they don't seem like more than a small minority of comment/feedback/amendment cases. These are times like "you put all of this code in the totally wrong place" or "this is missing a fundamental assumption that would require you to totally rearchitect every change you wrote". In those cases, a rebase (plus clearly calling out "everything was rebased starting here please start reading from here on!") or a brand new branch is in order.
The main purpose is to maintain a clean set of commits. So rather than having a history like:
Add method and unit tests
Update version to 1.2.3
Fixed issue in method
Fixed syntax error
Addressing review comments
you only have the first two commits.
> That seems needlessly hostile to reviewers
Why would doing something like this be considered hostile? The problem here is the tool used for reviewing code, not the submitter or reviewers. Other review tools have had the feature of viewing the diff of the branch across rebases for quite some time now.
The only other alternative is to rely on the submitter to make sure they squash the amendments they make into the correct commit. That in itself is more difficult after making multiple commits of that nature. What usually happens in that case is that those commits end up as part of the master branch. This makes it more difficult to revert certain changes because they're split across multiple commits and it also makes it more difficult to track down the source of a bug. It also makes it more difficult to see which commit was responsible for a given change when using git blame.
The problem I run into when reviewing PRs on Github is that many people rebase or otherwise mutate their history locally to address review comments, then force push to the branch being reviewed. Once they've done that, you've lost the original commits and can't see how the new ones differ.
I dislike when questions are worded like that, because it could be interpreted in two ways:
a) Given an arbitrary case, is there a chance that modifying commits is considered a poor practise in that case?
b) Is the belief that modifying commits is poor practise held by the population at large?
The answer to a) is yes, the answer to b) is no.
Some people prefer a clean history, where you have to explicitly request the steps to get to it if you want them. Others want the messy steps to be part of the history you show up-front.
Ideally, a commit should be self contained and change only one thing. This means that a feature would consist of multiple commits.
Since later commits may depend one or more earlier commits (some of which may be in the same feature branch), how do tools that work on a commit based workflow handle those dependencies?
Most large teams avoid long-lived feature branches and instead try to get things reviewed and merged into master as soon as possible. It's better to have many small reviews than a few massive ones.
You usually try to avoid dependencies. If you can't avoid them, have a series of patches depend on each other.
Phabricator supports stacking patches. Here's a random patchset:
Dependent changes are a nightmare in phabricator. I tried it once using arcanist and git, and it seemed to be confused about which patchset I wanted to change. After this experience, I talked to a few colleagues, and they basically said "yeah, just don't use dependent reviews"
> The patch-based workflow is very similar to how the Linux kernel review workflow works.
I don't think that is accurate. Or there kernel its very common to submit whole patch series (branches), and to rebase them on the latest kernel. Phabricator makes multi commit reviews possible but a total pain.
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.
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.
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.
My impression, coming from tools like gerrit, bitbucket/stash, fisheye/crucible and google3 is that phab is a review tool that kind of wants to be a source control tool, but it fails at both. I actually dread putting up reviews when I upstream stuff to FreeBSD because I hate phab. I've found that it is just easier for me to use the "upload patch" feature than it is to use their arcanist tools on top of git or svn. I really wish the project would move away from this tool.
Several years ago, we also used Phabricator for code reviews. It had just enough friction that eventually our team fell to manual code reviews ("Hey, could you check out revision X?"), then eventually just stopped bothering to code review at all.
Since switching to Fisheye/Crucible, code reviews have become so easy we do them all the time as part of the normal workflow. I really can't imagine switching back nowadays.
I've contributed some code to Phabricator, happy to answer any questions about why that code is so bad.
Phabricator is primarily aimed at teams with multiple approximately-full-time engineers working on projects together, and focuses more on scaling up to thousands of engineers than scaling down to personal projects. It may be a poor fit for your needs if you're looking to move very small projects away from GitHub following the acquisition by Microsoft.
Ha! Epriest is actually the primary Phabricator developer by my read of their webpage.
Can you guys advertise more? I hear about Atlassian on NPR and my IT team has guys fully sold on their stuff but my team has been operating very cleanly off a Phabricator VM for years now. However IT keeps pushing me to go all Atlassian so they can "support it". I'm like, yo, git pull every few months to upgrade and keep the VM patched. They're like but Atlassian has conferences.
For us, Crucible was a significant improvement over Phabricator in terms of daily use. My team had been trialing it for several months, and upon demoing it to other teams and our managers, convinced them it was worth switching.
I disagree, Atlassian products, IMHO, are notoriously full of pain points: speed, usability, lack of updates, old issues languish, lack of accountability, corporate greed, unwilling to add features that compete with "addons/plugins/etc".
Supporting self hosted gets even more murky, documentation tends to be stale, updates tend to be in place and high availability is hit or miss.
Used Phabricator/Arcanist for one year straight, it wasn't fun. It's pedantic, buggy, happy to mutate your branches or "revisions" (PRs) unless you take specific care (which won't happen until you've been bitten enough times).
Wrapping git is essentially a flawed idea; there are just too many corner cases (rebasing, resetting etc) for a wrapper to handle them all.
I've had the same experience with Arcanist. I think it might be a good solution if the team is not very experienced with Git, as it provides a straightforward workflow. However, using some more "advanced" features myself, I felt crippled. My main pain point was about squashing all PR commits automatically (i.e. enforcing the Squash Merge strategy). Again, this might be a good idea for junior developers, but I'd rather decide myself how to separate my commits.
I also remember having some issues with Arcanist on Windows.
Amen. Common vanilla-git approaches/workflows like feature-branches/sprint branches/hotfix branches are a massive pain due the often undocumented pedantry of Arcanist/Phabricator.
For example, if you merge a reviewed commit into two different branches and then god forbid you try to merge those two branches, Arcanist will fail with a cryptic message - and you'll only realize that this is arbitrarily/buggy-ly forbidden only when you try this workflow several times...
Vanilla-git or even a Bitbucket/GitHub/GitLab style pull-request style workflow gives you so much flexibility that Arcanist just takes away from you, and the only way to learn these quirks is the hard way....
Phabricator has a very particular workflows. If you use that workflow, it is really fast to use; you can do almost everything from the command line except the actual code review/approval. And it is pretty good about encouraging that your repo is kept clean, decluttered, and consistent.
Whereas gitlab/github etc are much more flexible, but also slower to use and more demanding that your individual developers adhere to your standards.
I think Phab is best for projects of 3-5 to 50 (basically until your project is dealing with multiple commits per hour and no single repo is going to be painless), especially when you have new team members and you'd rather let the the tools enforce the workflow as opposed to policing them yourselves. However, if you don't like that workflow, you're never going to be happy with Phab.
Finally, Phab has some really nice features that I haven't seen elsewhere, like posting lint errors inline in the merge request.
Pointing out flaws without detailing them isn't very useful.
Arcanist is not a Git wrapper - you can (and should) use Git normally. All Arcanist does is automate the process of creating and uploading patches, and applying remote patches.
Pointing out flaws without going into a lot of detail isn't very good practice if you're trying to offer helpful criticism in a feature request, a bug report, or generally trying to work with the team to improve it.
It's completely fine and quite useful for someone to say that their experience was bad with a tool in general on an internet thread about the tool in general.
It says "used by the Wikimedia Foundation" in the title, but that's sort of misleading.
We do use Maniphest, the issue tracker component, heavily. And it's pretty great, honestly. I find it to be a useful blend of exposed functionality and ease of use.
That said, we don't use Differential, the code review component for most (any?) teams. Instead we're pretty entrenched on gerrit still, and I haven't seen any signs of that changing over the last few years.
Yo I love phabricator; it's one of my favorite pieces of software, but three things:
1. The title's seeming attribution to Wikimedia as opposed to Facebook (or even Phacility) is like, whatever the opposite of dog whistling is
2. If you want to host your own things, great; do that. Phab is great, gitlab is also pretty neat. If you want someone to manage this stuff for you, Phacility is out there grindin' but they also have like O(10) employees, so don't expect miracles
3. The point of GitHub was always about "social coding"; the concerns about overcentralization aren't unfounded but it's also not like that wasn't straight up the value proposition in th the first place!
If everyone moves off to their own walled gardens, something of value will be lost. So like, again: love phab (it/arc's my favorite code review workflow, I think the conventions it adds on commit messages are really valuable (and btw trace right back to Facebook eng culture), the pretty tight integration of tools is nice, I enjoy its sense of humor), but I think calling it meaningfully a true GitHub alternative, with any consideration of FOSS, is inaccurate
Disclosure: I left a startup using phab (at my urging) and GitHub at the end of March and now work at Microsoft (where my team has some code on VSTS and some on GitHub). I first encountered Phab as an intern at FB in 2011, when epreistly had just left
> Phabricator has more than 300,000 lines of PHP, so there are probably at least sixty or seventy million security vulnerabilities in the project. Virtually limitless wealth!
"Written in PHP so literally anyone can contribute, even if they have no idea how to program." - not exactly a cheery marketing point for PHP, not sure I'd want to use something written by people who have no idea how to program. But I guess that's why they have the blurb above...
It's a joke. You can't speak about PHP online without getting inundated with comments about how supposedly awful it is, and how if you like PHP you are a bad developer.
They are just embracing the steriotype sarcastically.
As a PHP programmers, we've gotten so used to people shitting on our language that we've internalized it and shit on it ourselves now. I don't like it but I'll lump it for the convenient std lib.
"Phabricator uses a lighthearted tone in documentation and some interfaces, and includes some features which primarily exist to add flavor or make things sillier.
We use this tone because we like building software like this, and the feedback we receive about it from users is overwhelmingly (and often effusively) positive."
I use phabricator at work, it is an incredible tool and the patch workflow and even dependencies for diffs are wonderful.
I’ve also tried to volunteer add to a project on github but whenever a pull request depends on another, it gets messy. Rewriting history all the time to make commits easier to review has been a pain.
Another option is the one created by the Fedora project: https://pagure.io/pagure. It's a Git hosting solution where all the additional bits related to a repo (issues, docs, etc.) are also their own Git repos that can be pulled and pushed into.
Chronotope.io CTO here. We are using Phabricator as our primary organization tool for the team of 20+ people. Maniphest (task management) was the main reason why we chose Phabricator. I agree that Arcanist can seem complex when you first use it, but after you start to use `arc feature` you never want to go back. We love patch-based workflow and how task management integrated with tasks. I wish Herald to have more integrations, but Phabricator API is quite nice and we built our own integration for Jenkins, similar to what Uber did, but working natively with Jenkins Pipeline.
I used Phabricator on a daily basis at Facebook, and loved it, after having used it at a previous job where I hated it. The biggest reason for that was that Phabricator is a piece of software that wants to be used in a very particular way, and that is the "you're all in" sort of way. It's not a tool you'll get good results from by timidly testing the water with your toe.
One particular manifestation of the prior point is that, for me, it worked best with a one-commit-per-unit-of-work workflow, where stacks can be merged on a commit-by-commit basis and code review issues are addressed by editing the changes into the relevant commits. In Git, making this work is a painful amount of history rewriting that lands you in a world of rebase pain. In Mercurial, you just fix things at the top of the stack and `hg absorb` the changes into their relevant commits. `hg absorb` is, in fact, the one Mercurial command I really wish I had in Git.
Yeah, I've recently contributed a few patches to KDE and it was surprisingly pleasant. Github-like approach works well where it works, but doesn't scale that well.
Sourcegraph CEO here. We have many customers using Phabricator with our Sourcegraph Phabricator extension, which adds code intelligence (hovers, definitions, references, implementations), and search to Phab diffs. It makes reviewing code pretty magical since you have IDE-like context.
If you are considering switching from GitHub to Phabricator, definitely give this integration a try. Would love to hear feedback! Will post a demo video soon.
It is worth mentioning that Sourcegraph itself isn't Free / Open Source software... which makes the license of the plugin irrelevant (and in fact Phabricator's license likely forced your hand), so it's just a little bit fishy that the only license you mentioned is that of the plugin.
Have been using it for years and years and would thoroughly recommend.
Would have to say that some of the different parts of it feel quite seperated and disconnected, e.g. the source code 'side' of it and ticketing 'side' etc.
A few years back I went through and evaluated multiple different tools primarily for their code review capabilities. I looked at quite a few including GitLab, Gogs, ReviewBoard, SmartBear, and Phabricator. We use Mercurial for source control and nearly considered migrating to Git because that's where the majority of tooling exists. We set up Phabricator and haven't looked back. Getting developers to use Phabricator/Arcanist was fairly organic -- learning to use a command line tool for creating the reviews was probably the most challenging but devs learned it because of the convenience of the code review.
It's very well-designed and has support for enterprise features like ldap, clustered servers, CI, etc. and there's no distinction between community/enterprise versions -- it's all open source. Other great features are task management, wiki, blogs, question/answer (a la StackOverflow), and of course memes/macros which add some lighthearted fun to code review. The engineering behind the product is top-notch which is evident from reviewing the tasks/discussions behind features [1], or even reviewing the source code. One killer feature for my company was Spaces, which allows setting up "walled gardens" -- we use it to allow external collaborators to create tasks, etc. without being able to see anything outside their own space.
Managing and maintaining Phabricator is pretty straightforward. It's a standard LAMP type of product (Linux, Apache, MySQL, PHP) which is easy for myself or IT to jump on and diagnose issues. It's the only tool I've seen which will also alert administrators to identified issues with configuration (when logged into web page). Additionally administrators of the tool do not have blatant all-access to projects, though that might be niche.
I'm glad it's getting more notice now, even if it's largely due to Microsoft acquiring GitHub. I don't know if Facebook uses Phabricator still but WikiMedia does and I belive the Mercurial development team is considering it [2]. Phabricator is a great product and worth trying out. Their community is located at [3] - they used to allow open access to their self-hosted Phabricator instance but it became too noisy as the user base grew so they've moved to discourse forums.
Facebook is using internal fork of phabricator (with facebook specific modification) for (almost) all the code-review (there might be exceptions). It's much better code-review tool than github.
I was a heavy user of Phabricator 2014 -> 2017. Spinning it up internally at work for code reviews. Ticketing, project management etc. It was nice that everything was tied together. Wiki, code reviews, sprints, etc. It was one common application. That could easily link back to one another.
The idea of tying a repository to a specific project was great. As was being able to in-line issues directly in a pull request.
However when I went to spin up a new project, and stack for myself, earlier this year. I went through the major options and settled on GitLab. I'm doing this on the public site, with public repositories. So can't speak to the pains of self-hosting.
But phabricator I think is still a great alternative if you want to use it on site. Another benefit is being able to mix and match source control systems
What would be cool is some peer-to-peer git protocol.
Say I have a local repo, but don't host my own domain. Suppose I could run something which connects to the peer-to-peer rendezvous server, which provides a web presence for my repo.
Then suppose that the clone URL served by this repo would just put the user in contact with my IP address to do the git clone from me directly.
The public server facilitates the contact and provides a presence.
Patching this into git would help. Suppose git supported some htt2p://foo.bar/baz URL which connects to foo.bar, and retrieves a special dynamic resource baz which redirects it to the current location of baz; e.g. git://x.y.z.w/whatever/baz
Been using Phabricator for a few years now at our SaaS, and it is a great system. Recently really went to town with Herald rules etc., as well as connecting it up to AWS CodeCommit + CodePipeline to review and deploy to our staging server from our 'develop' git branches etc. Very granular control over workflow.
Took me a while to get to grips with the 'fun' spelling all over the place though. I know there is a 'serious' mode, but that it way too serious! :)
A few years ago I've used Phabricator as an example for "You can write reasonable code in PHP too." I haven't checked it recently, but at that point it was readable, well structured and commented code.
Unfortunately I never got around installing and using it, as it heavily relies on PHP installed as command line tool (for preparing a change for pre-submit code review).
If you are on a mac, another alternative is EasyGit (https://easygit.me). It is just the git hosting part (i.e. no issues, wikis, etc) but you just pay for the app, there are no on-going subscriptions. EasyGit stores your repos privately on iCloud and it doesn't use any 3rd party servers or analytics. In fact its sandbox doesn't allow any outgoing network connections, apart from talking to iCloud.
I've used Phabricator along side github; you can have it track any external git repository, and use its task tracking and code auditing tools, both of which are much better than github (Github's CI integrations are much better though, fwiw).
The value added by github is primarily that you can get drive-by patches submitted because it's become the tool that so many developers both already know how to use and already have an accountse. Phabricator is much more focused on providing value to set teams working on a project, and it does that really, really well.
I have been using Phabricator for the past couple of years, mainly for code review.
I would point out the very wide feature set for a development team, beyond code hosting and review. A couple of times I was thinking " we should set up a web app with this", only to find it with a few clicks that Phabricator already had it. A few gems:
- pastebin-like app
- Instant chat
- task manager with planning
None of them are top-of-the class, but it's helpful to have them all in the same setup.
How do you mean? Custom statuses can be configured if you visit `/config/edit/maniphest.statuses/`. It's also pretty well documented how to customize statuses there.
I wish they picked up some different names, anyway at the moment gitea has all I need for personal projects.
I wish gitea could be used as a file manager(file explorer), i.e. with folders on the side and I can navigator files and review them easily, sort of like the linux 'ranger' command inside browser, I know this is asking too much.
Gerrit is ugly* and less fully featured, but I love it. It's great for linear master branches. I like the rebase support, it means what I reviewed goes into master, no squashing required. And diffing between rebased patchsets works great and is a killer review feature (most tools get very unhappy when you rebase).
It's only really for code review though. No nice web UI for browsing repositories, no issue tracking, etc. This was a plus for us (very unix-y and easy to integrate with existing systems), but could be seen as a negative.
* The UI is getting better, and you can tweak the CSS, it's pretty simple.
Wikimedia uses both, unfortunately. They each have their advantages, however, Phabricator has a usable interface while Gerrit is one of the worst GUIs I've ever seen.
We use Phabricator at KDE, too, with many hundreds of contributors. Currently mostly for code review and task planning, which we're happy with, outside some nav woes with Pholio. We haven't retired Bugzilla for issue tracking yet, though.
The stack-based workflow in Phabricator makes so much more sense to me than GitHub's branch-and-PR model. I've never understood how people can be productive in GitHub for anything beyond minor changes.
A while back, I chose to migrate my open source projects from GitHub to Phabricator. Having open source projects on GitHub has felt like having an email inbox that's open to the public where there's an expectation to respond to every form of spam. It's been a source of aggravation for me that's taken the fun out of coding on side projects. In my opinion, two out of the three bullet points from Dear GitHub [1] are still unaddressed, but all three are handled by Phabricator.
I looked at GitLab, Bitbucket, and Phabricator. I selected Phabricator because it provides more control for moderation and managing workflows and it's 100% open source [2]. Some examples of ways Phabricator can be customized:
- Create a custom "New Bug Report" form with fields for reproduction steps, expected results, actual results, software version, operating system, etc. Customized forms are more than just a Markdown template. (This is the first bullet point from Dear GitHub.)
- Provide instructions on how to fill out each custom form. You can customize the blurb at the top of each form using Remarkup (similar to Markdown). (This is the third bullet point from Dear GitHub.)
- Keep security issues restricted to a private group until they've been resolved.
- Default user-reported issues to private until they've been triaged. (This could help alleviate the expectation to publicly reply to all spam.)
- Require users to acknowledge the contributing guidelines before submitting a feature request.
- Access to forms can be customized with ACL groups, which can be used to moderate spam by granting or revoking access to features based on users' behavior.
- Require signing a CLA or DCO before submitting a patch. This has first-class support since Phacility requires a CLA for contributions to Phabricator.
- Tasks can have subtypes, such as "feature" and "bug." (You can also do this with "project" tags, but I think Phacility's plan is to use subtypes to extend the custom fields functionality.)
Phabricator also has some nice extras that weren't part of my decision criteria:
- It has a built-in blogging application (Phame), which could be used to publish release notes or important changes (e.g., "Upcoming Breaking Changes in v2.0"). A feed of these news items can be added to a custom dashboard along with commit and task activity to help users keep up to date.
- A built-in polling application (Slowvote) can be used to solicit feedback.
- A Q&A app (Ponder) could be used to help answer users' questions without cluttering the issue tracker. Unfortunately, this app currently lacks some customization and moderation capabilities.
- Paste is for sharing snippets (similar to Gist).
- Flags can be used to bookmark anything you want to remember to come back to with an attached note.
- Pholio is a review tool for mockups. I probably won't need this for my peronsal projects, but I thought it was a cool idea.
Phabricator comes with some trade-offs. The downsides that I've noticed:
- There isn't a good hosted option for open source projects. Phacility provides hosting at $20/user/month, but if you have to pay $20/month for every user that signs up to file an issue, that's financially unviable for an open source project. Personally, I prefer self-hosting, so this isn't an issue for me. I'm mentioning it because I know others will prefer a hosted solution.
- Navigating the UI isn't as smooth out of the box. Some common tasks require an extra click or two compared to GitHub or GitLab. Some of it can be alleviated by customizing the places where you want a direct link. For example, you can add a link to a repository in a project's sidebar. (Projects are independent of repositories, so they're not automatically linked.)
- It's meant to be customized, so it's not as simple as just install it and start using it right away. It takes some time to setup and migrate projects.
- Many of the tools that aren't core functionality (repos, tasks, code review) are MVP quality. This includes the CI tool (Harbormaster) [3], the Q&A app (Ponder), and the human intelligence queue (Nuance) [4] among others.
- Phacility's focus is on enterprise customers, so it's not clear how issues that are unique to open source projects will be prioritized. I haven't seen this be a problem and it's used by some prominent open source projects (FreeBSD, GnuPG, Wikimedia), but it's worth mentioning as a possibility.
I've been playing around with Phabricator on a FreeBSD instance on DigitalOcean. For anyone else considering Phabricator, note that the page response time is greatly affected by the instance type that you choose. A standard droplet on DigitalOcean or any of the VC2 instances on Vultr provided about a 1 second response time (measured by Nginx's $request_time in the logs). A CPU optimized droplet on DigitalOcean provides about a 100 millisecond response time and results in a noticably more responsive UI. I can't speak to the response time on EC2 instances, because I've only tried hosting providers with first-class FreeBSD support.
[3] The documentation for Harbormaster says that all it's really good for is to notify an external CI system (Jenkins, Buildbot, etc) to trigger a build and then to receive build results. It doesn't have any built-in capability of running builds.
[4] Nuance seems like it has potential as a triage queue for user-reported feature requests and bug reports, but it currently lacks the necessary customization.
...and I remember one of the maintainers saying something along the lines of "Some of us don't even compile our code locally anymore. Sometimes you just throw code at Phab and get an email back telling you what you need to fix."
I can't remember in what context that was, but ever since I heard that, I have been wanting to try Phabricator out. I guess this is as good an opportunity as any!
I joined Eventbrite shortly after they moved from Review Board to Phabricator for code review about 4 years ago. It took me a little while to adjust, but once I did I found it to be superior to what Github provided. The CLI provides a nice way to standardize on a workflow company-wide. The UI for composing a review has a few quirks but a lot of functionality, and the patch-based aspect makes it easy to track the evolution of a diff. Herald is very powerful for making sure the right people review a diff. Conduit provided what we need to integrate with Jenkins for CI.
Github has gotten better since then, but I'd still lean toward Phabricator as the better tool for code review, especially for larger projects.
I eventually partially inherited running Phabricator at Eventbrite, and found it overall to be straightforward to configure and troubleshoot. We were only running a single node and using git for repositories, though. Now I'm at Mozilla, and we recently switched from Review Board to Phabricator for Firefox code review. Some of my teammates run the service, and I know that running a multinode setup with mercurial as the repo format has proven challenging.