diffHighligher.js: Recognize file-mode changes and mark them
history.js: Extend newfile callback by parameters for mode
history.css: Adjust changed-span to accomodate "mode changed"
The WebKit delegate method didStartProvisionalLoadForFrame:
is not called when reloading the frame. This caused the
webviews to appear empty.
We fix it by using a delegate method which is called each
reload, as suggested by weinig in #webkit.
This fixes Lighthouse bug #81.
The %x00 pretty specifier was only added in git v1.5.6.
This is quite new, so we try to support older git clients in
GitX (v1.5.4 and up). In order to do this, we need to use another
specifier.
Unfortunately, we can't use a real \0 in our argument, as that just
cuts off our argument string. So we get the next best thing -- we use
\01 :).
Some while ago, gitx changed its homepage from
frim.nl/gitx to gitx.frim.nl, and in the process the user
manual was moved. Though there is still a redirect in place,
it's nicer for the user if we go to the correct page at once.
Just before releasing 0.6, I cleaned up some old code.
In c6895105e2 (Remove old code in Commit/Diff views),
I removed some pre and code tags, causing new files
in the commit view to be displayed without line breaks
* 'pu/jg/rename_detection' (early part):
Diff: also show a binary when it's deleted
DiffHighlighter: Properly show binary changes
HistoryView: Prettify the file list
Show renames changes by default
history.css, history.js: Color changed/deleted/added/moved appendices
Rudimentary support for renames/deletions of files
We used to put diffs inside a <pre><code> block,
but no longer need to do that as we now use tables anyway.
We changed the code for the History view, but not for the
other two views.
Binary changes don't have a +++ / --- line, just like
a 100% rename doesn't show any changes. We work around
this in much the same way -- by reading the filenames
for that specific case.
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
Johannes Gilger