{"thread":{"id":"8690","subject":"qgit: Annotate hundreds of files at terrific speed ;-)","startedAt":"2007-06-23T16:35:11Z","lastAt":"2007-06-25T11:20:48Z","messageCount":5,"participants":["Marco Costalba","Shawn O. Pearce","Nanako Shiraishi"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"45615","messageId":"e5bfff550706230935m5363a6dava9dbd62a56a1b685@mail.gmail.com","threadId":"8690","inReplyTo":null,"subject":"qgit: Annotate hundreds of files at terrific speed ;-)","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-06-23T16:35:11Z","receivedAt":"2007-06-23T16:35:11Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"- pull from git://git.kernel.org/pub/scm/qgit/qgit4.git\n\n- compile + install\n\n- run qgit on the git repo\n\n- select the 900 pounds gorilla called 'Makefile' from tree view ('t'\nkey shortcut)\n\n- double click on it so to start file viewer and annotation\n\n- say wahooo!\n\nYou get _all_ the hundreds (more then 800) of revisions of this\nmonster history annotated in the time it takes *other* ;-) tools to\nannotate just one of them.\n\n\n\nOk. Come back to earth. I've just pushed some patches to use 'git log'\ninstead of 'git rev-list' as interface with git.\n\nBy using git-log with '-p' option it is possible to get a file history\n_and_ corresponding diff in one pass instead of the double step\ngit-rev-list + git-diff-tree. Speed up it's huge.\n\nBut there are other gains:\n\n- qgit can now be run with any command line argument known to 'git log'\n\n- when Linus patch 'git log --follow' will be accepted by Junio the\nfollowing of file renames will come automatically\n\n\nUnfortunately there are issues too:\n\n- git-log lacks currently a --stdin option needed to pass a long list\nof sha's, something that a tool sometime wants to do.\n\n- because of the previous issue a StGIT repo under with a long list of\nunapplied patches may break 'git log' loading.\n\n- probably 'git log --follow' will come semi-automatically because an\nincompatibility with '--parents' option, as pointed out by Linus,\nneeds a workaround. The latter is currently used to handle the grafts.\n\n\nMarco\n"},{"id":"45712","messageId":"20070624230851.GN17393@spearce.org","threadId":"8690","inReplyTo":"e5bfff550706230935m5363a6dava9dbd62a56a1b685@mail.gmail.com","subject":"Re: qgit: Annotate hundreds of files at terrific speed ;-)","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-06-24T23:08:52Z","receivedAt":"2007-06-24T23:08:52Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Marco Costalba wrote:\n> You get _all_ the hundreds (more then 800) of revisions of this\n> monster history annotated in the time it takes *other* ;-) tools to\n\nBy \"other tools\" do you mean git-blame? ;-)\n\n-- \nShawn.\n"},{"id":"45732","messageId":"e5bfff550706242259s143fe874mf82736426e94ecba@mail.gmail.com","threadId":"8690","inReplyTo":"20070624230851.GN17393@spearce.org","subject":"Re: qgit: Annotate hundreds of files at terrific speed ;-)","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-06-25T05:59:07Z","receivedAt":"2007-06-25T05:59:07Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 6/25/07, Shawn O. Pearce wrote:\n> Marco Costalba wrote:\n> > You get _all_ the hundreds (more then 800) of revisions of this\n> > monster history annotated in the time it takes *other* ;-) tools to\n>\n> By \"other tools\" do you mean git-blame? ;-)\n>\n\ngit-blame has some powerful features, like the possibility to follow\nrenames, and is fast enough for what it has to do, ie annotate _one_\nfile.\n\nBut missing to annotate all the file's history has its drawbacks for\nusing in a GUI tool, some clear, other not so clear:\n\n- browsing among file revisions it's slow because after each user\n'click' another annotation cycle should start from scratch (clear\nissue).\n\n- jumping from one file revision to another keeping the same mouse\nselection or view (current line at the top of the view) is not\npossible in general case without parsing all the annotations between\nthe two revisions.\n\n- filtering, ie selecting with the mouse some lines and getting a\nsubset of the file history that modified at least one of that lines is\nnot possible.\n\n\nSo when 'git log --follow' patch will be mainstream I think current\nqgit 'git log' based annotation will be superior to a git-blame based\ninterface under any point.\n\nRegarding speed IMHO it is already faster, ie it takes already the\nsame or _less_ time to qgit to annotate all the 800 and more file's\nrevisions of git Makefile then to git-blame/git-gui to annotate _one_\nof them.\n\nNote that this is not a problem of implementation, but of algorithm.\nSimply, the best algorithm to annotate one file is different from the\nbest one to annotate all of them. Another thing I've experienced is\nthat on old files in big repos (kernel/sched.c) the time to get the\nfile history its much bigger then time to annotate them.\n\n\nSure, in git-blame annotation it's incremental, you don't have to wait\nthe end of history loading to start to show stuff. I've used it, but,\nprobably a my limit, I really don't start to analyze what I have until\ngit-blame has finished.\n\nSo *for me*, the incremental blaming it's more or less a kind of fancy\nprogress bar, when you really care to search some blaming info.\n\n\nRegarding the CVS oriented annotation of qgit it's simply a problem\nthat I have no space to show the commit when the user selects a line.\nIn git-gui the half bottom screen space is dedicated to that, in qgit\nthe half top space is instead reserved for file history. Anyhow in\nqgit you can double click on any annotation line and the history will\njump to the corresponding revision, from there (right click->popup\nmenu) you can sync the other tabs so to see full commit and patch.\n\nI'm thinking on a way to add a quick view of commit log message when\nthe user clicks/selects/something-else on a line (in qgit memory there\nis already all the needed info, remember, annotation it's git-log\nbased), but the screen space it's an issue.\n\n\nMarco\n"},{"id":"45736","messageId":"200706250638.l5P6crkR026564@mi1.bluebottle.com","threadId":"8690","inReplyTo":"e5bfff550706242259s143fe874mf82736426e94ecba@mail.gmail.com","subject":"Re: qgit: Annotate hundreds of files at terrific speed ;-)","fromName":"Nanako Shiraishi","fromEmail":"nanako3@bluebottle.com","sentAt":"2007-06-25T06:35:21Z","receivedAt":"2007-06-25T06:35:21Z","isPatch":false,"sender":{"key":"nanako3@lavabit.com","avatar":"https://gravatar.com/avatar/3777b9e201c5883a62b1a6fdf7c53f2d712d1d80989146063ea861e33aad72a8?d=mp&s=160"},"body":"\n>> Marco Costalba wrote:\n>\n> - filtering, ie selecting with the mouse some lines and getting a\n> subset of the file history that modified at least one of that lines is\n> not possible.\n\nI often use \"git blame -L'/regexp/,/regexp/'\" (you can use line\nnumbers there, too). Is this different from what you talk above?\n\n-- \nしらいし ななこ http://ivory.ap.teacup.com/nanako3/\n\n----------------------------------------------------------------------\nGet a free email address with REAL anti-spam protection.\nhttp://www.bluebottle.com\n"},{"id":"45762","messageId":"e5bfff550706250420s603e36eds9a2bcbb339aac80e@mail.gmail.com","threadId":"8690","inReplyTo":"200706250638.l5P6crkS026564@mi1.bluebottle.com","subject":"Re: qgit: Annotate hundreds of files at terrific speed ;-)","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-06-25T11:20:48Z","receivedAt":"2007-06-25T11:20:48Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 6/25/07, Nanako Shiraishi wrote:\n>\n> >> Marco Costalba wrote:\n> >\n> > - filtering, ie selecting with the mouse some lines and getting a\n> > subset of the file history that modified at least one of that lines is\n> > not possible.\n>\n> I often use \"git blame -L'/regexp/,/regexp/'\" (you can use line\n> numbers there, too). Is this different from what you talk above?\n>\n\nYes it.\n\nSuppose you have selected file lines from 20 to 23 in revision A.\n\nRevision history it's the following, in cronological order:\n\nA (oldest) -> B - > C (newest)\n\nSay that in revision B the patch removed 5 lines from 5 to 10 and\nadded 2 new lines instead.\n\nNow when you jump from A to revision C you may want to see selected\nthe lines (-5 + 2 = -3) from 17 to 20 and no more the lines from 20 to\n23 that will point to a different content.\n\n\nIn a general case jumping from a revision A to a revision N you have to:\n\n- get the list of intermediate revision\n\n- for each revision calculate deleted/ added content that is before\nthe selected lines range.\n\n- for each revision calculate deleted/ added content that CROSSES the\nselected range, so that if in our example revision B adds also 2 new\nlines in position 21 the selection in C will not be 17 to 20 but 17 to\n22! The same logic in case of deleted lines in selected range.\n\nSo to keep a \"consistent\" mouse selection when jumping to different\nfile revisions you really need to know all the annotate history in\nbetween.\n\n\nMarco\n"}]}