To generate the diff for a commit, gitk used to do
git-diff-tree -p -C $p $id
(and same thing to generate filenames, except using just "-r" there) which
does actually generate the diff from the parent to the $id, exactly like
it meant to do.
However, that really sucks with --dense, where the "parent" information
has all been rewritten to point to the previous commit. The diff actually
works exactly right, but now it's the diff of the _whole_ sequence of
commits all the way to the previous commit that last changed the file(s)
that we are looking at.
And that's really not what we want 99.9% of the time, even if it may be
perfectly sensible. Not only will the diff not actually match the commit
message, but it will usually be _huge_, and all of it will be totally
uninteresting to us, since we were only interested in a particular set of
files.
It also doesn't match what we do when we write the patch to a file.
So this makes gitk just show the diff of _that_ commit.
We might even want to have some way to limit the diff to only the
filenames we're interested in, but it's often nice to see what else
changed at the same time, so that's secondary.
The merge diff handling is left alone, although I think that should also
be changed to only look at what that _particular_ merge did, not what it
did when compared to the faked-out parents.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
This adds several new keybindings to allow history and selectline
navigation. I basically added Opera-like history traversal, as well
as left-right-cursor history traversal and vi-like motion commands.
Signed-off-by: Robert Suetterlin <robert@mpe.mpg.de>
Signed-off-by: Paul Mackerras <paulus@samba.org>
This just displays the result of git-cat-file on the tag in the
details pane. If the tag is a "direct" tag (the tag file contains
the SHA1 ID of a commit rather than a tag), we show the tag name
and SHA1 ID.
These are features requested by Junio. Any plain file under .git/refs
whose contents start with 40 hex characters is taken as a reference
and displayed like a head but with a light blue background (unless it
is in .git/refs/tags or .git/refs/heads, in which case it is displayed
as before). There is now a "Reread references" menu item in the File
menu which re-reads all the plain files under .git/refs and redisplays
any references that have changed.
With --parents, git-rev-list gives us the list of parents on the
first line of each commit. We use that rather than looking for
the parent: lines in the commit body, since this way we get to
know about the grafts for free.
When the graph gets too wide (as defined by the maxwidth variable,
which can be set in ~/.gitk), we can now terminate graph lines with
an arrow pointing downwards, and reintroduce them later with an
arrow pointing upwards when we need them. This makes the graph much
less cluttered on large repositories such as the linux kernel.
Unfortunately this has made it slower; it takes about 10 seconds
user time on the linux-2.6 repository on my machine now, compared
to 6 seconds before. I'll have to work on optimizing that. Also
on the todo list are making the arrow heads active (so if you click
on them you jump to the other end) and improving the placement of
the null entry.
The previous commit improved performance a lot but also meant that
we waited longer to see something drawn. This refines the heuristics
for when to call update so that (1) when we have finished processing
a bufferfull of information from git-rev-list, we call update if
enough time has elapsed, regardless of how many commits we've drawn,
and (2) the number of commits drawn between updates scales with the
total number of commits drawn: 1 for 1-99 commits, 10 for 100-9999
commits, or 100 for >= 10000 commits.
On a large repository with > 60,000 commits, each call to the Tk
update primitive (which gives Tk a chance to respond to events and
redraw the screen) was taking up to 0.2 seconds. Because the logic
was to call update after drawing a commit if 0.1 seconds had passed
since the last update call, we were calling it for every commit,
which was slowing us down enormously. Now we also require that we
have drawn 100 commits since the last update (as well as it being
at least 0.1 seconds since the last update). Drawing 100 commits
takes around 0.1 - 0.2 seconds (even in this large repo) on my G5.
This adds "Child: " lines to the commit window, which tells what children
a commit has.
It also cleans things up: it marks the text widget as no-wrap, which means
that it doesn't need to truncate the commit description arbitrarily by
hand. Also, the description itself is now done by a common helper routine
that handles both the parent and the children.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Now the history remembers when we have clicked on a graph line
and when we have asked for a diff between two commits, as well
as when we have displayed a commit.
The display when you click on a graph line now uses clickable
SHA1 IDs instead of the embedded "Go" buttons. Also made the
IDs clickable in the header for a diff between two commits.
This adds a useful "Parent:" line to the git commit information window.
It looks something like this (from the infamous octopus merge):
Author: Junio C Hamano <junkio@cox.net> 2005-05-05 16:16:54
Committer: Junio C Hamano <junkio@cox.net> 2005-05-05 16:16:54
Parent: fc54a9c30c (Update git-apply-patch-script ...)
Parent: 9e30dd7c0e (Make git-prune-script executa ...)
Parent: c4b83e618f (Do not write out new index if ...)
Parent: 660265909f (diff-cache shows differences ...)
Parent: b28858bf65 (Update diff engine for symlin ...)
Octopus merge of the following five patches.
Update git-apply-patch-script for symbolic links.
Make git-prune-script executable again.
Do not write out new index if nothing has changed.
diff-cache shows differences for unmerged paths without --cache.
Update diff engine for symlinks stored in the cache.
Signed-off-by: Junio C Hamano <junkio@cox.net>
where all the parent commit ID's are clickable, because the new lines are
added as part of the "comment" string, and thus the regular clickability
thing will match them automatically.
I think this is good. And my random-tcl-monkey-skills are clearly getting
better (although it's perfectly possible that somebody who actually knows
what he is doing would have done things differently).
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
The effect of this is that it allows Tcl to do the locale-specific
conversion of the input data to its internal unicode representation.
That means that commit messages in Russian or other languages should
be displayed correctly now (according to the locale that is in effect.)
This is based on suggestions by Jeff Epler and Linus Torvalds, but
extended so that we do the switching between the watch cursor and
the normal cursor correctly as well.
Also fixed a bug pointed out by Junio Hamano - I wasn't incrementing
the link number (duh!).
When we display the commit message in the details pane, any string
of 40 [0-9a-f] characters that corresponds to a SHA1 ID that we
know about gets turned into a clickable link, and displayed in
blue and underlined.
We now keep a history of commits that we have looked at, and we
have forward and back buttons for moving within the history list.
If the graph gets to use more than a certain percentage (default 50%)
of the width of the top-left pane, we now reduce the amount of space
allowed for each graph line. This means it doesn't look quite as
nice but you can still see the headline for the commit. (Currently
the only way to customize the percentage is to edit your ~/.gitk
file manually.)
Specifically this should fix the following errors:
wrong # args: should be "startdiff ids" (fix from Junio Hamano)
can't read "filelines(....)": no such element in array
can't unset "treepending": no such variable
Now we see if the result is quite similar to one of the parents, and
if it is, display the result as a diff from that parent. If the result
is similar to more than one parent, pick the one that it's most
similar to.
Some places assumed .git is the GIT_DIR, resulting heads and
tags not showing when it was run like "GIT_DIR=. gitk --all".
This is not a contrived example --- I rely on it to verify
my private copy of git.git repository before pushing it out.
Define a single procedure "gitdir" and use it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Stuff that ended up in the result is shown in bold with a "+" at the
beginning of the line; stuff that didn't is in the normal font with
a "-" at the beginning of the line. The color shows which parent
the stuff was in; red for the first parent, blue for the second, then
green, purple, brown, and the rest are grey. If the result is different
from all of the parents it is shown in black (and bold).
If there is a GCA for the parents of the merge, then a file is
interesting if some parent has a version that is different from both
the child and the GCA. If there is no GCA (e.g. for a merge that
pulls in an external project) then a file is interesting if the child's
version is different from all of the parents.
Next step is to actually show the differences for the interesting
files...
We display the files where the child differs from the first parent
first in black in the file list window, followed by the second parent
in blue, and so on using different colors for each parent (provided
you don't have more than 6 parents; if you do we cycle around).
We now kick off a single git-diff-tree -r --stdin and feed it all
the commit pairs we want to know about, instead of doing a separate
git-diff-tree invocation for each.
"Files" matches the find string against each of the files modified
by each commit, and can do exact, case-ignoring or regexp matching.
"Pickaxe" uses git-diff-tree -S'string' and can only do exact
matching. I called it "pickaxe" rather than "find within patch"
since it only finds commits where the string is present in the child
but not the parents or vice versa, and "pickaxe" is what the author
of that feature calls it.
It's cheaper to calculate, and doesn't give different results depending
on the order of the arguments passed in (and is thus more appropriate
for something like gitk that can validly take the unordered "--all" flag
to show all branches).
The previous dup fix seems to have fixed --topo-order. Holler if you
still see problems.
This just invokes git-diff-tree. Also changed the readonly entry
widgets in the "write patch" and "generate tag" windows to have
flat relief, so it doesn't look like you should be able to modify
what's in them.
If we have a very long commit message, and we end up getting a
bufferfull of data from git-rev-list that all belongs to one commit,
we ended up throwing away the data from a previous read that should
have been included. The result was a error message about not being
able to parse the output of git-rev-list.
Also, if the git-rev-list output that we can't parse is long, only put
the first 80 chars in the error message. Otherwise we end up with an
enormous error window.
Check that $GIT_DIR (or .git, if GIT_DIR is not set) is a directory.
This means we can give a more informative error message if the user
runs gitk somewhere that isn't a git repository.
Right-click on a context row now brings up a menu allowing the user to
generate a diff between that row and the selected row. Left-click on
a graph line shows the parent and children connected by the line in
the details pane. Left-click on a circle in the graph selects that
commit. Left-click elsewhere in the graph does nothing.
When displaying a diff, the bottom-right file list box behaves
slightly differently now; instead of eliding all other files' diffs,
it now just scrolls the details pane so that the selected file's diff
starts at the top of the pane.
Since the diffs can be rather large, arrange for an update to be done
every 100ms while reading diffs.
Also removed the CVS revision keywords and bumped the version number
to 1.2.
With --header, git-rev-list gives us the contents of the commit
in-line, so we don't need to exec a git-cat-file to get it, and we
don't need the readobj command either.
Also fixed a residual problem with handling the commit that
has a parent listed twice.
This happens in the linux-2.6 tree. We draw the graph line
double-thick to show that this happened.
Also fix a bug where we got a bogus "No commit information available"
line at the end on simple repositories like this one.
Linus Torvalds