On Mon, 10 Jul 2006, Randal L. Schwartz wrote: > > Linus> Well, as long as you realize that that automatically means that you > Linus> have to walk the whole commit list, and you won't be able to get the > Linus> incremental output that git-log and friends normally are able to give? > > Wow. Yes, I think I can live with that for the application. It's a big deal for me, I often end up doing things like git log -p some-random-file to see what has happened, and getting the most recent changes basically instantaneously (rather than waiting for the thing to traverse all of the history) is a big deal. If you have a fairly small archive, or you don't use pathname limiting, the history generation is so fast that you'll never even notice. But with the kernel, doing something like git log drivers/serial takes just over two seconds for me, and if I had to wait for two seconds before the first data starts arriving, I'd go nuts. To see this in cold hard numbers: // Full log [torvalds@g5 linux]$ time git log drivers/serial > /dev/null real 0m2.267s user 0m2.204s sys 0m0.020s // Simulate "get the first screenful" [torvalds@g5 linux]$ time git log drivers/serial | head -25 > /dev/null real 0m0.054s user 0m0.048s sys 0m0.008s // Simulate "get the first screenful of reverse output" [torvalds@g5 linux]$ time git log --reverse drivers/serial | head > /dev/null real 0m2.218s user 0m2.176s sys 0m0.044s and it's the difference between the second and the third case I wanted to point out. The difference between getting the first screenful in 0.054 seconds versus it taking 2.218 seconds is quite noticeable, and one of the things I've actually spent a fair amount of time on is to make sure that the incremental output case is the _common_ one for all the normal operations like "git log -p". Linus - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html