Re: [RFC] faking cvs annotate

On Fri, 16 Dec 2005, Martin Langhoff wrote:

On 12/16/05, Johannes Schindelin [off-list ref] wrote:

quoted

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