- pull from git://git.kernel.org/pub/scm/qgit/qgit4.git
- compile + install
- run qgit on the git repo
- select the 900 pounds gorilla called 'Makefile' from tree view ('t'
key shortcut)
- double click on it so to start file viewer and annotation
- say wahooo!
You get _all_ the hundreds (more then 800) of revisions of this
monster history annotated in the time it takes *other* ;-) tools to
annotate just one of them.
Ok. Come back to earth. I've just pushed some patches to use 'git log'
instead of 'git rev-list' as interface with git.
By using git-log with '-p' option it is possible to get a file history
_and_ corresponding diff in one pass instead of the double step
git-rev-list + git-diff-tree. Speed up it's huge.
But there are other gains:
- qgit can now be run with any command line argument known to 'git log'
- when Linus patch 'git log --follow' will be accepted by Junio the
following of file renames will come automatically
Unfortunately there are issues too:
- git-log lacks currently a --stdin option needed to pass a long list
of sha's, something that a tool sometime wants to do.
- because of the previous issue a StGIT repo under with a long list of
unapplied patches may break 'git log' loading.
- probably 'git log --follow' will come semi-automatically because an
incompatibility with '--parents' option, as pointed out by Linus,
needs a workaround. The latter is currently used to handle the grafts.
Marco
Marco Costalba [off-list ref] wrote:
You get _all_ the hundreds (more then 800) of revisions of this
monster history annotated in the time it takes *other* ;-) tools to
By "other tools" do you mean git-blame? ;-)
--
Shawn.
On 6/25/07, Shawn O. Pearce [off-list ref] wrote:
Marco Costalba [off-list ref] wrote:
quoted
You get _all_ the hundreds (more then 800) of revisions of this
monster history annotated in the time it takes *other* ;-) tools to
By "other tools" do you mean git-blame? ;-)
git-blame has some powerful features, like the possibility to follow
renames, and is fast enough for what it has to do, ie annotate _one_
file.
But missing to annotate all the file's history has its drawbacks for
using in a GUI tool, some clear, other not so clear:
- browsing among file revisions it's slow because after each user
'click' another annotation cycle should start from scratch (clear
issue).
- jumping from one file revision to another keeping the same mouse
selection or view (current line at the top of the view) is not
possible in general case without parsing all the annotations between
the two revisions.
- filtering, ie selecting with the mouse some lines and getting a
subset of the file history that modified at least one of that lines is
not possible.
So when 'git log --follow' patch will be mainstream I think current
qgit 'git log' based annotation will be superior to a git-blame based
interface under any point.
Regarding speed IMHO it is already faster, ie it takes already the
same or _less_ time to qgit to annotate all the 800 and more file's
revisions of git Makefile then to git-blame/git-gui to annotate _one_
of them.
Note that this is not a problem of implementation, but of algorithm.
Simply, the best algorithm to annotate one file is different from the
best one to annotate all of them. Another thing I've experienced is
that on old files in big repos (kernel/sched.c) the time to get the
file history its much bigger then time to annotate them.
Sure, in git-blame annotation it's incremental, you don't have to wait
the end of history loading to start to show stuff. I've used it, but,
probably a my limit, I really don't start to analyze what I have until
git-blame has finished.
So *for me*, the incremental blaming it's more or less a kind of fancy
progress bar, when you really care to search some blaming info.
Regarding the CVS oriented annotation of qgit it's simply a problem
that I have no space to show the commit when the user selects a line.
In git-gui the half bottom screen space is dedicated to that, in qgit
the half top space is instead reserved for file history. Anyhow in
qgit you can double click on any annotation line and the history will
jump to the corresponding revision, from there (right click->popup
menu) you can sync the other tabs so to see full commit and patch.
I'm thinking on a way to add a quick view of commit log message when
the user clicks/selects/something-else on a line (in qgit memory there
is already all the needed info, remember, annotation it's git-log
based), but the screen space it's an issue.
Marco
quoted
Marco Costalba [off-list ref] wrote:
- filtering, ie selecting with the mouse some lines and getting a
subset of the file history that modified at least one of that lines is
not possible.
I often use "git blame -L'/regexp/,/regexp/'" (you can use line
numbers there, too). Is this different from what you talk above?
--
しらいし ななこ http://ivory.ap.teacup.com/nanako3/
----------------------------------------------------------------------
Get a free email address with REAL anti-spam protection.
http://www.bluebottle.com