From: Paul Mackerras <hidden> Date: 2016-06-15 22:41:57
I have released a new version of gitk. I got brave and called it 1.0
and it is at:
http://ozlabs.org/~paulus/gitk-1.0
(that's the actual script itself).
Gitk is a git commit viewer with the following features:
* Clear and compact representation of the commit graph
* Displays headline, author and date of each commit in the
summary window
* Displays the full details of one commit - the comments,
list of files and colorized diff - in the details window
* Find function for searching through commits
* Displays the SHA1 ID of the selected commit and makes it
the X selection so it can be pasted into other windows
* Convenient key bindings for scanning through each commit
in turn
Gitk passes its command-line arguments to git-rev-tree to allow you to
select the range of commits to display. With no arguments it will
display all the commits starting at HEAD.
The key bindings are:
up or p: select the commit on the next line up from the current one
down or n: select the commit on the next line down from the current one
pageup: scroll the commit summary window up one page
pagedown: scroll the commit summary window down one page
delete or backspace or b: scroll the details window up one page
space: scroll the details window down one page
u: scroll the details window up 18 lines
d: scroll the details window down 18 lines
f: move to the start of the next file diff in the details window
^F: search for commits matching the search string
^G or /: select the next commit matching the search string
^R or ?: select the previous commit matching the search string
^- or ^KP-: reduce the font size
^= or ^KP+: increase the font size
^Q: quit.
Features added since the last release include:
* Better error handling.
* Gitk now remembers the layout of the window, so if you adjust the
sizes of the panes to suit, then quit and restart, it should display
the panes in the proportions you have chosen.
* Instances of the search string are now highlighted in the details
window as well as the summary window.
* The circle diameter and line thickness now scale with the font size.
* Accommodates the new git-diff-tree output format.
Paul.
very nice! Works well and it's pretty fast on a 2GHz P4.
a bugreport: when looking at the main git history, the following commit
seems to be rendered incorrectly:
211232bae64bcc60bbf5d1b5e5b2344c22ed767e
The "Octopus merge ..." text is incorrectly overlayed with a graph line.
here's a feature wishlist if you dont mind:
- the ability to copy & paste from all the windows would be nice. (e.g.
in the bugreport above i had to type down the "Octopus merge .." text
instead of pasting it from gitk)
- i guess this one is on your todo list: the history graph of a single
object (file).
- first window appearance on an uncached repository can be pretty slow
due to disk seeks - so it might make sense to display something (an
hourglass?) sooner - when i first started it i thought it hung. On
already cached repositories the window comes up immediately, and the
list of commits is updated dynamically.
(and the biggest missing feature of GIT right now is author +
last-commit annotated file viewing which could be integrated into gitk
a'ka BK's revtool: selecting a given line of the file would bring one to
that commit, etc.)
Ingo
- the ability to copy & paste from all the windows would be nice. (e.g.
in the bugreport above i had to type down the "Octopus merge .." text
instead of pasting it from gitk)
scrap this one - the patch view window allows copy & paste, and the name
of the patch is included there too.
Ingo
From: Paul Mackerras <hidden> Date: 2016-06-15 22:41:57
Ingo Molnar writes:
very nice! Works well and it's pretty fast on a 2GHz P4.
I'm glad you like it. :)
The "Octopus merge ..." text is incorrectly overlayed with a graph line.
The patch below fixes that.
- i guess this one is on your todo list: the history graph of a single
object (file).
Yes. I was hoping that git-rev-tree would grow an option to do the
necessary selection of commits and produce a simplified graph. I
could do it in Tcl but it's probably better done in C.
- first window appearance on an uncached repository can be pretty slow
due to disk seeks - so it might make sense to display something (an
hourglass?) sooner - when i first started it i thought it hung. On
already cached repositories the window comes up immediately, and the
list of commits is updated dynamically.
The problem is that git-rev-tree HEAD doesn't output anything until it
has read all the relevant commits, which can involve a lot of disk
seeks. I put the "Reading commits..." message in to indicate that
something was happening, but your hourglass cursor suggestion is a
good one. It looks like git-rev-list might be better suited to what I
want, actually.
(and the biggest missing feature of GIT right now is author +
last-commit annotated file viewing which could be integrated into gitk
a'ka BK's revtool: selecting a given line of the file would bring one to
that commit, etc.)
Yes, indeed. I'll have to think about how to do it in a responsive
fashion, since getting the necessary information involves reading all
the commits and all the tree objects back to the beginning of time,
AFAICS. Gitk currently only reads the tree objects when you select a
commit, and it does that asynchronously; when you select a commit, it
immediately displays the commit message and starts a git-diff-tree
process. When the output from git-diff-tree arrives, it updates the
listbox and then (if you haven't selected another commit in the
meantime) starts a git-diff-tree -p to get the diff. As the output
from git-diff-tree arrives, it is colorized and placed in the details
window. That's why you can let the up or down key autorepeat and gitk
doesn't get hopelessly behind.
Another thing I want to do is find a way to display the deleted lines
in the annotated file listing. One thing I found quite frustrating
with bk revtool was trying to find which changeset deleted some
particular lines of code. I was basically reduced to binary searching
through the changesets - and with a large source file, just finding
the place to check in the annotated listing for each changeset was
time-consuming and error-prone in itself.
Paul.
diff -urN gitk-1.0/gitk gitk
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2016-06-15 22:41:57
On Thu, 2005-05-19 at 23:05 +1000, Paul Mackerras wrote:
I have released a new version of gitk. I got brave and called it 1.0
and it is at:
http://ozlabs.org/~paulus/gitk-1.0
(that's the actual script itself).
Gitk is a git commit viewer with the following features:
* Clear and compact representation of the commit graph
* Displays headline, author and date of each commit in the
summary window
* Displays the full details of one commit - the comments,
list of files and colorized diff - in the details window
* Find function for searching through commits
* Displays the SHA1 ID of the selected commit and makes it
the X selection so it can be pasted into other windows
* Convenient key bindings for scanning through each commit
in turn
Cool !
Here's a feature request though: beeing able to type/paste a SHA1 in the
SHA1 ID field to "jump" to that commit :)
Ben.
.
.
.
Today, gitk works beautifully for me. Yesterday, though, I had a weird
first experience when it opened a very attractive tcl/tk interface which
displayed no text of any kind. I tried fiddling with the two menus you
provide, bit still no success.
I finally just gave up. When I tried gitk again today -- it was magic!
All the kernel tree appeared just as (I suppose) you intended.
As far as I know, I did nothing to change anything since yesterday.
Can you venture a guess why I had sucess today and failure yesterday?
Does gitk perhaps depend on a generated database of some kind before
it will work properly?
From: Frank Sorenson <hidden> Date: 2016-06-15 22:41:57
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Benjamin Herrenschmidt wrote:
Cool !
Here's a feature request though: beeing able to type/paste a SHA1 in the
SHA1 ID field to "jump" to that commit :)
Very nice. I really like gitk as well. In addition to pasting an sha1
in, how about pasting a tag?
Also, what about identifying tagged commits with a different color, a
star instead of just the round bullet, or some other identifier?
Frank
- --
Frank Sorenson - KD7TZK
Systems Manager, Computer Science Department
Brigham Young University
frank@tuxrocks.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCjW2yaI0dwg4A47wRArsEAKCdkTBQEPD7yyb8ABiBg20nhdmKgACg2D2Y
W0ZxoOGTOspvrRczeEYN9mg=
=y2Z0
-----END PGP SIGNATURE-----
(and the biggest missing feature of GIT right now is author +
last-commit annotated file viewing which could be integrated into gitk
a'ka BK's revtool: selecting a given line of the file would bring one to
that commit, etc.)
Yes, indeed. I'll have to think about how to do it in a responsive
fashion, since getting the necessary information involves reading all
the commits and all the tree objects back to the beginning of time,
AFAICS. [...]
i guess so. A possible solution seems to be to read every object
starting at the oldest one (assuming it's possible to get a list of
object IDs that are predecessors), and to split the oldest object up
into 'line' objects, attaching the (same) object ID to every line. Then
the algorithm would go forward in time and would process every diff from
that point on, and would add/remove line objects, attaching the new
object IDs as new lines get added. The resulting set of lines then
contain all the metadata needed (== object ID they originate from).
i dont think other SCMs can do this much faster: you need to go back to
the last (still relevant) version and have to process the deltas from
that point on. Delta-based formats would be somewhat faster and easier
to process, but probably not that much faster in terms of IO overhead.
Ingo
- first window appearance on an uncached repository can be pretty slow
due to disk seeks - so it might make sense to display something (an
hourglass?) sooner - when i first started it i thought it hung. On
already cached repositories the window comes up immediately, and the
list of commits is updated dynamically.
The problem is that git-rev-tree HEAD doesn't output anything until it
has read all the relevant commits, which can involve a lot of disk
seeks. I put the "Reading commits..." message in to indicate that
something was happening, but your hourglass cursor suggestion is a
good one. It looks like git-rev-list might be better suited to what I
want, actually.
it was quite a couple of seconds to get the empty windows with the
'Reading commits...' message. It was this first period of time (5-10
seconds?) which i mistook for a hang. Perhaps this is some Tk startup
slowness, not a genuine gitk issue?
+ if {$nparents($id) > 2} {
+ set xt [expr {$xt + ($nparents($id) - 2) * $linespc}]
+ }
From: Kari Hameenaho <hidden> Date: 2016-06-15 22:41:57
Paul Mackerras wrote:
Yes, indeed. I'll have to think about how to do it in a responsive
fashion, since getting the necessary information involves reading all
the commits and all the tree objects back to the beginning of time,
AFAICS.
Maybe its not necessary to go back all the way. It is possible to look only
commits between 2.6.12-rc4 and 2.6.12-rc3, like follows (needs just a few
fixes to gitk):
gitk -d $(commit-id v2.6.12-rc4) ^$(parent-id $(commit-id v2.6.12-rc3))
--
Kari Hämeenaho
Yes, indeed. I'll have to think about how to do it in a responsive
fashion, since getting the necessary information involves reading all
the commits and all the tree objects back to the beginning of time,
AFAICS.
Maybe its not necessary to go back all the way. It is possible to look only
commits between 2.6.12-rc4 and 2.6.12-rc3, like follows (needs just a few
fixes to gitk):
gitk -d $(commit-id v2.6.12-rc4) ^$(parent-id $(commit-id v2.6.12-rc3))
But that _does_ actually go back all the way in time.
It does so inside of "git-rev-tree", and that's why git-rev-tree is slow.
What you can do, is to special-case certain things that git-rev-tree does,
and try to do them more efficiently.
For example, git-rev-list is much nicer to use, exactly because it does
only one very particular special case of what git-rev-tree does, ie "list
all revisions". Because it's a special case, you can do it incrementally.
Similarly, you _can_ actually do "git-rev-tree HEAD ^OLD_HEAD" as a
special case too, and do it "as incrementally as possible". It's more
complicated than the (trivial) git-rev-list, so I've not actually done it,
but it's clearly important enough that I _should_ do it.
The way to do it "as incrementally as possible" is to start with the
HEAD, and walk down and print out everything until you hit OLD_HEAD or a
merge. Then:
- If you hit OLD_HEAD, you're done.
- If you hit a merge, you know the merge itself wasn't in OLD_HEAD, but
now one of the sides might contain OLD_HEAD which might have a merge
pointing to the other side, so you don't know if you should show any of
the commits below it. What you do is:
- walk down both paths in date order - like rev-list does - until you
_do_ hit OLD_HEAD. Here "date order" ends up being an approximation
for "how do I avoid going down a long chain that ends up already
being pointed to by OLD_HEAD"
- mark everything reachable from OLD_HEAD as being uninteresting (aka
"seen"), and everything that reaches OLD_HEAD as being interesting
and print it out.
- as long as there are commits that aren't marked either uninteresting
_or_ interesting (they are unknown) continue to walk the commit
chain in date order, where the parent(s) of an uninteresting commit
is always uninteresting.
- eventually, you'll have no unknowns left, and you can stop.
In the worst case, you'll end up walking back to the root (somebody did
development against the root, and then merged that development up after
OLD_HEAD), but that ends up being increasingly unlikely as the project
grows, so in practice this kind of algorithm will always end up doign work
that is comparable to the amount of development between OLD_HEAD and HEAD,
and independent of the total history size.
I might have missed some detail in the above, but it should be _fairly_
straightforward to start with rev-list.c and make it generate the lists of
"interesting", "uninteresting" and "unknown" commits and do the above.
Is anybody up for coding up this small exercise in graph traversal?
Linus
From: Jon Seymour <hidden> Date: 2016-06-15 22:41:58
- mark everything reachable from OLD_HEAD as being uninteresting (aka
"seen"), and everything that reaches OLD_HEAD as being interesting
and print it out.
- mark everything reachable from OLD_HEAD as being uninteresting (aka
"seen"), and everything that reaches OLD_HEAD as being interesting
and print it out.
Won't this step end up traversing back to the root anyway?
Sorry, bad wording on my part. Here "reachable" means only withing the
context of "currently parsed", not "globally reachable".
So no, the reachability tests would not traverse anywhere new.
Linus
another small bug: if you click into the main window _before_ the commit
list has been fully generated (i.e. into the empty window) then all
sorts of error messages pop up. ("Cant use empty string ...")
Ingo