This makes the PBGitRevisionCell a bit nicer by retrieving all values
from the PBGitCommit object itself, and using another NSTextFieldCell to
draw the text.
This mean that PBGitGrapher now stores its information in the PBGitCommit's,
rather than in a custom grapher array. Also, because we don't need the
grapher to display refs anymore, the ref labels are also displayed when
using path limiting (for example, 'gitx -- Makefile').
This adds the "hasRef" boolean member in PBGitCellInfo which is set to true
if the specific commit has symbolic refs.
This is the first part in supporting labels just like gitk has. For now,
commits with refs are just displayed with a red circle.
Things that need to be done to support all refs:
* Make the NSDictionary in PBGitRepository contain arrays of refs,
not a single string
* Make PBGitGrapher store all refs of a commit in the PBGitCellInfo
* Figure out a nice way to display the labels in PBGitRevisionCell
This introduces a new object, PBGitLane that keeps track of the current lane.
We used to only need a sha for a lane, but now that more information is
needed, an extra object is in order. PBGitLane keeps a lane index number. This
number is later used to pick a color.
This uses more Cocoa classes to draw the lines, making it easier to
understand and hopefully maintain.
Furthermore, we use less memory now, which is nice, but all the
dynamic arrays probably mean more CPU usage.
This takes care of most situations. However, we don't have enough space
in the upperMapping to display multiple lines. Therefore we need to
improve it later on.
This is not complete and perhaps should not have been committed. However,
.xib files being what they are, rewriting history or merging is getting
very difficult so I'll just disable it for now.
If anyone wants to take a look at this: we should probably do some rev-parsing
to create a graph representation in ApplicationController. That class already
is a delegate for our table and can tell individual cells what to display.
There we should tell how many lines to draw, what color, if there are merges
or splitoffs etc.
Pieter de Bie