Michael Haggerty <mhagger@xxxxxxxxxxxx> writes: > The reason that cvs annotate is so much faster than git blame is that > CVS stores revisions filewise, with all of the modifications to file > $FILE being stored in a single $FILE,v file. So in the worst case, CVS > only has to read this one file. > > Git, on the other hand, stores revisions treewise. It has no way of > knowing, ab initio, which revisions touched a given file. (In fact, this > concept is not even well-defined because the answer depends on things > like whether copy (-C) and move (-M) detection are turned on and what > parameters they were given.) This means that git blame has to traverse > most of history to find the commits that touched $FILE. > > Slow git blame is thus a relatively unavoidable consequence of Git's > data model. That's not to say that it can't be sped up somewhat, but it > will never reach CVS speeds. Another thing to consider for a converted repository is that mass converters tend to either not make a pack at all or make a pack that is horribly inefficient to access. Running "git repack -a -d -f" with a small value of "--depth" may be a thing worth trying, if that is contributing to the performance. -- 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