Some time ago when we were planning the migration, we decided (see #939024: Decide if we should switch to a homemade git viewer instead of cgit or gitweb) to go with the warthog9 fork of gitweb.
At that time, that fork was maintained. Now it seems to not be there anymore (at

AFAIK, we are not modifying warthog9 gitweb fork by ourselves. Actually that code is not public.

Another issue with a lot of information about this, also where this started: #1303208: Firefox gives "Corrupted Content error" on any "raw" or "snapshot" views in Gitweb.

Proposed resolution

This idea is not new: we need to evaluate current alternatives of git web viewers and replace our warthog9 fork of gitweb with it.

Remaining tasks

  • Make a list of current alternatives. An initial list on git wiki. Also see #1003550: Complete homegrown repository viewer
  • Decide on the factors we are going to use to choose the replacement.
    • Code is maintained.
    • It needs to support caching. We can't hit the repository for every web request.
    • It needs to be able to deal with a high number of repos. Specifically we can't have a repo list page that locks up the server. Preferably the ability to disable the listing all together.
    • Add/edit more.
  • Do performance testing, again, define factors to choose.
  • Any other step?

User interface changes

Well, it will be a completely new interfase.
Maybe it worths to write some redirecting rules to avoid linkrot from issues linking gitweb.

Another minor note, any project we choose, it needs to be deployed at the same time as the versioncontrol webviewer plugin that supports it(i.e. make views commit listings point to the right new place).

Comments’s picture

I think we should also look at this list of PHP based repo viewers:

two interesting contenders are IMO:


I've also come across

A very important issue is scalability:

1) There needs to caching. We can't hit the it daemon for every web request.

2) It needs to be able to deal with a high number of repos.’s picture

Created a support issue for gitphp:

and gitlist:

Looking at metrics like maintenance, community involvement etc, I think that both are solutions I could support.

Of course, the real test is to actually install both of them and do a test-drive.

marvil07’s picture

Notice gitphp is GNU GPLv2. gitlist has one custom license, that sounds permissive enough, but I'm bad on reviewing licenses, so an expert look would help.

Update: Sorry for the noise, gitlist is BSD 2-clause license.

neclimdul’s picture

Custom licenses just as a thing are concerning to me. That said, I think that's actually one of the BSD licenses.’s picture

Since we do not intend to redistribute the code, the license is less of an issue.
It is labelled as "new BSD", though.

neclimdul’s picture

Looks to be a modified version of so it actually is custom which... yuck.

neclimdul’s picture

That's fair. We don't so we don't really need to worry much past its free.

marvil07’s picture

Issue summary: View changes

Add some killes comments’s picture

attiks’s picture

I had a quick look and it looks and feels very similar to dc.o’s picture

The gitlist install is here:

the listing times out, how would a repo URL look like?

neclimdul’s picture

Random note, while I'm not really a fan of the contrasts, the current gitweb color scheme was done by some designerly people or something in an issue here on d.o.

It looks pretty great and seems quick. That's promising.

attiks’s picture

#10 it looks like /views.git’s picture is 404. Am I missing some rewrite rule?

greggles’s picture

Re #11 - IIRC the current theme was done by samkottler without asking anyone :)

I don't think we should actually try to carry it forward or block deployment on that. The issues I've seen about it (#1394192: Extreme low contrast on git repository viewer pages and the one referenced there) are actually complaints that it's too low contrast and an unfulfilled promise to fix that. If anything we should style it like

skwashd’s picture

I have made a few contributions to GitList and I'm pretty keen to see it used on d.o. Upstream (Klaus) is easy to work with and he is welcoming of patches and suggestions. One of the basic design decisions is that GitList won't depend on a database backend. There is an upstream issue discussing scalability and performance.

In terms of the license it is the 3 clause BSD license, using the OSI template.

The underlying git library of GitList, gitter, is used in the git module.

realityloop’s picture

Another potential is GitLab, but it'd probably require a lot of changes to be suitable.

marvil07’s picture

A general note: It would be great if there is a client good for our needs that interact with git via libgit2(there is a php extension that wraps it), since most of solutions use git binary directly in execs(gitlist and gitphp both do that). Just to mention, gitweb uses also the git binary(not sure about comparison between perl vs php fork timing), so no hard request really.

Maybe it worths to add this as extra points to choose it:
- A list of directories with git repositories can be provided (instead of only one directory). Based on sdboyer comment.

About that last comment, I saw a multidir topic branch on gitlist upstream repository.

skwashd’s picture

@realityloop gitlab is good, but it aims to be a lightweight open source alternative to github. Installing gitlab isn't the easiest sysadmin task I've ever undertaken. gitlab is rails based which will limit who from the Drupal community can contribute.

neclimdul’s picture

I also maintain a gitlab install and it does have an open authentication api we could use but it does major updates often and dictates the entire git infrastructure. It replaces issues, project creation workflows, pretty much the majority of d.o. It would require a re-envisioning and review of the entire way we handle projects and git from the bottom up. Also, Ruby like skwashd said. Lets leave that for a different issue :)

realityloop’s picture

@skwashd, no disagreements from me there.. it is very nice.. but niceness is not the only deciding factor.

drumm’s picture

cgit is promising.

neclimdul’s picture

At the time I think cgit didn't scale well because it didn't have any sort of caching. That doesn't appear to be the case anymore.

Glancing through the features it doesn't look like they've added supporting for email obfuscation which was a requirement we had and probably still do have.

attiks’s picture

#19 Gitlab does not require you to use their issue management, you can redirect it to d.o.

One problem with gitlab is that it requires authentication even to view the files/commits, but that will be fixed soon.’s picture

Status: Active » Fixed

we've decided that cgit is the programm we want to use as a blocking performance issue was fixed.

greggles’s picture

neclimdul’s picture

I think you're probably right since cgit is running on but is there a discussion for transparency?

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Anonymous’s picture

Issue summary: View changes

Clarify our performance concerns a bit more per the discussions and deployment around the gitweb implementation.

ciss’s picture

For future reference I'd like to add that GitLab blacklists a couple of project names, which would probably pose a serious problem for some major Drupal projects: Link to GitLab code

I noticed this when I was creating a local copy of Services.

Component: » Git