The gitphp rewrite has been merged from its development branch into the master branch. It’s not 100% complete, but most of the work is done. There haven’t really been any UI changes yet, this is all backend stuff at the moment. I’m sure it’s still pretty buggy, so I encourage the brave to grab a snapshot and try it out – the more bugs we take care of now, the less are in the actual release. If you’re not that brave, the copy running on my site right now at http://gitphp.xiphux.com is running the rewrite snapshot code, so you can play around with that if you want. It’s still going to be some time before the next release; a complete code change like this needs a significant amount of testing time.

The rewrite uses an exception catching system to display error messages to the user. Some of these are intentional – for example, displaying that a search had no results. However, for the moment, I have disabled this exception catch in order to debug actual issues easier – errors will be a lot less friendly but will show a lot more useful debugging info. This exception catch will be re-enabled before release.

As a side effect of the rewrite, a couple small “features” did make it into the rewrite right now:

• The configuration management operates on a merge system now, in that configuration values specified in gitphp.conf.php will be merged over and replace default values. What that means is that now the config file doesn’t have to specify all the config values in order to work properly – it only has to specify the values that you want to change. In fact, you’ll notice that this is now reflected in the example config; the example now only has config values that almost everyone cares about: the projectroot config value (because it’s necessary), the git projects list (because it’s frequently used), and the caching option (because really everyone should be using caching, I just can’t turn it on by default because it requires setting up a cache directory). Every other config option has been moved to the gitphp.conf.defaults.php file, which lists all the config values and their defaults (formerly what the example used to do). The defaults file isn’t usable as a real config; the idea is that if you want to change a config value, you copy it from the defaults file into your gitphp.conf.php file and set it appropriately. This way users can keep the amount of noise in their config files to a minimum. If you have suggestions for other very frequently used config options that are good candidates to put in the example file, let me know.
• Previously, ref tags (the little yellow labels that list heads/tags for a commit) would not distinguish between tags and heads. Now, tags and heads are different colors, and clicking on the little badges will direct you to an appropriate page for that ref (the shortlog for heads, the tag page for tags).
• Turning on debugging outputs a wealth of timing and memory usage information – probably way more than you care about. This output also breaks any non-html output (snapshots, rss, opml, etc). In other words, turn debugging off if you were using it.
• Trees display file sizes by blobs. At the moment they’re not right-aligned though, I need to fix that (Update 2010-03-30: also it requires git 1.5.3 or greater, as I found out the hard way just now when my copy hosted on this website has been crashing on the tree view because dreamhost only runs git 1.4.4.4. A fix was added to make it fallback gracefully on older versions)
• File searching shows the line number by matching lines

I have a variety of ideas that I want to implement. I don’t know how many of these will get in before the next release, but some ideas are:

• Using javascript tooltip bubbles to show more information – for example, mousing over a commit title to get the full commit message in a more readable form than the current method of using the title attribute
• GeSHi syntax highlighting on the blame page
• Loading blame info inline into the blob page using javascript and ajax, rather than going to a separate page
• I18n
• Allowing drilling down into a tree using javascript and ajax without having to navigate to a different tree page

Other suggestions are welcome.

The rest of this post is about the architectural design and decisions of the OOP rewrite. If you don’t care, you can stop reading now.

The idea of the rewrite was to separate the business logic from the UI using a model-view-controller system. I followed this basic methodology:

• Model: a library of objects representing the various pieces of a git repository – project, commit, tree, blob, etc. In directory include/git
• View: the smarty template
• Controller: connector class that reads the parameters for an action, instantiates the proper model objects, and passes them to the template system (smarty). In include/controller

The git data model is pretty self-explanatory. Most objects represent pieces of a git repo you’re familiar with. Any objects representing a hash in the repository inherit from the GitObject class, which is an abstract class representing a hash. The ProjectList* classes represent a list of projects, with ProjectList being the factory and ProjectListBase being the abstract base class that the various projectlist implementations (directory list, gitosis file, categorized array) extend.

Controllers are also pretty straightforward. All controllers inherit from ControllerBase, the base class which does a lot of the generic implementation, such as setup of template variables used in all templates, handling displaying a cached template vs loading the data for rendering, etc. The Controller class itself is the “supercontroller” that maps the action to a given controller class. Controllers can also be flexible and change things based on parameters – for example, shortlog and log now both use the same data objects and therefore use the same controller – just that the controller decides whether to use the shortlog or the log template depending on a parameter.

This is not a 100% pure MVC system – to minimize the amount of processing the controller does, the template has to know some things about how the data objects work. For example, if the template knows how to get the commit message out of a commit object, or get the root tree from a commit object, it doesn’t really make sense to make the controller do the extra work of pulling that out beforehand. Really, this is because for this project I am both the programmer and the template author, so I don’t have to pretend that the template author doesn’t know anything about the data model.

Apoplectic MVC purists can leave now.

That said, if you can get over that, any constructive criticism on any part of the design is welcome. I did take shortcuts in the data model in a couple places, after all.

Performance testing is showing certain actions to be slower and others to be faster. In particular, pages that can make repeated use of a single object (project summary, commit, etc) are showing speedups because of the way objects only load data from the repository on demand and cache it. At the same time, code that makes use of many different objects (for example, all the commit objects used to display all the entries on a log page) are showing slowdowns because it takes php time to create those objects. In the end, it balances out. Of course, caching still makes much of this pretty much moot.

Give the new code a test – play around with using the rewritten code, have a look at the code if you’re programming inclined and offer suggestions. Heck, if you use http://gitphp.xiphux.com you can do both at the same time. Let me know what you think.