…ymore I've seen this hang or crash a few times, so I hope this works better. Instead of running a task in a separate thread, we just let it go through the run loop and catch it when the task is done. This ruins the second subview in the history view, but I don't think anybody ever used that, so I'm going to remove it.
We don't want to do this in the commit view, as that way you can't commit whitespace differences. You'll never be able to have a clean working tree, and you can't see why the files remain 'unstaged'. So, we do this only for the history view :)
This fixes ticket #132, where setting color.ui = always in the gitconfig caused GitX to received colorized output for "git show", thereby destroying the diff-output. Signed-off-by: Johannes Gilger <email@example.com>
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 reduces GitX's memory usage and makes some operations much faster, like graphing, by having a cheaper comparison
… zombie-leaking bug
This should make the GUI more responsive by allowing the diff to be read in the background. This assumes that [PBGitCommit details] is threadsafe, so we should keep it that way.
This is a nice way to track patches that appear on the internets :)
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 is necessary for cool graph displaying, to be made.