This remaps Command-1/2 to the History/Commit view.
The keys used to be used to switch the subview in the history view.
As these views are probably less frequently changed than the history/
commit view, we'd better use the easier shortcut for the latter.
The subviews can now be changed by using command-option-1/2/3
There have been numerous bug reports about zombie processes in GitX,
because if an NSThread dies before an NSTask is finished it won't
kill the child process properly.
We tried to fix this by adding an [NSTask waitUntilExit] to wait for the
process to die, fixing the problem with the zombies. However, this caused
another problem: rendering glitches in the history view.
The problem is that [NSTask waitUntilExit] does NOT wait until the task has
finished (yeah, took me some time to figure that one out). Instead, it runs
the main loop and periodically queries if the task has finished yet.
What happens then is that during the drawing of one of the cells a call
is made to [repository headRef] to determine whether we should show the
cell in bold or not.
[repository headRef] then invokes an NSTask to figure out what the HEAD ref
really is. This in turn runs the [NSTask waitUntilExit].
Now, rather than really wait, the NSTask continues the main loop, and Cocoa
tries to display the next cell. This cell again calls an NSTask, etc...
So, what we basically have then is that halfway through the NSCell's drawing
code, the NSCell will be asked to draw another cell. It then changes the
data members and calls the [drawInRect] stuff again. the cell finishes
drawing, and control is returned to the previous draw. This path happily
continues, but now its data members are changed because of the second
draw, so it continues drawing something different than what it started
with.
As you might imagine, it took me some time to figure that one out :) The
next part is to fix it, of course, which might be somewhat tougher.
There's the easy fix to only [waitUntilExit] if the current thread is
not the main thread. This fixes our problem because nothing is drawn
in other threads, and nothing is zombie'd if it's called from the
main thread.
Another way is to fix the drawing code not to use data members. That
way the drawing can continue happily as if nothing ever happend
A third way is to fix the drawing part to never execute a git call.
I think the first and third way are OK to do. The second option doesn't
look very entertaining or practical.
Of course, the first option is only working around the problem, and
only solves this particular case. I guess this is one of those cases
of "I'll work around it this time.. if it bugs me later, I'll fix
it properly".
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 :)
We used to unconditionally set the title of the branch
to the current branch. This worked fine in most cases
where the current branch was already known, but failed
when you use 'gitx -c' and then switch to the HistoryView,
because then the currentBranch isn't known yet.
The simple fix is to check if we know it. If we don't,
it'll be set later on.
This adds a slider in the commit view with
which the user can change the context size.
This is useful for example if the hunks are too
big; by changing the context size, a hunk can be
split and then the changes can be committed.
The message that the commit was succesful used to disappear
because after the commit, the index would refresh and another
file would be shown. We fix this by never requiring a file to be
selected.
We used to fall back on the ASCII encoding if UTF-8 did not work out. However,
this causes its own problems; ASCII is only valid for the lower 7 bytes. We
solve this by using Latin-1, which should have a valid character for every
byte sequence
This restores the "Revert Changes.." functionality
that was removed when changing the file list stuff.
It's now possible to revert multiple files. Also, it
now uses 'git checkout-index', which should be a bit
more robust.
We used to read in a completely new array when refreshing
the index. The problem with this is that the selection
changes when reading in the new array. We avoid this
by changing the current array, rather than loading in
a completely new one.
We used to output a line for every lane after the
lane in which the current commit is in, and also
make it have the wrong color. This fixes the buglet
and also makes sure not to draw a line when
the commit has no parents.
This was somewhat unfortunate, as we don't check
on if we have at least a single parent when adding
new parents. That would cause a wild pointer, or null
dereference when creating a new lane.
We previously used some cool git syntax to display changes in the index.
The unfortunate side-effect of this was that the diff headers weren't correct,
so the unstage button didn't work anymore.
Seems like File.copy doesn't do directories (as source, that is),
only files (as far as I can tell from reading the docs and trying
it in irb, punch me if I'm wrong). It only creates a zero byte file
in the target directory on my system.
Replaced File.copy with a system call to 'cp -R ...' to do the job.
Seems like FileUtils could have done it just as well (with cp_r),
but I figured making a system call was better than introducing a
new dependency.
Pieter de Bie