{"thread":{"id":"662","subject":"gitk-1.0 released","startedAt":"2005-05-19T13:05:20Z","lastAt":"2005-05-28T11:47:27Z","messageCount":14,"participants":["Paul Mackerras","Ingo Molnar","Benjamin Herrenschmidt","walt","Frank Sorenson","Kari Hameenaho","Linus Torvalds","Jon Seymour"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"3544","messageId":"17036.36624.911071.810357@cargo.ozlabs.ibm.com","threadId":"662","inReplyTo":null,"subject":"gitk-1.0 released","fromName":"Paul Mackerras","fromEmail":"paulus@samba.org","sentAt":"2005-05-19T13:05:20Z","receivedAt":"2005-05-19T13:05:20Z","isPatch":false,"sender":{"key":"paulus@samba.org","avatar":"https://avatars.githubusercontent.com/u/1606439?v=4"},"body":"I have released a new version of gitk. I got brave and called it 1.0\nand it is at:\n\n\thttp://ozlabs.org/~paulus/gitk-1.0\n\n(that's the actual script itself).\n\nGitk is a git commit viewer with the following features:\n\n* Clear and compact representation of the commit graph\n* Displays headline, author and date of each commit in the\n summary window\n* Displays the full details of one commit - the comments,\n list of files and colorized diff - in the details window\n* Find function for searching through commits\n* Displays the SHA1 ID of the selected commit and makes it\n the X selection so it can be pasted into other windows\n* Convenient key bindings for scanning through each commit\n in turn\n\nGitk passes its command-line arguments to git-rev-tree to allow you to\nselect the range of commits to display. With no arguments it will\ndisplay all the commits starting at HEAD.\n\nThe key bindings are:\n\nup or p: select the commit on the next line up from the current one\ndown or n: select the commit on the next line down from the current one\npageup: scroll the commit summary window up one page\npagedown: scroll the commit summary window down one page\ndelete or backspace or b: scroll the details window up one page\nspace: scroll the details window down one page\nu: scroll the details window up 18 lines\nd: scroll the details window down 18 lines\nf: move to the start of the next file diff in the details window\n^F: search for commits matching the search string\n^G or /: select the next commit matching the search string\n^R or ?: select the previous commit matching the search string\n^- or ^KP-: reduce the font size\n^= or ^KP+: increase the font size\n^Q: quit.\n\nFeatures added since the last release include:\n\n* Better error handling.\n* Gitk now remembers the layout of the window, so if you adjust the\n sizes of the panes to suit, then quit and restart, it should display\n the panes in the proportions you have chosen.\n* Instances of the search string are now highlighted in the details\n window as well as the summary window.\n* The circle diameter and line thickness now scale with the font size.\n* Accommodates the new git-diff-tree output format.\n\nPaul.\n"},{"id":"3546","messageId":"20050519132411.GA29111@elte.hu","threadId":"662","inReplyTo":"17036.36624.911071.810357@cargo.ozlabs.ibm.com","subject":"Re: gitk-1.0 released","fromName":"Ingo Molnar","fromEmail":"mingo@elte.hu","sentAt":"2005-05-19T13:24:11Z","receivedAt":"2005-05-19T13:24:11Z","isPatch":false,"sender":{"key":"mingo@elte.hu","avatar":null},"body":"\n* Paul Mackerras wrote:\n\n> I have released a new version of gitk. I got brave and called it 1.0\n> and it is at:\n> \n> \thttp://ozlabs.org/~paulus/gitk-1.0\n\nvery nice! Works well and it's pretty fast on a 2GHz P4.\n\na bugreport: when looking at the main git history, the following commit \nseems to be rendered incorrectly:\n\n 211232bae64bcc60bbf5d1b5e5b2344c22ed767e\n\nThe \"Octopus merge ...\" text is incorrectly overlayed with a graph line.\n\nhere's a feature wishlist if you dont mind:\n\n- the ability to copy & paste from all the windows would be nice. (e.g. \n in the bugreport above i had to type down the \"Octopus merge ..\" text \n instead of pasting it from gitk)\n\n- i guess this one is on your todo list: the history graph of a single\n object (file).\n\n- first window appearance on an uncached repository can be pretty slow \n due to disk seeks - so it might make sense to display something (an \n hourglass?) sooner - when i first started it i thought it hung. On \n already cached repositories the window comes up immediately, and the \n list of commits is updated dynamically.\n\n(and the biggest missing feature of GIT right now is author + \nlast-commit annotated file viewing which could be integrated into gitk \na'ka BK's revtool: selecting a given line of the file would bring one to \nthat commit, etc.)\n\n\tIngo\n"},{"id":"3547","messageId":"20050519133055.GA8076@elte.hu","threadId":"662","inReplyTo":"20050519132411.GA29111@elte.hu","subject":"Re: gitk-1.0 released","fromName":"Ingo Molnar","fromEmail":"mingo@elte.hu","sentAt":"2005-05-19T13:30:55Z","receivedAt":"2005-05-19T13:30:55Z","isPatch":false,"sender":{"key":"mingo@elte.hu","avatar":null},"body":"\n* Ingo Molnar wrote:\n\n> - the ability to copy & paste from all the windows would be nice. (e.g. \n> in the bugreport above i had to type down the \"Octopus merge ..\" text \n> instead of pasting it from gitk)\n\nscrap this one - the patch view window allows copy & paste, and the name \nof the patch is included there too.\n\n\tIngo\n"},{"id":"3588","messageId":"17037.5109.556362.904185@cargo.ozlabs.ibm.com","threadId":"662","inReplyTo":"20050519132411.GA29111@elte.hu","subject":"Re: gitk-1.0 released","fromName":"Paul Mackerras","fromEmail":"paulus@samba.org","sentAt":"2005-05-19T22:32:21Z","receivedAt":"2005-05-19T22:32:21Z","isPatch":false,"sender":{"key":"paulus@samba.org","avatar":"https://avatars.githubusercontent.com/u/1606439?v=4"},"body":"Ingo Molnar writes:\n\n> very nice! Works well and it's pretty fast on a 2GHz P4.\n\nI'm glad you like it. :)\n\n> The \"Octopus merge ...\" text is incorrectly overlayed with a graph line.\n\nThe patch below fixes that.\n\n> - i guess this one is on your todo list: the history graph of a single\n> object (file).\n\nYes. I was hoping that git-rev-tree would grow an option to do the\nnecessary selection of commits and produce a simplified graph. I\ncould do it in Tcl but it's probably better done in C.\n\n> - first window appearance on an uncached repository can be pretty slow \n> due to disk seeks - so it might make sense to display something (an \n> hourglass?) sooner - when i first started it i thought it hung. On \n> already cached repositories the window comes up immediately, and the \n> list of commits is updated dynamically.\n\nThe problem is that git-rev-tree HEAD doesn't output anything until it\nhas read all the relevant commits, which can involve a lot of disk\nseeks. I put the \"Reading commits...\" message in to indicate that\nsomething was happening, but your hourglass cursor suggestion is a\ngood one. It looks like git-rev-list might be better suited to what I\nwant, actually.\n\n> (and the biggest missing feature of GIT right now is author + \n> last-commit annotated file viewing which could be integrated into gitk \n> a'ka BK's revtool: selecting a given line of the file would bring one to \n> that commit, etc.)\n\nYes, indeed. I'll have to think about how to do it in a responsive\nfashion, since getting the necessary information involves reading all\nthe commits and all the tree objects back to the beginning of time,\nAFAICS. Gitk currently only reads the tree objects when you select a\ncommit, and it does that asynchronously; when you select a commit, it\nimmediately displays the commit message and starts a git-diff-tree\nprocess. When the output from git-diff-tree arrives, it updates the\nlistbox and then (if you haven't selected another commit in the\nmeantime) starts a git-diff-tree -p to get the diff. As the output\nfrom git-diff-tree arrives, it is colorized and placed in the details\nwindow. That's why you can let the up or down key autorepeat and gitk\ndoesn't get hopelessly behind.\n\nAnother thing I want to do is find a way to display the deleted lines\nin the annotated file listing. One thing I found quite frustrating\nwith bk revtool was trying to find which changeset deleted some\nparticular lines of code. I was basically reduced to binary searching\nthrough the changesets - and with a large source file, just finding\nthe place to check in the annotated listing for each changeset was\ntime-consuming and error-prone in itself.\n\nPaul.\n\ndiff -urN gitk-1.0/gitk gitk\n--- gitk-1.0/gitk\t2005-05-20 08:17:18.000000000 +1000\n+++ gitk\t2005-05-20 08:09:38.000000000 +1000\n@@ -563,6 +563,9 @@\n \t\t -fill $ofill -outline black -width 1]\n \t$canv raise $t\n \tset xt [expr $canvx0 + $nlines * $linespc]\n+\tif {$nparents($id) > 2} {\n+\t set xt [expr {$xt + ($nparents($id) - 2) * $linespc}]\n+\t}\n \tset headline [lindex $commitinfo($id) 0]\n \tset name [lindex $commitinfo($id) 1]\n \tset date [lindex $commitinfo($id) 2]\n"},{"id":"3591","messageId":"1116544421.5153.46.camel@gaston","threadId":"662","inReplyTo":"17036.36624.911071.810357@cargo.ozlabs.ibm.com","subject":"Re: gitk-1.0 released","fromName":"Benjamin Herrenschmidt","fromEmail":"benh@kernel.crashing.org","sentAt":"2005-05-19T23:13:41Z","receivedAt":"2005-05-19T23:13:41Z","isPatch":false,"sender":{"key":"benh@kernel.crashing.org","avatar":null},"body":"On Thu, 2005-05-19 at 23:05 +1000, Paul Mackerras wrote:\n> I have released a new version of gitk. I got brave and called it 1.0\n> and it is at:\n> \n> \thttp://ozlabs.org/~paulus/gitk-1.0\n> \n> (that's the actual script itself).\n> \n> Gitk is a git commit viewer with the following features:\n> \n> * Clear and compact representation of the commit graph\n> * Displays headline, author and date of each commit in the\n> summary window\n> * Displays the full details of one commit - the comments,\n> list of files and colorized diff - in the details window\n> * Find function for searching through commits\n> * Displays the SHA1 ID of the selected commit and makes it\n> the X selection so it can be pasted into other windows\n> * Convenient key bindings for scanning through each commit\n> in turn\n\nCool !\n\nHere's a feature request though: beeing able to type/paste a SHA1 in the\nSHA1 ID field to \"jump\" to that commit :)\n\nBen.\n\n\n"},{"id":"3594","messageId":"d6jdc5$f0u$1@sea.gmane.org","threadId":"662","inReplyTo":"17036.36624.911071.810357@cargo.ozlabs.ibm.com","subject":"Re: gitk-1.0 released","fromName":"walt","fromEmail":"wa1ter@myrealbox.com","sentAt":"2005-05-20T01:10:23Z","receivedAt":"2005-05-20T01:10:23Z","isPatch":false,"sender":{"key":"wa1ter@myrealbox.com","avatar":null},"body":"Paul Mackerras wrote:\n> I have released a new version of gitk. I got brave and called it 1.0\n> and it is at:\n> \n> \thttp://ozlabs.org/~paulus/gitk-1.0\n.\n.\n.\n\nToday, gitk works beautifully for me. Yesterday, though, I had a weird\nfirst experience when it opened a very attractive tcl/tk interface which\ndisplayed no text of any kind. I tried fiddling with the two menus you\nprovide, bit still no success.\n\nI finally just gave up. When I tried gitk again today -- it was magic!\nAll the kernel tree appeared just as (I suppose) you intended.\n\nAs far as I know, I did nothing to change anything since yesterday.\nCan you venture a guess why I had sucess today and failure yesterday?\n\nDoes gitk perhaps depend on a generated database of some kind before\nit will work properly?\n\n"},{"id":"3596","messageId":"428D6DB2.2050602@tuxrocks.com","threadId":"662","inReplyTo":"1116544421.5153.46.camel@gaston","subject":"Re: gitk-1.0 released","fromName":"Frank Sorenson","fromEmail":"frank@tuxrocks.com","sentAt":"2005-05-20T04:55:14Z","receivedAt":"2005-05-20T04:55:14Z","isPatch":false,"sender":{"key":"frank@tuxrocks.com","avatar":null},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nBenjamin Herrenschmidt wrote:\n> Cool !\n> \n> Here's a feature request though: beeing able to type/paste a SHA1 in the\n> SHA1 ID field to \"jump\" to that commit :)\n\nVery nice. I really like gitk as well. In addition to pasting an sha1\nin, how about pasting a tag?\n\nAlso, what about identifying tagged commits with a different color, a\nstar instead of just the round bullet, or some other identifier?\n\nFrank\n- --\nFrank Sorenson - KD7TZK\nSystems Manager, Computer Science Department\nBrigham Young University\nfrank@tuxrocks.com\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.2.6 (GNU/Linux)\nComment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org\n\niD8DBQFCjW2yaI0dwg4A47wRArsEAKCdkTBQEPD7yyb8ABiBg20nhdmKgACg2D2Y\nW0ZxoOGTOspvrRczeEYN9mg=\n=y2Z0\n-----END PGP SIGNATURE-----\n"},{"id":"3601","messageId":"20050520112229.GA5606@elte.hu","threadId":"662","inReplyTo":"17037.5109.556362.904185@cargo.ozlabs.ibm.com","subject":"Re: gitk-1.0 released","fromName":"Ingo Molnar","fromEmail":"mingo@elte.hu","sentAt":"2005-05-20T11:22:29Z","receivedAt":"2005-05-20T11:22:29Z","isPatch":false,"sender":{"key":"mingo@elte.hu","avatar":null},"body":"\n* Paul Mackerras wrote:\n\n> > (and the biggest missing feature of GIT right now is author + \n> > last-commit annotated file viewing which could be integrated into gitk \n> > a'ka BK's revtool: selecting a given line of the file would bring one to \n> > that commit, etc.)\n> \n> Yes, indeed. I'll have to think about how to do it in a responsive \n> fashion, since getting the necessary information involves reading all \n> the commits and all the tree objects back to the beginning of time, \n> AFAICS. [...]\n\ni guess so. A possible solution seems to be to read every object \nstarting at the oldest one (assuming it's possible to get a list of \nobject IDs that are predecessors), and to split the oldest object up \ninto 'line' objects, attaching the (same) object ID to every line. Then \nthe algorithm would go forward in time and would process every diff from \nthat point on, and would add/remove line objects, attaching the new \nobject IDs as new lines get added. The resulting set of lines then \ncontain all the metadata needed (== object ID they originate from).\n\ni dont think other SCMs can do this much faster: you need to go back to \nthe last (still relevant) version and have to process the deltas from \nthat point on. Delta-based formats would be somewhat faster and easier \nto process, but probably not that much faster in terms of IO overhead.\n\n\tIngo\n"},{"id":"3602","messageId":"20050520113334.GA19810@elte.hu","threadId":"662","inReplyTo":"17037.5109.556362.904185@cargo.ozlabs.ibm.com","subject":"Re: gitk-1.0 released","fromName":"Ingo Molnar","fromEmail":"mingo@elte.hu","sentAt":"2005-05-20T11:33:34Z","receivedAt":"2005-05-20T11:33:34Z","isPatch":false,"sender":{"key":"mingo@elte.hu","avatar":null},"body":"\n* Paul Mackerras wrote:\n\n> > - first window appearance on an uncached repository can be pretty slow \n> > due to disk seeks - so it might make sense to display something (an \n> > hourglass?) sooner - when i first started it i thought it hung. On \n> > already cached repositories the window comes up immediately, and the \n> > list of commits is updated dynamically.\n> \n> The problem is that git-rev-tree HEAD doesn't output anything until it \n> has read all the relevant commits, which can involve a lot of disk \n> seeks. I put the \"Reading commits...\" message in to indicate that \n> something was happening, but your hourglass cursor suggestion is a \n> good one. It looks like git-rev-list might be better suited to what I \n> want, actually.\n\nit was quite a couple of seconds to get the empty windows with the \n'Reading commits...' message. It was this first period of time (5-10 \nseconds?) which i mistook for a hang. Perhaps this is some Tk startup \nslowness, not a genuine gitk issue?\n\n> +\tif {$nparents($id) > 2} {\n> +\t set xt [expr {$xt + ($nparents($id) - 2) * $linespc}]\n> +\t}\n\nthanks, this fix did the trick.\n\n\tIngo\n"},{"id":"3631","messageId":"d6l9l1$ttd$1@sea.gmane.org","threadId":"662","inReplyTo":"17037.5109.556362.904185@cargo.ozlabs.ibm.com","subject":"Re: gitk-1.0 released","fromName":"Kari Hameenaho","fromEmail":"khaho@kolumbus.fi","sentAt":"2005-05-20T18:18:59Z","receivedAt":"2005-05-20T18:18:59Z","isPatch":false,"sender":{"key":"khaho@kolumbus.fi","avatar":null},"body":"Paul Mackerras wrote:\n\n> \n> Yes, indeed. I'll have to think about how to do it in a responsive\n> fashion, since getting the necessary information involves reading all\n> the commits and all the tree objects back to the beginning of time,\n> AFAICS. \n\nMaybe its not necessary to go back all the way. It is possible to look only\ncommits between 2.6.12-rc4 and 2.6.12-rc3, like follows (needs just a few\nfixes to gitk):\n\ngitk -d $(commit-id v2.6.12-rc4) ^$(parent-id $(commit-id v2.6.12-rc3))\n\n-- \nKari Hämeenaho\n\n\n"},{"id":"3635","messageId":"Pine.LNX.4.58.0505201150220.2206@ppc970.osdl.org","threadId":"662","inReplyTo":"d6l9l1$ttd$1@sea.gmane.org","subject":"Re: gitk-1.0 released","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-05-20T19:07:48Z","receivedAt":"2005-05-20T19:07:48Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 20 May 2005, Kari Hameenaho wrote:\n> Paul Mackerras wrote:\n> > \n> > Yes, indeed. I'll have to think about how to do it in a responsive\n> > fashion, since getting the necessary information involves reading all\n> > the commits and all the tree objects back to the beginning of time,\n> > AFAICS. \n> \n> Maybe its not necessary to go back all the way. It is possible to look only\n> commits between 2.6.12-rc4 and 2.6.12-rc3, like follows (needs just a few\n> fixes to gitk):\n> \n> gitk -d $(commit-id v2.6.12-rc4) ^$(parent-id $(commit-id v2.6.12-rc3))\n\nBut that _does_ actually go back all the way in time.\n\nIt does so inside of \"git-rev-tree\", and that's why git-rev-tree is slow.\n\nWhat you can do, is to special-case certain things that git-rev-tree does, \nand try to do them more efficiently.\n\nFor example, git-rev-list is much nicer to use, exactly because it does\nonly one very particular special case of what git-rev-tree does, ie \"list\nall revisions\". Because it's a special case, you can do it incrementally.\n\nSimilarly, you _can_ actually do \"git-rev-tree HEAD ^OLD_HEAD\" as a\nspecial case too, and do it \"as incrementally as possible\". It's more\ncomplicated than the (trivial) git-rev-list, so I've not actually done it,\nbut it's clearly important enough that I _should_ do it.\n\nThe way to do it \"as incrementally as possible\" is to start with the \nHEAD, and walk down and print out everything until you hit OLD_HEAD or a \nmerge. Then:\n - If you hit OLD_HEAD, you're done.\n - If you hit a merge, you know the merge itself wasn't in OLD_HEAD, but \n now one of the sides might contain OLD_HEAD which might have a merge\n pointing to the other side, so you don't know if you should show any of \n the commits below it. What you do is:\n - walk down both paths in date order - like rev-list does - until you \n _do_ hit OLD_HEAD. Here \"date order\" ends up being an approximation \n for \"how do I avoid going down a long chain that ends up already \n being pointed to by OLD_HEAD\"\n - mark everything reachable from OLD_HEAD as being uninteresting (aka \n \"seen\"), and everything that reaches OLD_HEAD as being interesting\n and print it out.\n - as long as there are commits that aren't marked either uninteresting \n _or_ interesting (they are unknown) continue to walk the commit \n chain in date order, where the parent(s) of an uninteresting commit \n is always uninteresting.\n - eventually, you'll have no unknowns left, and you can stop.\n\nIn the worst case, you'll end up walking back to the root (somebody did\ndevelopment against the root, and then merged that development up after\nOLD_HEAD), but that ends up being increasingly unlikely as the project\ngrows, so in practice this kind of algorithm will always end up doign work\nthat is comparable to the amount of development between OLD_HEAD and HEAD,\nand independent of the total history size.\n\nI might have missed some detail in the above, but it should be _fairly_\nstraightforward to start with rev-list.c and make it generate the lists of\n\"interesting\", \"uninteresting\" and \"unknown\" commits and do the above.\n\nIs anybody up for coding up this small exercise in graph traversal?\n\n\t\tLinus\n"},{"id":"3683","messageId":"2cfc40320505202340e5d1aee@mail.gmail.com","threadId":"662","inReplyTo":"Pine.LNX.4.58.0505201150220.2206@ppc970.osdl.org","subject":"Re: gitk-1.0 released","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2005-05-21T06:40:09Z","receivedAt":"2005-05-21T06:40:09Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"> - mark everything reachable from OLD_HEAD as being uninteresting (aka\n> \"seen\"), and everything that reaches OLD_HEAD as being interesting\n> and print it out.\n\nWon't this step end up traversing back to the root anyway?\n\njon.\n\n\n-- \nhomepage: http://www.zeta.org.au/~jon/\nblog: http://orwelliantremors.blogspot.com/\n"},{"id":"3698","messageId":"Pine.LNX.4.58.0505210934290.2206@ppc970.osdl.org","threadId":"662","inReplyTo":"2cfc40320505202340e5d1aee@mail.gmail.com","subject":"Re: gitk-1.0 released","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-05-21T16:35:34Z","receivedAt":"2005-05-21T16:35:34Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 21 May 2005, Jon Seymour wrote:\n>\n> > - mark everything reachable from OLD_HEAD as being uninteresting (aka\n> > \"seen\"), and everything that reaches OLD_HEAD as being interesting\n> > and print it out.\n> \n> Won't this step end up traversing back to the root anyway?\n\nSorry, bad wording on my part. Here \"reachable\" means only withing the \ncontext of \"currently parsed\", not \"globally reachable\".\n\nSo no, the reachability tests would not traverse anywhere new.\n\n\t\tLinus\n"},{"id":"4135","messageId":"20050528114727.GA1812@elte.hu","threadId":"662","inReplyTo":"17036.36624.911071.810357@cargo.ozlabs.ibm.com","subject":"Re: gitk-1.0 released","fromName":"Ingo Molnar","fromEmail":"mingo@elte.hu","sentAt":"2005-05-28T11:47:27Z","receivedAt":"2005-05-28T11:47:27Z","isPatch":false,"sender":{"key":"mingo@elte.hu","avatar":null},"body":"\nanother small bug: if you click into the main window _before_ the commit \nlist has been fully generated (i.e. into the empty window) then all \nsorts of error messages pop up. (\"Cant use empty string ...\")\n\n\tIngo\n"}]}