A massive extension of D7387.
This basically allows Phabricator to support hosting Git repositories. In this model, when repositories are edited there's now a new sidebar entry called "Hosting" (in addition to "Tracking") in the repository application. The general workflow is as such:
- Administrator creates a repository with a particular version control type.
- Administrator goes to the "Hosting" tab.
- Administrator sets the path, enables hosting and saves changes.
- Administrator can then set the view (pull) and edit (push) policies for the self-hosted repository.
This diff implements:
- Serving Git repositories over HTTP, using git-http-backend. I believe the pcntl extension is required due to the use of proc_open, but this is required to feed the posted data into git-http-backend's input stream.
- A configuration UI under the Repositories application to allow Administrators to create hosted Git repositories.
- VCS passwords for users. Since Phabricator users don't necessarily login with a username / password combination (because they might be authing with other services such as Google), it was necessary to add support for a "VCS password". A VCS password acts almost identical to the way a Conduit certificate does, except that it's much shorter. When a user goes to pull or push from a Git repository (and the policy is not Public), basic HTTP authorization will be used, and the user is expected to type in their username and VCS password to authorize themselves.
- Push and pull policies. This allows Administrators to restrict who can pull changes and who can push changes from a hosted repository. I've tested it with all various kinds of policies (including custom and project policies) and they are all enforced correctly.
- Initialisation of repository. Pretty simple, but basically if the Administrator enters a directory that does not already exist, the code executes git init --bare for them so they don't need to set anything up. If the directory already exists, it's assumed it's already a valid Git repository.
Although this implementation adds support for Git, there's no reason that Mercurial and Subversion support can't be added using the same CGI-based backend. The hosting already infers the version control type from the repository it's attached to, so to add support for these would only require the implementation of MercurialHTTPServer, SubversionHTTPServer and a few switch statements around the Diffusion serving controller.
Also because screenshots are nice:
{F74368}
{F74370}
{F74376}
{F74378}
{F74380}