
Phabricator – GitHub Alternative written in PHP used by the Wikimedia Foundation - TekMol
https://phabricator.wikimedia.org/
======
sciurus
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.

~~~
dcosson
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.

~~~
sciurus
"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.

~~~
Nullabillity
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.

------
maktouch
We moved from Gitlab to Phab a year ago.

Context:

\- 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

~~~
TekMol

        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.

~~~
u801e
> 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).

~~~
unfunco
Use squash and merge instead. It's built right into GitHub, that way your
history will look like:

    
    
        Implement feature A
        Implement feature B

~~~
u801e
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.

------
sirn
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_rev...](https://secure.phabricator.com/phame/post/view/766/write_review_merge_publish_phabricator_review_workflow/)

~~~
lima
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
> 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
> 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.

~~~
WhyNotHugo
> 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.

~~~
u801e
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.

~~~
zbentley
> 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.

~~~
u801e
> Why would you do that, in general?

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.

------
drewg123
We use it for FreeBSD.

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.

~~~
Izkata
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.

------
epriest
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.

~~~
acidburnNSA
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.

What should I do?

~~~
kridsdale1
Replace your IT team.

~~~
devhead
...educate your IT team.

------
vemv
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.

~~~
lima
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.

~~~
ianamartin
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.

------
kemayo
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.

~~~
20after4
Sad but true.

------
lorenzfx
Better link:
[https://phacility.com/phabricator/](https://phacility.com/phabricator/)

~~~
Sujan
Better link indeed.

But also a bit scary:

> Review others' code with Differential, because they can't be trusted.

~~~
brobdingnagians
"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...

~~~
Klathmon
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.

------
donaldguy
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

------
mhoad
Wasn't this originally developed in-house in Facebook and still their go-to
solution?

~~~
samcday
Yep, but apparently the original author left Facebook to continue working on
Phabricator.

[https://en.wikipedia.org/wiki/Phabricator](https://en.wikipedia.org/wiki/Phabricator)

------
cordite
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.

------
m4r71n
Another option is the one created by the Fedora project:
[https://pagure.io/pagure](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.

------
smakhtin
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.

------
peremen
Also used by KDE: [https://phabricator.kde.org/](https://phabricator.kde.org/)

~~~
seba_dos1
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.

------
sqs
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.

The Sourcegraph extension for Phabricator is open source at
[https://github.com/sourcegraph/phabricator-
extension](https://github.com/sourcegraph/phabricator-extension).

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.

~~~
ahartmetz
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.

~~~
lifeisstillgood
To be fair (s)he said she was the CEO and I would always assume that means
paid for - "core maintainer" and I would have agreed with you.

------
mrmattyboy
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.

~~~
colonelpopcorn
All the docs I've read on Phabricator seem to imply that this is by design.

------
neandrake
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.

[1] [https://secure.phabricator.com](https://secure.phabricator.com)

[2] [https://phab.mercurial-scm.org/](https://phab.mercurial-scm.org/)

[3] [https://discourse.phabricator-
community.org/](https://discourse.phabricator-community.org/)

~~~
lima
> _I don 't know if Facebook uses Phabricator still_

Last time I heard, multiple teams at Facebook are using it.

~~~
mic47
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.

------
sdi9usu8dfu8f
Also used by llvm:
[https://llvm.org/docs/Phabricator.html](https://llvm.org/docs/Phabricator.html)

------
kazinator
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

~~~
mkirklions
Im not a fan of blockchain for most applications, but couldnt this be one?

People that want to host code on the internet just need to pay the fee to put
it on the internet. Once its there, anyone can download it.

Hopefully the fee is trivial, I'm guessing this wouldnt be a problem since it
would be less popular than Bitcoin.

~~~
cobalt
git is basically a block chain by design. Both it and bitcoin use variants of
a merkle tree

------
cyberferret
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! :)

~~~
acidburnNSA
You can at least change the spelling on the main page to Tasks and Bugs, Code
Review, etc.

Agreed that serious business mode is slightly too serious. I miss the acsii
dragon when pushes were denied by heralds.

------
doubleunplussed
And it supports mercurial!

------
isoos
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).

------
pdpi
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.

------
verigit
If you are on a mac, another alternative is EasyGit
([https://easygit.me](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.

Disclaimer: This is my app and btw I'm running a WWDC promotion and you can
download it for free till Friday:
[https://itunes.apple.com/us/app/easygit/id1228242832?mt=12](https://itunes.apple.com/us/app/easygit/id1228242832?mt=12)

------
soulnothing
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

------
rimliu
You will probably not enjoy it if you like pull requests.

------
aidenn0
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.

------
ChankeyPathak
HN discussion on available alternatives to GitHub.
[https://news.ycombinator.com/item?id=17241487](https://news.ycombinator.com/item?id=17241487)

------
salicideblock
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.

------
littledot5566
I really wish Phabricator Tasks could have custom statuses and not just
"Open/Close". This would make the Workboard feature so much more useful.

~~~
neandrake
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.

------
thinkingemote
Phabricator is used extensively by Wikimedia, Wikipedia etc

------
partycoder
If the main focus is code reviewing, I would rather try Gerrit / Gitiles
instead.

It is less invasive, doesn't include issue tracking.

------
trasz
Also used by FreeBSD
([http://reviews.freebsd.org](http://reviews.freebsd.org)).

------
ausjke
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.

------
navd
Any opinions on Phabricator vs Gerrit? I'm currently working on a project
using the latter.

~~~
guitarbill
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.

------
sho_hn
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.

------
bsimpson
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.

------
davidcuddeback
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.

[1] [https://github.com/dear-github/dear-github](https://github.com/dear-
github/dear-github)

[2] "No special editions. Everything included, open and free"
([https://phacility.com/phabricator/](https://phacility.com/phabricator/)).

[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.

(Edited for formatting.)

------
indescions_2018
Lubuntu team uses it as well:

[https://phab.lubuntu.me/](https://phab.lubuntu.me/)

------
amaccuish
The humour of the front page got me interested. Looks good (y)

------
lamby
"Set sail for adventure..."

------
stealthmodeclan
Also used by GHC.

Glasgow Haskell Compiler

~~~
kqr
...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!

------
gitgud
A little ironic that the source code is managed on GitHub (9k stars)

[https://github.com/phacility/phabricator/](https://github.com/phacility/phabricator/)

~~~
timendum
It's definitively a mirror, the repositories are at
[https://secure.phabricator.com/diffusion/](https://secure.phabricator.com/diffusion/)

Phabricator:
[https://secure.phabricator.com/source/phabricator/](https://secure.phabricator.com/source/phabricator/)

Clone via
[https://secure.phabricator.com/source/phabricator.git](https://secure.phabricator.com/source/phabricator.git)

~~~
gitgud
Yeah ok, that makes sense now

