If there is no commit made yet, gitk just dumps a Tcl error on stderr,
which sometimes is hard to see. Noticed when gitk was run from Xfce
file manager (thunar's custom action).
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Windows, unlike X-Windows, sends mousewheel events by default to the
window that has keyboard focus and uses the MouseWheel event to do so.
The window to be scrolled must be able to take focus, but gitk's panels
are disabled so cannot take focus. For all these reasons, a different
design is needed to use the mousewheel on Windows. The approach here is
to bind the mousewheel events to the top level window and redirect them
based upon the current mouse position.
Signed-off-by: Mark Levedahl <mdl123@verizon.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>
On windows, mouse input follows the keyboard focus, so to allow selecting
text from the patch canvas we must not shift focus back to the top level.
This change has no negative impact on X, so we don't explicitly test
for Win32 on this change. This provides similar selection capability
as already available using X-Windows.
Signed-off-by: Mark Levedahl <mdl123@verizon.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Under some circumstances, having duplicate parents in a commit could
trigger a "can't unset idinlist" Tcl error. This fixes the cause
(the logic in layoutrows could end up putting the same commit into
rowidlist twice) and also puts a catch around the unset to ignore
the error.
Thanks to Jeff King for coming up with a test script to generate a
repo that shows the problem.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This changes the optimizer to insert pads to straighten downward
pointing arrows so they point straight down. When drawing the parent
link to the first child in drawlineseg, this draws it with 3 segments
like other parent links if it is only one row high with an arrow.
These two things mean we can dispense with the workarounds for arrows
on diagonal segments. This also fixes a couple of other minor bugs.
Signed-off-by: Paul Mackerras <paulus@samba.org>
The way gitk used to draw the lines joining a commit to the lines
representing its parents was sometimes visually ambiguous, especially
when the line to the parent had a corner that coincided with a corner
on another line.
This improves things by using a smaller slanting section on the line
joining a commit to a parent line if the parent line is vertical where
it joins on. It also optimizes the drawing a little in the case where
the parent line slants towards this commit already.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This creates an "ordering token" for each commit which establishes
a total ordering for commits and is used to order the commits from
left to right on a row. The ordering token is assigned when a commit
is first encountered or when it is first listed as a parent of some
other commit, whichever comes first. The ordering token is a string
of variable length. Parents that don't already have an ordering
token are assigned one by appending to the child's token; the first
parent gets a "0" on the end, the second "1" and so on. As an
optimization, the "0" isn't appended if the child only has one parent.
When inserting a new commit into an element of rowidlist, it is
inserted in the position which makes the ordering tokens increase
from left to right.
This also simplifies the layout code by getting rid of the rowoffsets
variable, and terminates lines with an arrow after 5 rows if the line
would be longer than about 110 rows (rather than letting them go on
and terminating them later with an arrow if the graph gets too wide).
The effect of having the total ordering, and terminating the lines
early, is that it will be possible to lay out only a part of the graph
rather than having to do the whole thing top to bottom.
Signed-off-by: Paul Mackerras <paulus@samba.org>
At the moment this just has two entries, which allow you to add the file
that you clicked on to the list of filenames to highlight, or replace
the list with the file.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This fixes the problem reported by Brian Downing where searching for
a string that doesn't exist would give a Tcl error. The basic problem
was that we weren't reading the data for the last commit since it
wasn't terminated with a null. This effectively adds a null on the end
(if there isn't one already) to make sure we process the last commit.
This also makes the yellow background behind instances of the search
string appear more consistently, and fixes a bug where the "/" key
would just find the same commit again and again instead of advancing.
Signed-off-by: Paul Mackerras <paulus@samba.org>
When the git log process returned an error immediately, we were
sometimes getting no main window and no error window displayed,
with the gitk process just hanging waiting for something. It appears
that the tkwait in show_error, which waits for the error window to
be destroyed, wasn't sufficient to allow the main window or the error
window to be mapped.
This adds a wait in the main startup code after the main window
has been created to wait until it is visible. This seems to fix the
problem.
Signed-off-by: Paul Mackerras <paulus@samba.org>
git-gui already uses the command key for accelerators, but gitk has
never done so. I'm actually finding it very hard to move back and
forth between the two applications as git-gui is following the Mac
OS X conventions and gitk is not.
This trick is the same one that git-gui uses to determine which
key to bind actions to.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Cygwin's Tcl is configured to honor any occurence of ctrl-z as an
end-of-file marker, while some commits in the git repository and possibly
elsewhere include that character in the commit comment. This causes gitk
ignore commit history following such a comment and incorrect graphs. This
change affects only Windows as Tcl on other platforms already has
eofchar == {}. This fixes problems noted by me and by Ray Lehtiniemi, and
the fix was suggested by Shawn Pierce.
Signed-off-by: Mark Levedahl <mdl123@verizon.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>
The magenta was a bit close in color to the normal blue commits. This
makes them green instead as suggested by Linus.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This makes gitk show up to two fake commits when there are local changes
in the repository; one to represent the state of the index and one to
represent the state of the working directory. The commit representing
the working directory is colored red as before; the commit representing
the index state is colored magenta (as being between red and blue in
some sense).
Signed-off-by: Paul Mackerras <paulus@samba.org>
When I added the "--" case to the code scanning the arguments, I missed
the fact that since the switch statement uses -regexp, the "--" case
will match any argument containing "--", e.g. "--all". This fixes it
by taking out the -regexp (since we don't actually need regular
expression matching) and adjusting the match strings.
A side effect of this is that previously any argument starting with
"-d" would be taken to indicate date mode; now the argument has to be
exactly "-d" if you want date mode.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This makes gitk more consistent with git rev-list and git log in its
handling of arguments that could be either a revision or a filename;
now gitk displays an error message and quits, rather than treating it
as a revision and getting an error in the underlying git log. Now
gitk always passes "--" to git log even if no filenames are being
specified.
It also makes gitk display errors in invoking git log in a window
rather than on stderr, and makes gitk stop looking for a -d flag
when it sees a "--" argument.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This is based on patches from Linus Torvalds and Junio Hamano, so the
ideas here are theirs.
This makes gitk use "git log -z --pretty=raw" instead of "git rev-list"
to generate the list of commits, and also makes it grok the "<" and ">"
markers that git log (and git rev-list) output with the --left-right
flag to indicate which side of a symmetric diff a commit is reachable
from. Left-side commits are drawn with a triangle pointing leftwards
instead of a circle, and right-side commits are drawn with a triangle
pointing rightwards. The commitlisted list is used to store the
left/right information as well as the information about whether each
commit is on the boundary.
Signed-off-by: Paul Mackerras <paulus@samba.org>
In commit 66e46f37de I changed gitk to
store ids in rowrangelist and idrowranges rather than row numbers,
but I missed two places in the layouttail procedure. This resulted
in occasional errors such as the "can't read "commitrow(0,8572)":
no such element in array" error reported by Mark Levedahl. This fixes
it by using the id rather than the row number.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Unroll the prefix stack when assigning treeheights when leaving
proc treeview. Previously, when the ls-tree output ended in
multiple nested directories (for instance in a repository with a
single file "foo/bar/baz"), $treeheight("foo/bar/") was assigned
twice, and $treeheight("foo/") was never assigned. This led to
an error when expanding the "foo" directory in the gitk treeview.
Signed-off-by: Brian Downing <bdowning@lavos.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>
This was a hangover from before the "Files" and "Pickaxe" parts of
the Find function were moved to the highlight facility in commit
60f7a7dc49. It serves no useful
purpose any more, so this removes it.
Signed-off-by: Paul Mackerras <paulus@samba.org>
I missed the case where both nodes have no children and therefore
have no incoming arcs. This fixes it.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This reworks the way that the "Find" button (and the /, ?, ^F, and ^G
keys) works. Previously, pressing the "Find" button would cause gitk
to go off and scan through every commit to see which commits matched,
and the user interface was completely unreponsive during that time.
Now the searching is done in chunks using the scheduler, so the UI
still responds, and the search stops as soon as a matching commit is
found.
The highlighting of matches using a yellow background is now done in
the commit-drawing code and the highlighting code. This ensures that
all the commits that are visible that match are highlighted without
the search code having to find them all.
This also fixes a bug where previously-drawn commits that need to be
highlighted were not being highlighted.
Signed-off-by: Paul Mackerras <paulus@samba.org>
The callback function was incorrectly set to update the background
colorbar when updated the selection background. This did not affect the
colors chosen or their use, just their presentation in the preferences
dialog box.
Signed-off-by: Mark Levedahl <mdl123@verizon.net>
The tabstop must be a smallish positive integer, and a spinbox is the
accepted UI control to accomplish this limiting rather than the text
entry box previously used.
Signed-off-by: Mark Levedahl <mdl123@verizon.net>
Since git reset now gets chatty while resetting, we were getting errors
reported when a reset was done using the "reset branch to here" menu
item. With this we now read the progress messages from git reset and
update a progress bar. Because git reset outputs the progress messages
to standard error, and Tcl treats messages to standard error as error
messages, we have to invoke git reset via a shell and redirect standard
error into standard output.
This also fixes a bug in computing descendent heads when head ids
are changed via a reset.
Signed-off-by: Paul Mackerras <paulus@samba.org>
The main thing here is better parsing of the diff --git lines in the
output of git diff-tree -p. We now cope with filenames in quotes with
special chars escaped. If the filenames contain spaces they aren't
quoted, however, which can create difficulties in parsing. We get
around the difficulties by detecting the case when the filename hasn't
changed (chop the part after "diff --git " in two and see if the halves
match apart from a/ in one and b/ in the other), and if it hasn't
changed, we just use one half. If the filename has changed we wait
for the "rename from" and "rename to" lines, which give the old and
new filenames unambiguously.
This also improves the parsing of the output of git diff-tree.
Instead of using lindex to extract the filename, we take the part from
the first tab on, and if it starts with a quote, we use [lindex $str 0]
to remove the quotes and convert the escapes.
This also gets rid of some unused tagging of the diff text, uses
[string compare] instead of [regexp] in some places, and fixes the
regexp for detecting the @@ hunk-separator lines (the regexp wasn't
accepting a single number, as in "-0,0 +1" for example).
Signed-off-by: Paul Mackerras <paulus@samba.org>
When we compute descendent heads and descendent/ancestor tags, we
cache the results. We need to be careful to invalidate the cache
when we add stuff to the graph. Also make sure that when we cache
descendent heads for a node we only cache the heads that are actually
descendents of that node.
Signed-off-by: Paul Mackerras <paulus@samba.org>
For some unknown reason, changing the scrolling region on the canvases
provokes multiple milliseconds worth of computation in the X server,
and this can end up slowing gitk down significantly. This works around
the problem by limiting the rate at which we update the scrolling region
after the first 100 rows to at most 2 per second.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This adds an entry to the menu that comes up when the user does a
right-click on a row. The new entry allows the user to reset the
currently checked-out head to the commit for the row that they did
the right-click on. The user has to select what type of reset to
do, and confirm the reset, via a dialog box that pops up.
Signed-off-by: Paul Mackerras <paulus@samba.org>
The information in childlist is a duplicate of what's in the children
array, and it wasn't being accessed often enough to be really worth
keeping the list around as well.
Signed-off-by: Paul Mackerras <paulus@samba.org>
We were doing two execs for each tag - one to map the tag ID to a
commit ID and one to read the contents of the tag for later display.
This speeds up the process by not reading the contents of the tag
(instead it is read later if needed), and by using the -d flag to
git show-ref, which gives us refs/tags/foo^{} lines which give us
the commit ID. Also this uses string operations instead of regexps.
Signed-off-by: Paul Mackerras <paulus@samba.org>
If there are local changes in the repository, i.e., git-diff-index HEAD
produces some output, then this optionally displays an extra row in
the graph as a child of the HEAD commit (but with a red circle to
indicate that it's not a real commit). There is a checkbox in the
preferences window to control whether gitk does this or not.
Clicking on the extra row shows the diffs between the working directory
and the HEAD (using git diff-index -p). The right-click menu on the
extra row allows the user to generate a patch containing the local diffs,
or to display the diffs between the working directory and any commit.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This only draws as much of the graph lines as is visible. This can
happen by adding coordinates on to an existing graph line or by
creating a new line. This means that we only need to have laid out
and optimized as much of the graph as is actually visible in order to
draw it, including the lines (previously we didn't draw a graph
line until we had laid out and optimized to the end of a segment of
the line, i.e. down to a down-arrow or to the row where the line's
commit is displayed). This also lets us get rid of the linesegends
list, and gives us an easy workaround for the X server bug that
causes long lines to be misdrawn. This also gets rid of the use
of rowoffsets in drawlineseg et al.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This removes the need for insertrow to go through rowrangelist and
idrowranges and adjust a lot of entries. The first entry for a given
id is now the row number of the first child, not that row number + 1,
and rowranges compensates for that so its callers didn't have to
change. This adds a ranges argument to drawlineseg so that we can
avoid calling rowranges a second time inside drawlineseg (all its
callers already called rowranges).
Signed-off-by: Paul Mackerras <paulus@samba.org>
Neither the "check out this branch" nor the "remove this branch"
menu item can be used on the currently-checked out branch, so disable
them.
Signed-off-by: Paul Mackerras <paulus@samba.org>
In some repositories imported from other systems we can get carriage
return characters in the commit message, which leads to a multi-line
headline being displayed in the summary window, which looks bad.
Also some commit messages start with one or more blank lines, which
leads to an empty headline. This fixes these problems.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This allows us to do compute-intensive processing, such as laying out
the graph, relatively efficiently while also having the GUI be
reasonably responsive. The problem previously was that file events
were serviced before X events, so reading from another process which
supplies data quickly (hi git rev-list :) could mean that X events
didn't get processed for a long time.
With this, gitk finishes laying out the graph slightly sooner and
still responds to the GUI while doing so.
Signed-off-by: Paul Mackerras <paulus@samba.org>
It used to be that if you clicked on a line while gitk was still drawing
stuff, it would immediately re-select the first line of the display.
This fixes that.
Signed-off-by: Paul Mackerras <paulus@samba.org>
With some large repositories, a commit can end up on thousands of
branches, which results in an extremely long "Branches:" line in the
details window, and that results in the window being extremely slow
to scroll.
This fixes it by just showing "many (N)" after "Branches:", "Follows:"
or "Precedes:", where N is the number of heads or tags. The limit
is currently set at 20 but could be made configurable (and the "many"
could be a link to pop up a window listing them all in case anyone
really wants to know).
Signed-off-by: Paul Mackerras <paulus@samba.org>
Instead of working out descendent heads and descendent & ancestor
branches in a two-pass algorithm, this reads and stores a simplified
version of the graph topology, and works out descendent/ancestor
tags and descendent heads on demand (with a bit of caching).
The advantages of this are, first, that we now don't have to use
--topo-order on the git rev-list process. Secondly, we don't have
to re-read the whole graph when tags or heads change or even when
the graph changes. Since we can cope with parents coming before
children, we can update the graph by running a git rev-list with
arguments that just give us the new commits, and merge the new
commits into the simplified graph.
The graph is simplified in the sense that commits with exactly one
parent and one child (which is >90% of them in most cases) are grouped
together into arcs joining nodes or 'branch/merge points', which are
the commits that don't have exactly 1 parent and 1 child. This reduces
the size of the graph substantially and decreases the time to traverse
it correspondingly.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Not all projects use the convention that one tabstop = 8 characters, and
a common convention is to use one tabstop = one level of indent. For such
projects, using 8 characters per tabstop often shows too much whitespace
per indent. This allows the user to configure the number of characters
to use per tabstop.
Signed-off-by: Mark Levedahl <mdl123@verizon.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>
When adjusting fontsize (using ctrl+/-), all panes except the lower right
were updated. This fixes that.
Signed-off-by: Mark Levedahl <mdl123@verizon.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Cygwin's tk by default uses a very dark selection background color that
makes the currently selected text almost unreadable. On linux, the default
selection background is a light gray which is very usable. This makes the
default a light gray everywhere but allows the user to configure the
color as well.
Signed-off-by: Mark Levedahl <mdl123@verizon.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>
This adds a set of radiobuttons that select between displaying the full
diff (both - and + lines), the old file (suppressing the + lines) and the
new file (suppressing the - lines) in the diff display window.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Made the default buttons on the dialog active and focused upon the
dialog appearence.
Bound 'Escape' and 'Return' keys to the dialog dismissal where it
was appropriate: mainly for dialogs with only one button and no
editable fields.
Unified the look of the "About gitk" and "Key bindings" dialogs.
Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Some parts of gitk were not respecting the default GUI font. Most
of them were catched and fixed.
Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Preferring git _space_ COMMAND over git _dash_ COMMAND allows the
user to have only git and gitk in their path. e.g. when git and gitk
are symbolic links in a personal bin directory to the real git and gitk.
Signed-off-by: Paul Mackerras <paulus@samba.org>
I chose <F5> because it's also the key to reload the current
page in web browsers such as Konqueror and Firefox, so users
are more likely to be familiar with it.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>
