The current nextfile() jumps to last hunk, but I think this is not
intention, probably, it's forgetting to add "break;". And this
patch also adds prevfile(), it jumps to previous hunk.
Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Signed-off-by: Paul Mackerras <paulus@samba.org>
When inserting the new commit row for the cherry-picked commit, we weren't
advancing the selected line (if there is one), and we weren't updating
commitlisted properly.
This restructures layoutmore so that it can take a time limit and do
limited amounts of graph layout and graph optimization, and return 1
if it exceeded the time limit before finishing everything it could do.
Also getcommitlines reads at most half a megabyte each time, to limit
the time it spends parsing the commits to about a tenth of a second.
Also got rid of the unused ncmupdate variable while I was at it.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This does a git-cherry-pick -r to cherry-pick the commit that was
right-clicked on to the head of the current branch. This would work
better with some minor changes to the git-cherry-pick script.
Along the way, this changes desc_heads to record the names of the
descendent heads rather than their IDs.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This fixes a silly typo (an extra a) and fixes the condition for
asking for confirmation of removing a branch.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This menu allows you to check out a branch and to delete a branch.
If you ask to delete a branch that has commits that aren't on any
other branch, gitk will prompt for confirmation before doing the
deletion.
Signed-off-by: Paul Mackerras <paulus@samba.org>
We weren't updating the desc_heads, desc_tags and anc_tags arrays when
rereading the set of heads/tags/etc. The tricky thing to get right
here is restarting the computation correctly when we are only half-way
through it.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This makes the colors for the diff old/new lines and hunk headers
configurable, as well as the background and foreground (text color)
of the various panes. There is now a GUI in the edit->preferences
window to set them.
Signed-off-by: Paul Mackerras <paulus@samba.org>
The listrefs procedure was inadvertently removed during the course of
development, but there is still a user of it, so resurrect it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>
This is a small extension to the code that reads the complete commit
graph, to make it compute descendent heads as well as descendent tags.
We don't exclude descendent heads that are descendents of other
descendent heads as we do for tags, since it is useful to know all the
branches that a commit is on.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This adds a feature to the diff display window where it will show
the tags that this commit follows (is a descendent of) and precedes
(is an ancestor of). Specifically, it will show the tags for all
tagged descendents that are not a descendent of another tagged
descendent of this commit, and the tags for all tagged ancestors
that are not ancestors of another tagged ancestor of this commit.
To do this, gitk reads the complete commit graph using git rev-list
and performs a couple of traversals of the tree. This is done in
the background, but since it can be time-consuming, there is an option
to turn it off in the `edit preferences' window.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This is invoked by shift-down/shift-up. It relies on a patch to
git-diff-tree that has recently gone into the git repository, commit
ID e0c97ca6 (without this it may just sit there doing waiting for
git-diff-tree when looking for the next/previous highlight).
Signed-off-by: Paul Mackerras <paulus@samba.org>
This provides a way to highlight commits that are, or are not,
descendents or ancestors of the currently selected commit. It's
still rough around the edges but seems to be useful even so.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Bug noted by Junio C Hamano: show_error can be passed "." (root
window) as its $w argument, but appending ".m" and ".ok" results in
creating "..m" and "..ok" as window paths, which were invalid.
This fixes it in a slightly different way from Junio's patch, though.
Signed-off-by: Paul Mackerras <paulus@samba.org>
The code to extract a message part from the error message was
not passing the error message to [string range], and resulted
in the show_error not getting called.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>
This removes the "Files" and "Pickaxe" parts of the "Find" function,
so Find is now just about searching the commit data. We now highlight
the commits that match the Find string (without having to press Find),
and have a drop-down menu for selecting whether the git-diff-tree based
highlighting is done on paths or on adding/removing a given string.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This makes it work a bit more smoothly, and adds a reverse-search
function, for which I stole the ^R binding from the find function.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This does incremental highlighting of matches to the search string
but doesn't do true incremental search a la emacs.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This applies a bold highlight to entries in the file list pane in the
bottom right corner when it is displaying the list of changed files.
This doesn't yet highlight file list entries when it is in tree view
mode.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Some people put very long strings into commit messages, which then
become invisible in gitk (word wrapping in the commit details window is
turned off, and there is no horizontal scroll bar). Enabling word wrap
for just the commit message looks much better.
Wrapping is controlled by the "wrapcomment" option in ~/.gitk. By
default this option is set to "none", which disables wrapping; setting
it to "word" enables word wrap for commit messages.
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
Signed-off-by: Paul Mackerras <paulus@samba.org>
If the user pressed page up or page down and the new page wasn't
already drawn, we failed to select the line we wanted in the new
page. This fixes it.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Now there is a bar across the middle (just below the bar containing
the sha1 ID, find string etc.) which controls highlighting. There are
three ways to highlight: the user can highlight commits affecting
a list of paths, commits in a view, or commits where the author or
committer matches any of a list of strings (case-insensitive). The
elements of the list of paths and list of names are delimited by
whitespace with shell quoting rules.
Signed-off-by: Paul Mackerras <paulus@samba.org>
In the commit details window, we were displaying "(...)" for the
headlines of parents and children that haven't been drawn, without
making any attempt to get those headlines. This adds a call to
getcommit to commit_descriptor so we get those headlines.
Signed-off-by: Paul Mackerras <paulus@samba.org>
The list of arguments to git-rev-list, including arguments that
select the range of commits, is now a part of the view specification.
If any arguments are given to gitk, they become part of the
"Command line" view, and the non-file arguments become the default
for any new views created.
Getting an error from git-rev-list is no longer fatal; instead the
error window pops up, and when you press OK, the main window just
shows "No commits selected".
The git-rev-list arguments are entered in an entry widget in the
view editor window using shell quoting conventions, not Tcl quoting
conventions.
Signed-off-by: Paul Mackerras <paulus@samba.org>
The conversion of the file list to use a text widget assumed incorrectly
that the list of files from git-diff-tree -r would correspond 1-1 with
the diff sections in the output of git-diff-tree -r -p -C, which is
not true when renames are detected. This fixes it by keeping the
elements in the difffilestart list in the order they appear in the
file list window.
Since this means that the elements of difffilestart are no longer
necessarily in ascending order, it's somewhat hard to do the dynamic
highlighting in the file list as the diff window is scrolled, so I
have taken that out for now.
Signed-off-by: Paul Mackerras <paulus@samba.org>
With this, one view can be used as a highlight for another, so that
the commits that are in the highlight view are displayed in bold.
This required some fairly major changes to how the list of ids,
parents, children, and id to row mapping were stored for each view.
We can now be reading in several views at once; for all except the
current view, we just update the displayorder and the lists of parents
and children for the view.
This also creates a little bit of infrastructure for handling the
watch cursor.
Signed-off-by: Paul Mackerras <paulus@samba.org>
You can now select whether you want to see the patch for a commit
or the whole tree. If you select the tree, gitk will now display
the commit message plus the contents of one file in the bottom-left
pane, when you click on the name of the file in the bottom-right pane.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This lets us do things like highlighting all the entries for which
the corresponding part of the diff is at least partly visible in the
commit/patch display window, and in future it will let us display
the file list in a hierarchical form rather than as a flat file list.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This patch partly changes the background color for remote refs.
It makes it easy to quickly distinguish remote refs from local
developer branches.
I ignore remote HEADs, as these really should be drawn as
aliases to other heads. But there is no simple way to
detect that HEADs really are aliases for other refs via
"git-ls-remote".
Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
Signed-off-by: Paul Mackerras <paulus@samba.org>
This allows the user to change the name of the view, whether it is
permanent, and the list of files/directories for the view.
Signed-off-by: Paul Mackerras <paulus@samba.org>
With this the user can now mark a view as "permanent" and it will
appear in the list every time gitk is started (until it is deleted).
Also tidied up the view definition window, and changed the view
menu to use radiobuttons for the view selections so there is some
feedback as to which is the current view.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This uses git-rev-parse --no-revs --no-flags to give us just the
file and directory names on the command line, so that we can create
the "Command line" view if any were specified. All other arguments
just get passed to git-rev-list (without a pass through git-rev-parse).
Signed-off-by: Paul Mackerras <paulus@samba.org>
This is a fix for a problem reported by Jim Radford where an argument
list somewhere overflows on repositories with lots of tags. In fact
it's now unnecessary to use git-rev-parse since git-rev-list can take
all the arguments that git-rev-parse can. This is inspired by but not
the same as the solutions suggested by Jim Radford and Linus Torvalds.
Signed-off-by: Paul Mackerras <paulus@samba.org>
When moving backwards or forwards through the history list, this
automatically switches the view so that each point that we jump to
is shown in the same view that it was originally displayed in.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This bug was reported by Yann Dirson, and results in an 'Error:
expected boolean value but got ""' dialog when scrolling to the bottom
of the graph under some circumstances. The issue is that git-rev-list
isn't outputting all the boundary commits when it is asked for commits
affecting only certain files. We already cope with that by adding the
missing boundary commits in addextraid, but there we weren't adding a
0 to the end of the commitlisted list when we added the extra id to
the end of the displayorder list.
This fixes it by appending 0 to commitlisted in addextraid, thus keeping
commitlisted and displayorder in sync.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Previously, if we switched away from a view before we had finished
reading the git-rev-list output for it and laying out the graph, we
would discard the partially-laid-out graph and reread it from
scratch if we switched back to the view. With this, we preserve the
state of the partially-laid-out graph in viewdata($view) and restore
it if we switch back. The pipe to git-rev-list remains open but we
just don't read from it any more until we switch back to that view.
This also makes linesegends a list rather than an array, which turns
out to be slightly faster, as well as being easier to save and restore.
The `update' menu item now kills the git-rev-list process if there is
one still running when we do the update.
Signed-off-by: Paul Mackerras <paulus@samba.org>
- don't re-read refs when switching views, it's too slow; just do
it if the user did File->Update
- make the view menu use the uifont
- if we have a graph line selected, unselect it before changing the view
- if a row is selected and appears in the new view, but we have to
read in the new view, select that row when we come across it
- if no row was previously selected, or if we don't find the previously
selected row in the new view, select the first row
Signed-off-by: Paul Mackerras <paulus@samba.org>
