Re: [RFC] faking cvs annotate

From: Linus Torvalds <torvalds@osdl.org>
Date: Dec 16, 2005, 17:07 UTC
Message-ID: <Pine.LNX.4.64.0512160843450.3060@g5.osdl.org>
In-Reply-To: <46a038f90512152037u66993aadg566a2a47abd279c9@mail.gmail.com>

On Fri, 16 Dec 2005, Martin Langhoff wrote:

Show 7 quoted lines

>
> On 12/16/05, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > For starters, you could use my attempt:
> > http://www.gelato.unsw.edu.au/archives/git/0508/7171.html
> 
> Not bad at all! I might simplify it a bit (won't need the commitmsg
> parsing), and see if how fast I can make it.

NOTE! You can make it a whole lot faster these days by passing the path down to git-rev-list. But as usual, I'm perl-incompatible, so I can't help you with that modification.

> OTOH, yours didn't get included. Any particular reasons? (other than
> stressing the point that you should use whatchanged/pickaxe?)

I'd love to see a git-annotate, but I want it to be efficient enough that it's not embarrassing.

For example, "git-whatchanged" is certainly efficient enough, and you could just parse that output (possible without using -p and comparing file contents on your own against the current HEAD as you progress backwards)

Or, you could now use "git-rev-list <rev> <filename>", which is even more efficient, but the downside of that is that it computes the _full_ graph before it starts outputting the early ones.

But, for example:

	[torvalds@g5 linux-history]$ time git-whatchanged drivers/char/Makefile > /dev/null 
	real    0m37.993s
	user    0m41.912s
	sys     0m0.400s

	[torvalds@g5 linux-history]$ time git-rev-list HEAD drivers/char/Makefile > /dev/null 
	real    0m6.713s
	user    0m6.656s
	sys     0m0.056s

that's the old Linux history thing, with 60,000+ commit. The path-based git-rev-list thing cuts it down to just 103 commits you need to look at (so the annotate itself should be really fast, and the cost really is all in that "git-rev-list" thing).

Of course, with the current kernel tree, the git-rev-list takes a lot less time, and only results in six commits, but that's a tree that only has a few months of history, so when looking at performance, you really should look at some bigger tree.

NOTE! You can also decide to cut down on time by saying "annotate back only to a specific date", ie something like

	git-rev-list $(git-rev-parse --since=2.years.ago HEAD) drivers/char/Makefile

which limits the thing by filename _and_ date (a good way to handle really really big projects) where the rev-parse might otherwise be very expensive.

And, of course, a quality implementation will notice when a file disappears, and use "git-diff-tree -M" on that commit to see if it was renamed, and then continuing with the old name...

			Linus