GitPHP

I’ve released GitPHP 0.2.5. I’ve had a little more free time recently than I’ve had for the past couple versions, so this version has some more changes than the previous couple releases.

• Move a lot of the data loading to using raw php file parsing instead of relying on the git executable. This causes an enormous performance boost, especially on webservers that have very expensive process forking (I’m looking at you Apache)
• Add a 'compat’ config option that can be specified globally or per-project, to fall back on the old method of loading data if you run into issues with the previous enhancement. (PHP will not process repository packfiles larger than 2GB)
• Add a 'largeskip’ config option. Using raw PHP data loading, we have to walk commits down the log as you page down earlier and earlier in the history, which has decreasing performance as you go back. This determines at what threshold gitphp will instead just use the git executable.
• Display merge commits in the shortlog with grayed-out titles, thanks to Tanguy Pruvot
• Subdirectory snapshots now include the subdirectory as part of the archive name
• Support for the xdiff php extension . If you have the xdiff php extension installed, that will be used for diffing, which is faster and completely eliminates the need to have a separate diff executable or temp dir configured.
• Support for loading the project list from an SCM-Manager config. Only projects marked public are loaded. Based on work done by Craig Sparks
• Add debug info when searching directory for projects. If you aren’t seeing certain or any projects appear when letting GitPHP find all projects in the project root, turn on the 'debug’ config option to see more about what it’s doing.
• Benchmarking info is now turned on separately from debug info, with a new config option 'benchmark’
• Cache list of projects if the object cache is turned on, instead of searching the project root every time. Based on work done by Tanguy Pruvot
• Archives are now delivered incrementally to the user’s browser, instead of being loaded entirely into memory first. This avoids PHP out-of-memory errors when trying to snapshot a very large project. Note: as a result of this change, snapshot tarballs are no longer cached to Memcache, even if Memcache support is turned on. They will always be cached to the cache directory on disk.
• Minify CSS for performance
• Support tags pointing directly to blobs. This isn’t commonly done but can be used to embed something like a GPG key in a repository
• Allow displaying a website URL for a project. Because this can’t really be automatically calculated the way clone/push urls can, this is a per-project setting only.

• Fixed how the default diff executable is determined if not specified in the config
• Fixed issues diffing when the temp dir had spaces in the name (common on Windows)
• Fixed issues diffing on windows when the temp dir didn’t have a trailing backslash
• Avoid floods of warning messages when the fileinfo magic database is incorrectly compiled
• Avoid warning messages when the project doesn’t have a description file. (sometimes happens with repositories created by third party software other than the standard git program)
• Fixed some display issues on the project list with owner/age/links columns wrapping too much when the project has an extremely long description
• Avoid warning messages when listing all projects in the projectroot and the webserver user doesn’t have read access to one of the directories. Based on a fix by Justyn Shull
• Fixed issue where using the diff link by a single file on the commit page showed the wrong commit at the top of the diff

Q: You’ve had a smarty 3 branch in progress for a while now. Why haven’t you merged it yet? Smarty 3 is perfect and amazing!!!1!eleven1one
A: Not quite. Smarty 3 is a complete rewrite and, just like the complete GitPHP rewrite a year ago, has some bugs and some differences in behavior. These changes in smarty 3 actually broke some of the functionality in GitPHP. I’ve been making changes to accomodate new behavior, and doing hacks to work around smarty 3 bugs, and I’m still not convinced I’ve found all of them yet. Additionally, Smarty 3’s cache infrastructure is completely different from Smarty 2, which renders all custom cache code useless. In particular, this means that GitPHP Memcache support does not work at all with Smarty 3. The upgrade to smarty 3 is something that makes development easier but has no real discernible effect for end users. I refuse to do an 'upgrade’ that will negatively impact end users, especially when that negative impact is lost functionality.