I seem to be in the minority, but I found Phabricator to be a very unpleasant code review experience. Because it doesn’t speak git natively, it would frequently just spew commits from an arbitrary branch into PRs, for no apparent reason. And because reviews weren’t based on actual git branches, people could throw patches that you couldn’t actually build into it. Awful, awful thing.
You need to buy into the phab workflow which is diff based not branch based. Once you accept that the experience is awesome. For many people they don’t understand git enough unfortunately to appreciate the workflow not that it doesn’t have its flaws but it has worked amazingly on both large and small teams for me
When you do code review, you are approving a patch: the difference between the old code and the new code.
With GitHub / Gitlab you push a branch and tell the tool to generate the diff by comparing two branches.
With Phabricator you make the patch locally and push the patch directly for review. There is fooling to help you do this, as well as to pull and apply patches.
This decouples Phabricator from your VCS tool and is partly a legacy of a time when Facebook had some engineers (and the central repo) using Subversion, and others using git. Even when everyone is using git, there are still 1001 different workflows which people use, so Phabricator ignores all that and zeroes in on the relevant bit: the code change you are proposing.
It is more precise, imho. At its heart, code review is a human process for discussing the merits of a document that happens to be structured in the form of @@, + and - symbols. You can bolt other tools onto the side of it for CI/CD, linting, etc., but the human readable code change and social interaction parts are still front and centre.
Ah, but you're not really approving a patch. You're approving a series of changes, and specifically their motivations. That's why git history is important. Complex code is meaningless without an understanding of what motivates it.
The reviewable unit being as atomic as the version control unit has many positive knock-on effects. For example, if you merge numerous commits and keep the commit information, often times you will wind up with commits that have partial or complete breakage, which can seriously be a pain when someone is trying to triage a regression, for example.
There is not one exact correct philosophy about how small the atomic unit is or what constitutes too much work, but the general wisdom is something to the order of "do one thing."
I believe a PR should "do one thing," so PRs with multiple commits should be safe to flatten, else they likely contain too much. Of all of the things Google is rightly criticized for, their methodologies towards code review are pretty good and this is more or less what it felt like working in pseudo-Perforce. What if you needed multiple changes? Well, it was certainly more cumbersome than needed, but serieses work great here. Not only that, but patch serieses are already well established in the software engineering canon! Plenty of projects have accepted patch serieses over mailing lists for decades.
I know many people have seen Github-style workflows work pretty well and so are unlikely to be receptive to the idea that some of the fundamentals could be wrong, but my advice is please consider it. It's not like there's one exactly correct way to handle merging changes, but I've found that the process of focusing on atomic sets of changes individually has improved my discipline as a software engineer. It may be a bit too wanky to call it "enlightening," but it's pretty close.
Each patch has a form attached to it where you outline a title, description (including your motivation), and a test plan. These are mapped into the eventual commit message.
Individual, atomic ideas are expressed as a single diff which maps to a single commit. Representing one idea as multiple commits is discouraged, though Phabricator does keep its own history of how a patch evolves should you ever need to refer to it.
The words you're saying are correct in isolation, but in context of the thing you're replying to,
1) At issue here is not (just) the portion of the history in the changes under review, but the choice of where that history starts. That's what the commenters above mean by "diff based" and "branch based". If I start a Git branch on HEAD@{yesterday}, and HEAD@{today} renames a function that I'm using, then there is a semantic difference between approving solely my changes and approving my branch with information about its branch point. And in a workflow where only my changes are under review without further history, it's entirely possible for me to submit a set of changes that simply don't sensibly apply to a specific target branch, because the tooling did not reflect that my source branch is different.
Note that all of this true even if "my changes" takes the form of a series of patches, such as a [PATCH m/n] series posted to a mailing list using an LKML-style workflow!
2) All that said, I do not know of any tool that makes it particularly easy to manage both of these pieces of history in a review. All the Git-based review tools I've seen (GitHub, GitLab, Gitea, etc.) make it fairly easy to see where the remainder of history is, view the final state of a modified file with history (e.g., it's easy to see the blame view of a modified file), etc. But they don't default to showing you the commit-by-commit history; they show you the diff between the beginning and end for review. Meanwhile, the [PATCH m/n] workflow (e.g., git format-patch, including Sourcehut's tooling on top) is in fact much closer to the Phabricator one in spirit; while it does permit you to see the commit-by-commit history, it has no idea what the history before the first patch is, and it's difficult to even tell if a patch got merged!
So in a practical sense, there isn't really a tool that lets you work with full history. You have to make some form of compromise. In practice, I think the most common compromise is to constrain yourself to making one commit per code review; if the history is complex enough to really want commit-by-commit review, you're probably best off making multiple reviews anyway.
(You might object - what if the code doesn't build or work right between your first and second commits? But that's already a bad place to be, because ordinary git bisect will have false build failures if it lands between those two points. There is git bisect --first-parent, but first, your project had better be doing --no-ff merges to make this useful, and second, the effect of it is to ignore the detailed history, so if you're going to ask people to do that, why burden them with the detailed history in the first place?)
The other compromise here, weirdly enough, is Phabricator itself. Because Phabricator reviews diffs and not branches, you can submit two independent code reviews for two dependent commits, and Phabricator won't care. If you try to do this with any of the pull-request-style tools, the second code review will include both changes because they know history; Phabricator doesn't, and it will show just the second change if all you sent it is "arc diff HEAD^". And then you can "arc land" those on your own. (But you have to be careful about getting the order right, because, again, Phabricator doesn't know how to do that for you.)
Phabricator works with patches, not branches. Kind of like how Linux kernel development works, except instead of attaching a patch file in an email and sending to a mailing list, the patch gets uploaded via a CLI tool (arc) and reviewed in a web interface.
jira is a project tracking tool, and has no native code review capabilities. It can be plugged into various suites of software that does have code review capabilities (such as bitbucket (both cloud and on-premises)), and display links to those software suites.
I am very happy to see this. Phabricator is an incredibly well written and deeply thought-out tool (even if people may disagree with some of its philosophies regarding e.g. patches and code review) and it had a tremendous influence on my career and the way I thought about managing and contributing to software projects. I say that as someone with a few patches in Phabricator itself.
I hope Phorge is just as successful and retains that levity and unique polish that Phab had; looks like a lot of the old guard contributors are around as part of this, so I'm very hopeful. Maybe I should spin up some of my old patches for things like WebAuthn support and re-submit them...
Me too. I was just looking for something last week as a good on-prem solution. Phabricator was the first thing I looked at but quickly discovered it was "dead."
For what it is worth, GitLab and GitHub both do an absolutely terrible job of selling to someone where cloud isn't an option.
If you go to the pricing page[0] and click the “Buy GitLab <tier>” you’re interested in purchasing (Premium or Ultimate), a pop up will appear and you can purchase an on-prem license by clicking the “Purchase self-managed” button.
Congrats on launching! I'm personally a huge fan of pharicator, having used it at FB and realizing how much I missed stacking, the review queue, and herald after leaving.
We built Graphite (https://graphite.dev) to bring a lot of that goodness to developers still stuck on Github for one reason or another (after finding that we ourselves were locked into GH). And I'm glad others are championing that as well.
I loved Phabricator. It’s the system that made the most sense to me, with no real issues. I was shocked when I saw that no more work was going to be done with it and I’m glad to see someone pick it up!
I never got GitHub's PR model. Maintaining separate branches of a single codebase is something I want to do approximately never, and a single commit is the right atom for code review.
Thus, I find Phabricator to be intuitive in a way that branch-based workflows never were.
When we develop software task by task, feature by feature, some (actually, most) features are too big to be represented by a single commit. This is because we need code versions history to understand those changes in the future, even if the author is not around, and wrapping my head around +5000/-3000 diff is very complex task by itself. On the other hand, in most CD systems pushing commit to master branch triggers a new version deploy. So we are doing small atomic "always green" changes in a separate branch, and then merge them all at once into master branch.
Has your team considered using feature flags? For large changes that can span weeks of effort, being able to PR and get small portions in to main branch and then "flip the switch" at the end usually works out better for us than "okay our feature branch is done but now we have to catch it back up to everything that happened in the meantime from the past few weeks."
We are thinking about it. There are still some gray zones like database migrations. It is easier to daily rebase big feature branches onto master, IMO.
Exciting stuff! Phabricator was one of the better project/dev management systems I've interacted with and I'm glad to see developer energy behind maintaining and improving it!
I revisited the site regularly and honestly never thought they'd make it to 1.0. We were using Phabricator at work and had to migrate (Gitlab) after the project was sunset. I still miss many features of Phabricator although it's not without flaws and quite idiosyncratic. I wish the Phorge people best luck!
It would have been nice to get some commitments from the bigger Phabricator users before going public, so I could read this and see oh projects x, y, and z are going to be using Phorge! But maybe they wouldn't until they see what kind of project it's going to turn out to be..
How does Phorge/Phabricator compare to other code management tools like Gitea or GitLab in terms of resource requirements? Can it, e.g., run along side other apps on a single-board computer, or does it take more system resources than this?
It's been open source for many years. Not sure if it was ever open source.
The twist is that it was developed by a commercial company called Phacility, and their monetisation model was that you had to pay to be able to submit bug reports or even create an account on their Phabricator instance. As a result I don't think they have many external developers.
They packed up shop a few months ago. Phorge was created to continue development.
Yeah, AFAIR the basic realization at some point was that most freely submitted user reports were either of low quality, part of something that wasn't on the near-term roadmap, or part of something to be addressed more broadly in the near term anyway, so the value of them got lower over time. It kind of happens in every FOSS project to some extent; early on in a project's life, user feedback is almost always useful to help hone your direction and future scope, but at a certain point, that value diminishes once you know the contours of what your users want, competitors do, what timeline you can complete them in, etc. Phabricator and its vision were very stable. Evan at some point moved to a support-only model IIRC because he didn't believe the value versus support burden justified the alternative anymore.
(And actually, you could still submit bugs and comments generally speaking if you were an "old school" contributor who had generally high-value contributions; I was in this category and never had my permissions pulled, and dropped by from time to time to submit things -- but that was the exception and not the rule.)
Having more than one option should be generally seen as a good thing. I don’t think an open source project needs to justify its existence if you dont want to take the time to learn what it actually does
Given that Github is now owned by Microsoft who can pull your identity or shut down your repository on a whim, being an open source GitHub issues is plenty enough, no?
Having a self-hosted solution inside company's security perimeter is nice by itself. This is why I use GitLab on all my projects since I don't remember when. Also, the GitHub way of doing things is not universally liked, so having an alternative is always welcome.
I used Phabricator a long time ago before we eventually moved to Github due to a handful of blocking issues with the `arc` tool, and CircleCI only supporting Github (this was even pre-circle 2.0 days).
I really, really liked Phabricator and would happily have replaced Jira + Confluence + GitHub with Phorge if I was starting somewhere from scratch.
Line height issues. Odd icons. Weird verbiage. Swapping ‘ph’ for ‘f’. A declaration the author is a ‘User’, with no projects, and a “tada” token (whatever that is).
Phab users may feel right at home. Unfortunately.
Yes, my phab experience has been underwhelming and quite confusing. Each piece functions nominally, but is a miserable cacophony of integration. I hope the leaders of this project take some creative liberties with the vision and organization. It’s needed - lest a full restart of this thinking take the reins.
I think some people are angry that you admonish the project. However, those are some valid criticisms from someone who clearly was frustrated by the previous incarnation of this project.
