First, features:

• Support for specifying a project list file, rather than listing out projects manually in the config file. It was done with Gitosis in mind, but will work with any flat file of projects. Thanks to Jonathan Kolb
• Switch to using GeSHi’s CSS mode to make highlighted blob support more lightweight (less traffic)
• Basic blame support. This is available as a link on any blob page to see the blame view for that file (if there’s somewhere else you would like the link, let me know). This is just the standard git blame algorithm, it doesn’t do any of the more fancy pickaxe stuff such as added/deleted lines. Also, currently blame view does not do any syntax highlighting with GeSHi – it’s actually trickier than it sounds because of the way GeSHi works
• Smarty and GeSHi are now included with GitPHP so you don’t have to install it yourself – more on this below

Bugfixes:

• Fix a bug that prevented filesearch from working, thanks to Christiaan Kortekaas
• Fix a bug that caused RSS to generate an error for a project with a small number of commits, thanks to Zaran
• Fix a security hole that allowed users to access any project using the p= parameter, even if it was not listed in the project list. Thanks to Jonathan Kolb

Just a note that some files have been moved around for organizational purposes (in particular, images, CSS, and documentation was moved into their own directories, rather than having them float around in the root), so if you’re upgrading, I would backup your config, delete your current install, then install the new version and replace your config so you don’t have unused files hanging around.

As always, release is on the GitPHP page, and bugs can be reported on Mantis.

For future releases, I am aiming for making everyone’s lives easier with some significant changes. In case you’re a tl;dr person, I will bold key points.

Ease of setup
Currently, GitPHP is not easy to setup. You have to read through a long list of configuration options to get things set up, and you have to install smarty on your own, as well as (if you choose) GeSHi. One thing I’ve discovered, after developing commercial software for a year and a half, is that users don’t read instructions. Despite the fact that I’ve written up a README and explained how to do everything, I’m willing to bet there’s been at least one user that tried to install GitPHP, gotten an error that Smarty isn’t found, then gave up. There was even a fork by someone at one time to remove Smarty support. While I have nothing against forks (I’ve seen at least two forks of GitPHP), I couldn’t really understand why someone would want to remove support for Smarty other than the fact that they didn’t want to have to install it themselves as a dependency. If it’s completely internal to the project, it shouldn’t matter whether you’re using smarty or any other template engine. Besides, Smarty is what provides the caching framework that GitPHP uses.
Previously, I always excluded Smarty and GeSHi because I wanted to keep the package lightweight and allow users to choose what versions they wanted to use (in keeping with Unix style). But since this has led to so much confusion for people, I am now including Smarty with GitPHP (in a ‘lib/’ directory). The example config now points to this smarty install by default. GeSHi is also included in this lib directory, and the example config points to this copy and enables GeSHi by default. Eventually the config options will be removed from the example config, or at least moved away from the main config options. The config options themselves will probably never go away because it’s useful to be able to point to a shared smarty or geshi instance, but at least they’ll be hidden away from the average user and not be required options.
This is probably the best I can do as far as making Smarty transparent. You still need to set templates_c writable by the server because I can’t control permissions on a directory in a tarball.
I will also be evaluating other configuration options for removal in the future from the example config so you don’t have to read over them if I can provide reasonable defaults. No current options will be removed completely, but like Smarty and GeSHi, they may be hidden away by default. The only config option a user must be required to set up is the project root, because I’m not psychic and I don’t know where you’ve made your projects available.

Ease of maintainability
For the past few years, I’ve hated the GitPHP codebase. GitPHP was written in 2005, back when PHP 4 was still commonplace and PHP 5 was not widely deployed for everyone. So at the time, when I started the project, I wrote it as a very large collection of functions (like a C program), because:

• I wanted it to work on PHP4, which most people (including me) were still using at the time
• I was basing it on Gitweb, which is a single perl file. Perl is not exactly organized, and neither was the Gitweb code. (it still isn’t)
• I was still relatively inexperienced with PHP

However, after five years of changes and tweaking, it’s ended up as a train wreck of spaghetti code. I’ve found myself having to violate the DRY (don’t repeat yourself) principle all over the place just to fix simple bugs, and adding a new feature (blame) was a lot messier than it should have been.
Therefore, I am going to be rewriting all the internal code of GitPHP. Because PHP 5 is widespread now (and PHP 4 is end of life), I can take advantage of PHP 5’s much better (though still not quite perfect) object oriented programming support. This means I can use things inherent to object oriented programming like patterns, code reuse, and loading data by git commands only on demand and caching it in objects to minimize the number of git commands executed.
For people looking at the code (me, and maybe anyone doing a bugfix), this will eventually make your job a lot easier. For users, what this means is that at some point – maybe even as soon as the next release – GitPHP will stop working on PHP 4. I’ve already started, but as a rewrite of pretty much the entire application, it’s going to take quite a while. Depending on how long it takes me, it’s possible that the next release will have a half-half codebase. We’ll see.

Ease of use
The current GitPHP interface is based on Gitweb (obviously). While the gitweb interface works fairly well, there are also places where I’ve found using it to be fairly clumsy.
Also, currently GitPHP uses no javascript for browser compatibility reasons. However, there have been a number of times where I would have liked to use javascript to make life easier for someone using the site. As compatibility between browsers gets better, using javascript in a compatible but also degradable way looks more and more feasible, so I will be looking into ways to make the user interface of GitPHP more flexible in the future – implementing javascript, and partially departing from the Gitweb look. It’s not going to look like a radically different application or anything, but it will probably stop adhering so closely to Gitweb. This is a long term thing though; I probably won’t start this until I’ve at least addressed the other two points, rewriting the core and making the install easier.

Changes:

• Security fix: A user could perform a directory traversal using a crafted relative path (using .. and a null byte) to read an arbitrary file on the server
• Allow display of clone/push urls for projects

Release is on the GitPHP page, and bugs can be reported on Mantis.

Changes:

• PHP 5.3 fixes (avoid assigning object references, switch to perl compatible regular expressions since the posix extended regex functions are deprecated) – patch by Khee Chin
• On the project list, the project description links to the project page like gitweb – patch by Khee Chin
• Packed ref support – based on work by Khee Chin
• Fixed display of non-english UTF-8 characters (they used to appear garbled)
• Disabled smarty’s template compile check in releases for a small performance boost (smarty used to constantly check if a template was modified, something that’s unnecessary in releases put into production and is only useful during development)

Release is on the GitPHP page, and bugs can be reported on Mantis.

Major features:
Caching
By request… GitPHP now makes use of Smarty caching to cache the output of any action – this includes all pages, blobs, diffs, searches, and even snapshots. There are new cache options in the example config, so make sure you copy them into your existing config to turn on caching and choose your desired cache lifetime.
GitPHP will attempt to automatically expire the cache appropriately. When a page is loaded for a project, it will expire any cached pages that are older than the most recent commit to the project, on any head. This ensures that users are always seeing the proper information for the project, and not seeing outdated information due to cached pages that have been hanging around too long. This check is a tiny performance hit, but is trivial compared to the gain of caching. You can turn this off if you want to skip the check, but you should beware that users could be seeing mixes of old and new data depending on what has and hasn’t been cached. You can also turn this off if commits are coming in so quickly that the cache is constantly being expired, but if you’re doing your git workflow properly (occasionally pushing groups of commits from a private to a public repository) this should not be the case.
If you ever run into cache issues, you can go to

http://yourserver.com/gitphp/index.php?a=expire

to forcefully expire everything in the cache. You will also need to do this if you change any config options. This is not linked anywhere from the interface since it’s an administrative action; you have to type it in yourself.

Unified templates
I realized that the way I was handling templates previously was hampering customizability. I had template pieces that got displayed in order… for example, the header template, then the nav template, then the paging prev/next template, then the log template, then the footer template… you get the idea. While each of those templates was customizable, I was still enforcing the order of elements – eg the nav always had to be first, before the content.
Now, each page’s template is a single file that displays everything. This allows full flexibility to customize the template any way you want – anything can now be moved anywhere on the page. (It also made implementing caching easier)
This is a very slight performance degradation compared to previous versions, because there are times where the code will have to loop twice – once to parse data, then another time to output it in the template. However, caching completely eliminates this difference (and then some).

Minor features:

• Debugging can be turned on with a new config option. This is probably not useful for most users. However, this will display the execution time of a given page at the bottom, so it can be useful for checking how much time a particular action on a repository takes – although naturally, this is influenced by the cache

Bugfixes:

• The “performance fix” introduced in version 0.0.6 made use of the –skip parameter for revision lists. This parameter was introduced in git 1.5.0, which means that revision browsing was effectively broken for any version of git lower than that. (It was broken on this site… dreamhost runs git 1.4.4.4). I have now made it backwards compatible; gitphp will use the faster –skip parameter if it detects you are running git 1.5.0 or greater, and transparently fall back to the old method if you are not. I refuse to be like gitweb and require the gitweb and git versions to both be the most current; I’ll always support old versions to the best of my ability, so please report bugs on Mantis if you have any issues with old versions.
• Whitespace is preserved on non-html pages (such as opml and rss) for readability
• The blob page now properly displays ref tags for HEAD
• Pages now properly report their charset to the browser as UTF-8
• Pages do not use the output buffer anymore. It is unnecessary if you are using caching, and avoids issues where the snapshot is larger than the output buffer and gets truncated

Internationalization is not in this release. Technically it is done, but no one showed interest in translating into another language. Abstracted and tokenized strings, without any other languages besides English, are just an unnecessary performance hit. The code still exists in the branch i18n-manual, but I’m not going to merge the feature until there’s a reason to, meaning there’s at least one other language to offer.

As always, the release is on the GitPHP page, and bugs can be reported on Mantis.

There are three small(-ish) changes:

• Readable names in diffs (I changed some of these last release but didn’t get all of them)
• Treeview paths now have clickable links for each folder, so you can jump to any parent directory easily
• Ref icons appear in more places by commit titles

I wouldn’t normally do a release this small, but I’m planning on making some major changes to the way templates work (internally, not really much difference visible to users), which is a change that could potentially take a while, so I wanted to get these fixes out and released before I started anything.

As always, packages are available from the GitPHP page, and bugs can be reported by Mantis.

git clone http://www.xiphux.com/git/gentoo.git /usr/local/portage/xiphux

And adding to your make.conf:
PORTDIR_OVERLAY="/usr/local/portage/xiphux"

The ebuild will handle changing the permissions of templates_c and will copy gitphp.conf.php.example to gitphp.conf.php, and will allow you to merge changes to gitphp.conf.php using etc-update when you upgrade.

Unfortunately, I don’t know of a good way to make webapp-config handle the templates_c directory, so when you unmerge the package you have to get rid of the templates_c directory manually (since by then the webserver has generated the compiled files in there, so webapp-config won’t remove it since it’s not empty).

There’s a README file included now. I’m no master technical writer, but it should explain what you need to know.

The config file is no longer distributed directly; it is distributed as an example file so you don’t overwrite your old config when upgrading. I recommend checking for new options that have been added to the example config that you may not have in your main config.

Changes in this release:

• Mime type support, to display images inline. When viewing a blob, if it recognizes the mime type as an image, it will embed and display the image using a data uri rather than dumping the binary content. This is only done for images, though – there isn’t a good way to embed other binary file formats. It supports pecl-fileinfo (which was merged into PHP in 5.3), the “file” command on *nix machines, and just checking the file extension. Based on work by Trevino
• Searching of commit logs, authors, committers, filenames, and file contents
• Blob diffs show the filenames instead of the hashes to be more readable
• Fixed blank entries that appeared at the end of the log/shortlog
• Added a link to the tree from the main project list
• Some performance fixes for projects with many commits
• Snapshots can be sent as tar.gz or zip
• templates_c directory created for you already, just change the permissions
• Single tag view page… somehow I forgot this a long time ago and never noticed since I don’t usually annotate my tags

As usual, release is on the GitPHP page, the repository can be browsed here, and bugs / enhancement suggestions can be reported on Mantis.

I am working on setting up a gentoo portage overlay with a gitphp ebuild, which will install gitphp and handle stuff for you, like the templates_c permissions and config file management using etc-update.

• Mime type support.  When viewing a blob, if it recognizes the mime type as an image, it will embed and display the image using a data uri rather than dumping the binary content.  This is only done for images, though – there isn’t a good way to embed other binary file formats.  It supports pecl-fileinfo (which was merged into PHP in 5.3), the “file” command on *nix machines, and just checking the file extension.  Based on work by Trevino
• Searching of commit logs, authors, committers, filenames, and file contents
• Blob diffs show the filenames instead of the hashes to be more readable
• Fixed blank entries that appeared at the end of the log/shortlog
• Added a link to the tree from the main project list
• Some performance fixes for projects with many commits
• Snapshots can be sent as tar.gz now
• templates_c directory created for you now, you just need to change the permissions

Also, I’m going to be writing up a README, because it looks like the installation and the handling of templates_c has really confused people.

I’ve seen suggestions of symlinking templates to templates_c, which is not right at all, they are not the same thing.  (I saw this posted on a Chinese website, and I don’t know Chinese, so I can’t tell the person the right way)

Your templates directory holds the templates that I’ve written – essentially the layout of the page, without any of the data in it.  Your templates_c directory contains compiled templates – that is, smarty has taken the templates (*.tpl) from the templates directory, inserted all the php code it takes to make them work, and stored the php file that resulted from that template in templates_c, for use when serving up pages.  Compiled templates are temporary.  Actual templates, tpl files, are not temporary, they were written by me and come with the distribution.  If you symlink the two directories together, you have one directory with a mess of compiled and uncompiled templates.

I admit that a readme would have explained this a little better, which is why I’m doing it for the next version.  Here is how your directory structure is supposed to look:

gitphp/index.php

gitphp/config/gitphp.conf.php

gitphp/include/*.php

gitphp/templates/*.tpl <- These are the templates written by me that come with gitphp

gitphp/templates_c/*.tpl.php <- These are the compiled templates that get written, so this directory must be writable by the web server

If you don’t have a global copy of smarty installed, you can install it locally:

gitphp/smarty/Smarty.class.php

gitphp/smarty/internals/*

gitphp/smarty/plugins/*

If you want to use geshi:

gitphp/geshi/geshi.php

gitphp/geshi/geshi/*.php

I’m planning on releasing the new version maybe this weekend or next.  Whatever testing you can do with the snapshot before then will help everyone, because that means less bugs in the actual release.  You can report them using Mantis.