On Tue, 28 Nov 2006, Aaron Bentley wrote: > > I notice that blame has an option to limit the annotation to recent > history. I can only assume that is for performance reasons. You'd assume wrong. Trust me, if you talk about performance, bzr will lose. I can pretty much guarantee you that you perform worse. The mozilla discussion pointed to a performance test between hg and bzr, and hg in that test tended to perform better by a factor of 2-10. And git tends to be another factor faster than _that_. Performance is important to git, but it's important not in the sense of "let's not do it because it performs badly", but in the sense of "things should be so fast that people don't even realize that they are done". You guys may count commit times in seconds. I still want to commit multiple patches _per_second_ to the kernel tree. THAT is performance. So no, performance wasn't the reason. The reason is simple: be logical. The original blame/annotate semantics were git blame filename which is what people traditionally use, but then to specify which version to _start_ with (in case you wanted to go backwards in time), you had an optional revision argument at the end. Which is totally against how all the other git programs work, and I complained, because I had actually wanted to see the blame at a particular release version, and what my fingers typed didn't work. I want to be able to do git blame [revno] [--] filename the same way I can ask for a git log, git whatchanged, gitk, and any other such history tool. And once you do the same command line parsin as the other log-related commands, you pretty much automatically get the revision limiting. So now you can do git blame v2.6.17..v2.6.18 filename on the kernel archive to see who is to blame for certain lines in a certain _range_ of commits. It just fell out of using the same syntax everywhere. It's also happens to be useful. Quite often, you know something broke after a particular known-good release, so you're interested in the blame, but anything older than that known-good release is simply noise, and actually takes AWAY from the information, by just making things more cluttered. Linus - To unsubscribe from this list: 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