This keeps the subviews in memory, which means that switching views will
be faster if a view has already been opened. This also allows you to type
a commit message, switch to the history view, and then switch back to
continue typing.
Previously, the diff hilighter was a bit odd in that it would
just search for elements with a diff and highlight those. While
useful in theory, this wasn't used at all. We change it to
receive the diff to hilight, which makes the code somewhat simpler.
A list of files included in a commit are listed below the
commit message. The list are links which will take you to
that file in the diff display below.
The title of each fileHeader is now just the path to the file
instead of the full diff command.
While the focus is in the commit ctrl-down_arrow and up_arrow
will navigate to to next and previous file in that commit.
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.
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
I'm not sure what this loop originally did, but it was buggy and doesn't
seem logical. Removing it speeds up the graphing a lot, so let's kill it.
We can always get it back later if necessary
This produces cleaner code and is also significantly faster
than the old obj-c code: linux-2.6 goes from ~8 seconds
to ~6 seconds.
Using the c++ code allows us to do easy optimizations
This adds a new target 'SpeedTest', which just loads in a repository
and displays how long it takes to load the revision. This is handy for
testing the speed of the revwalking mechanism
This limits the maximum number of lanes to 32, making the
graphing a lot faster. For example, linux-2.6.git takes only
30 seconds now, rather than >400
This wasn't used anyway. A good idea would be to create a new
branchcontroller that takes care of all these revs, rather than
letting PBGitRepository take care of that
* 'master' of git://github.com/bkerley/gitx:
Use a task (that is properly disposed of) for reading the rev list
make taskForCommand public so other classes can use it
Wait for a child to clear it out.
use outputForCommand instead of handleForCommand to save code, remove zombie-leaking bug
This merges functionality that was previously stored in the
combination of PBGitCommitController / PBChangedFile to a
dedicated controller, PBGitIndexController.
Pieter de Bie