If there are a large number of refs pointing to a commit, then they may be drawn on top of or behind the other columns.
This will not show any labels that don't fit.
Switch from storing both the ref and the commit to storing just one or the other as a refish.
Change action methods that receive PBRefMenuItem to support the change in functionality. In particular the removeRefSheetDidEnd:returnCode:contextInfo: method in PBRefController now looks up the commit for the ref (this was the only place that needed both the ref and the commit).
When the Subject column is not the first column in the git history table the contextual menu for refs and dragging and dropping refs don't work.
Offset the mouse click's x value by the x origin of the Subject column.
In PBRefController look up the column index of the subject column and check that it's the clicked column (don't assume it's the first one).
It used to be displayed in bold, but this can be easily overlooked when
visualizing all branches. It's easier to see the HEAD when it has its own
colour.
This was seriously broken after we moved to a hash
to store the refs in ddc9ae7654. Apparently nobody
noticed this earlier.
We fix it by doing the right thing. Don't remove the array
if it's empty, but check in the drawing if we really have refs.
We used to use NSObjects, which was really expensive, because for each commit
as many as 100 graphlines can be created. By preallocating them and not
using NSObjects in general, we gain a massive speedup
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.
Nathan Kinsinger