On Mon, 27 Mar 2006, Marco Costalba wrote: > > > > And that's the point. Almost always, we're interested in the _recent_ > > stuff. The fact that it takes longer to get the old history is not very > > important. You generally don't ask "what changed in this file" for a file > > that hasn't changed in five years. > > We could run git-rev-list with a time range specifier (changes of last > year as example) by default so to have fast results and run all time > history _only_ on request. Yes. However, what I've been meaning to do (but just haven't had the time and energy for so far) is to fix "git-rev-list" with a path limiter. Right now that always causes things to be totally serialized, and the revision walking will first look up _all_ the history (well, it will prune out the merges) before starting to output stuff. So right now in order for "git-whatchanged" to be fast and incremental, it doesn't do any path limiting with git-rev-list at ALL, and does it all in git-diff-tree. Which is horrid. > I still think the problem with annotation is that you don't see > patches that _remove_ lines of code, you need the whole diff for this. Well, that's just another reason "annotate" sucks. If you select a range of lines, my suggested tool _would_ show you lines that got removed there, and git-whatchanged does it quite well. I really think "annotate" is _fundamentally_ a broken operation. It's not what any sane developer actually wants, and it has serious limitations (ie it depends on whole history, and it cannot show removals well). 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