Add support for tags pointing to other tag objects
Tags now store the object they point to and the commit separately. (For
tags pointing right to commits, the object and the commit are the same)
This keeps the object link working correctly by pointing to the direct
object (as opposed to dereferencing all the way down to the commit), so
you can use the object link to trace tagged tags all the way down to the
Also, the project and the tag list page now use the same tag listing
template fragment to make things easier.
The tree link by heads was passing the old style h=refs/heads/[head]
piece of the url, from the old version. It actually wasn't worth it to
implement the translation of the ref path to the tree object in the tree
controller, because we were already passing the hash of the head's HEAD
commit as the hashbase parameter (hb=) - in that case the tree
controller is already automatically looking up the tree for that
This addresses three issues:
1. Git stores trees as a hash of their content, which has nothing to do
with their name. Therefore, two different directories with the exact
same content but different names could end up pointing to the exact same
tree hash. This caused problems on the tree view, when it attempted to
look up the tree name by its hash - this is actually something you just
can't do reliably in git because of this system.
2. Previously, the tree view used the object cache when enumerating
items in the tree. However, because of the problem above, you could
have two copies of the same tree under two different names. Because the
object cache stores by reference, fetching and populating the tree with
data during its second appearance in the tree actually affected and
overwrote what was populated during its first appearance in the tree.
This happened during the model load, before the template was rendered,
so instead of showing the first instance and then the second instance,
it looked like the second instance appeared twice.
3. Previously the FilesystemObject class used a system where you would
assign the name to an object. This was a leftover from before it was
split out of the Tree object. Doing it this way meant there were
inconsistencies all over the place as far as what was being set for the
name - sometimes it was just the base file name, sometimes it was the
full file path, and every now and then it would have to be converted
back and forth.
Now, these are fixed:
1. Now, the f= parameter is taken as the source of truth and used to set
up the path for the tree/blob.
2. Now, the tree enumeration doesn't use the cache in order to prevent
3. Now, for consistency, the ability to set a name for a filesystem
object is removed. You can only set the full path now using SetPath,
SetName is removed. The name can still be fetched but it is
automatically derived as the base file name of the path.
The non-geshi blob output has a row for each line, which is even harder
to inject blame data into. It just made more sense to change the
non-geshi blob output to the same table structure as geshi, so one
Plus, it had the advantage of fixing the bug that made geshi introduce
this format in the first place - if you highlight code with your mouse,
the line numbers are no longer selected along with it in non-geshi view.
This changes the way projects are specified with categories in an array.
There is a new config file in the config directory, projects.conf.php,
where the projects are listed using the git_projects array. In order to
make the transition easier for upgrading users without breaking
everything when they upgrade, this will allow a fallback to the legacy
method. If the file projects.conf.php exists, it will read that using
the new array format. If it doesn't exist, it will continue to use the
legacy array format that was specified in the main gitphp.conf.php.
This change was necessary because the previous format was limited to
only a single piece of metadata for a project - one category as a
string. Now, with this format, an arbitrary amount of metadata can be
specified for any project - so future enhancements can take advantage of
this and it will be very easy to add extra metadata.
This uses PHP's standard syntax for specifying multidimensional arrays.
It is admittedly more complicated than the old method because you have
to get all the syntax with commas and array() declarations correct,
which may be difficult for non-PHP programmers. I considered doing an
actual config file parser; however since this file is loaded every
single time you load any page, I wanted it to be as lightweight as
possible, and nothing is more lightweight than PHP's native syntax.
This uses a really nasty hack to take apart the HTML table that geshi
returns, in order to inject a table cell with the blame data.
Unfortunatly because geshi only returns a complete block of HTML,
there's no good way to do this.
Make git-daemon-export-ok exclusion a config value
Just enabling this would be an automatic change, and many people
would suddenly see all their projects disappear and not know what
happened. I like the idea of respecting git-daemon-export-ok but I
can't reasonably expect everyone to go through all their repositories
and add this when they upgrade, so the exclusion is set by a config
option that's off by default.
Also, Gitweb doesn't do this at all so the odds of people having this
magic file set are even lower.
Make tree view blob sizes fallback gracefully on older versions
The tree view used -l indiscriminately to get blob sizes, without
taking into account that the -l option only appeared in git 1.5.3,
in which case the tree would fail to display anything (because the
command returned only the help message because of the invalid -l
parameter). Now it falls back properly depending on the version,
only displaying blob sizes if running on git 1.5.3 or greater.
Now the example config file only has the bare minimum config option (projectroot). It
also has the git projects array (since that is frequently used), and the cache option
commented out (since really everyone should be using caching, but it requires setup of
the cache directory so I can't enable it by default).
All other non-essential config options have been moved to a defaults file that doesn't
actually get loaded or used at all, but is just for documentation purposes. Users can
copy any config values from the defaults file into their config file and set as necessary.
Will need to evaluate to see if any other really frequently used config options should be
copied from the defaults file to the example file so users are more likely to see them.