> 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...
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.
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.
"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."
...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!
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.
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.
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.
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.
> 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.
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?
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"
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
- 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
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.
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
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.
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.
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.
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.
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.
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.
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.
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! :)
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.
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.
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.
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.
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.
161 comments
[ 3.7 ms ] story [ 205 ms ] threadBut also a bit scary:
> Review others' code with Differential, because they can't be trusted.
Don't take it too seriously.
The software itself is similarly whimsical[0][1]
[0] https://secure.phabricator.com/D7216
[1] https://secure.phabricator.com/rP099695ab615775e5f6d107fba40...
> 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!
They are just embracing the steriotype sarcastically.
"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."
[1] https://secure.phabricator.com/book/phabricator/article/tone...
https://en.wikipedia.org/wiki/Phabricator
Glasgow Haskell Compiler
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!
https://github.com/phacility/phabricator/
Phabricator: https://secure.phabricator.com/source/phabricator/
Clone via https://secure.phabricator.com/source/phabricator.git
It's managed at https://secure.phabricator.com/
The Sourcegraph extension for Phabricator is open source at 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.
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...
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)
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?
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.
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.
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:
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.
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.
https://github.com/isaacs/github/issues/997
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.
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?
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:
https://secure.phabricator.com/D19429
Scroll down to "Stack" - it will display the list of patches depending on each other:
https://i.imgur.com/WTl4B8x.png
We had a big Wiki page for newcomers on how to setup arcanist, and it was not that funny.
Wrapping git is essentially a flawed idea; there are just too many corner cases (rebasing, resetting etc) for a wrapper to handle them all.
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.
The `arc` command did rewrite my branches, ruin my revisions or otherwise do something buggy a handful of times, particularly with `arc update`.
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.
I also remember having some issues with Arcanist on Windows.
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....
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.
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.
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.
I hope they will add a "git push"-based workflow to accommodate this use case.
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?
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.
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.
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
You need to throw quite a lot of hardware at it for acceptable performance.
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.
Their front-end is open source: https://github.com/buildkite/frontend
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.
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.
- Job retries!
- Docs are pretty dope
- Annotate is very cool (https://buildkite.com/docs/agent/v3/cli-annotate)
- Block step. Useful for confirming before deploy or something.
- Pretty cheap (unlimited builds, you pay per user). Honestly, I would love to pay them more.
Cons of buildkite:
- It's not free, so Gitlab is hard to beat on that.
- Gitlab works fine for 99% of the use case.
Take a look at their changelog, a bunch of screenshots and you'll see their development pace =)
https://buildkite.com/changelog
"Merge branch 'dev-hello' into 'master'"
Phabricator makes it so that the squashed commit summary is the summary of the diff (merge request)
But like the parent said, it's not nearly as fancy.
With Github, you'll end up with a history like:
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).
Gitea is written in Go. I used it for a small self hosted instance; it's fast for me, but I wonder if it scales well.
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.
Those who still compare are living in the past.
Is Gitea any better?
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.
Still, that doesn’t help much. Gitea just does a lot less than Gitlab behind the scenes.
See https://gitlab.com/gitlab-org/gitlab-ce/graphs/master/charts for the core server.
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
[2] https://phab.mercurial-scm.org/
[3] https://discourse.phabricator-community.org/
Last time I heard, multiple teams at Facebook are using it.
https://phab.lubuntu.me/
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! :)
Agreed that serious business mode is slightly too serious. I miss the acsii dragon when pushes were denied by heralds.
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.
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.
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.