This release has a couple new features and bugfixes, and starts a bit of a change in direction with the development of the project.

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.