This will simplify methods that execute git commands that can take a ref or an SHA.
Add some string constants so there is only one place for the type strings.
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 already keep this dictionary in our repository. Rather than adding a
pointer to it on every commit in our rev walk, just look it up lazily in the
dictionary when we need to. That cuts down some time in the initial revwalk
and also removes some stupid code :)
This uses a normal c array to store parent sha's. That means that we
save a lot of room, as they are only 20 bytes rather than 40 + the cost of
an NSArray and the NSStrings.
The ref functionality is somewhat weird right now, in that
some parts of the code require a nil array when there are no
refs. So, we add a good removeRef accessor to keep track of this
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 uses the C fgets() over the weird readLine implementation I found.
It speeds up the rev-parsing significantly: we went from ~4.5 seconds
on the git.git repo to ~0.95 seconds. And that's with the secret new date
parsing!
Nathan Kinsinger