featureful git web application for lamp stack

Question

I am looking for an application that provides some of the basic features of familiar Git web interfaces, such as GitHub, GitLab, and Bitbucket, though I have no requirement for the more advanced features of these systems, such as pull requests and issue tracking.

My limitation is that I use a shared hosting service, which is predominately a LAMP stack (Linux, Apache, MySql/MariaDB, PHP) administrated through a Plesk instance. The service also supports a few other features, such as single-user SSH access, Python and Ruby interpreters, and so on. Although I even have access to GCC, the environment is essentially a minimal Linux stack. As a large number of Web applications can run in this environment, it is in widespread use for low-maintenance, economical hosting solutions.

Writing to system directories and adding shared libraries, however, are impossible. Managing system users is also impossible, as the entire service includes only one user to the shared system.

The restrictive authentication methods of standard Git server components has been a major obstacle for finding a compatible software package.

The requirements thus are summarized:

• Implementation in PHP or as a CGI script runnable with standard Posix components (e.g. Perl, Python, Ruby etc.), such that requests can be dispatched by a standard Apache deployment.
• Graphical web front-end for initializing and browsing repositories, managing users, etc.
• HTTP interface for Git clients, integrated with internal user and credential management, instead of relying on system or web-server credentialing, as in the case for standard Git SSH and HTTP server components.
• Independent of any standalone server process other than the system instance of Apache, which would dispatch individual requests to the application by invoking a new process in a CGI context.

Most applications either have a much simpler feature set (e.g. git-web, GitList), or are designed for installation as a system application (e.g. GitLab, Gogs). Note, please, that even if an application can hypothetically install in user directories, I prefer to consider only applications that solidly support this particular case.

Have I overlooked any options that might be promising solutions to my needs?

Answer 1

Although I was hoping for some suggestions from the community, I did discover two promising candidates since asking the original question. One proved to be viable, the other not so.

Viable candidate

GitPrep is the "little engine that could" of Git graphical web interfaces. It fancies itself as a "GitHub clone" for embedded deployments, and largely achieves that lofty objective, despite being developed by a small team. It has no commercial ties, and development was very active for many years, until it slowed several years ago, presumably because the desired feature set and stability were realized. Maintenance commits have since occurred occasionally.

It is written in Perl, on the Mojolicious web engine, at a time when I thought that Perl was dead for all but trivial uses. While most projects of this type run only as a standalone application, a constraint represented as a convenience, GitPrep is instead deployed as a CGI/FastCGI application, and also ships with a lightweight standalone wrapper for deployments outside of a web-server instance. It has minimal system dependencies, which include a recent release of Perl 5, and of course Git itself. Setup is straightforward and largely automated. It does not require administrative access and requires only minimal administrative skills. For me, the automatic tests reported problems, but the application runs correctly anyway. Function appears rather stable, with a few scattered glitches.

Its major strength is also its major weakness, in my view. Like its inspiration, GitHub, it packages a handful of valuable features into a compact space, but its deep resemblance, in almost every respect, to the source of its inspiration also limits its potential to add further capabilities, character, and value to the space of embedded deployments. Now that the groundwork is laid, it could seek to realize this potential by forging its own identity.

GitPrep has not received much attention, with much of the commentary being unfairly critical of its smaller feature set, as though to presume that the software were intended for the space of large commercial projects. Perhaps my mentioning it will have some use in helping it get the interest is deserves.

Nonviable candidate

I was excited to learn about Phabricator. Derived from a project started at Facebook, it is developed by a commercial venture, which obtains revenue from selling a hosted service, but which releases the entire platform as an open-source package for embedded deployments.

It targets the LAMP stack, and also has minimal further dependencies. It has a large feature set, which emphasizes scalability for larger teams, and much of which is not needed for small or individual uses. What may be more useful in either case is that it equally supports Subversion and Mercurial repositories, as well as Git, and operates with remote repositories as well as those managed internally. It installs entirely inside of a web server, making it seem like a viable option for shared hosting.

However, currently shared hosting targets are not supported, for unclear reasons. What is clear is that no workaround is available. The installer requires administrative access to a MySQL cluster, in order to create a large, unspecified number of separate databases, each with a prescribed name. It cannot operate inside of a single pre-existing database, which is a requirement for shared hosting. A single database per application is of course also the standard and established design principle for database applications, which is represented in the design of most database management systems.

It would be interesting to keep an eye on this project, especially to see whether more flexibility is added with respect to deployment targets. Unfortunately, the staff was not receptive to this possibility in my recent inquiry, and since the company's revenue stream is potentially hurt by facilitating a larger number of embedded deployments, such changes might not come soon.