Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: ... > is virtually useless because it's too expensive, but try doing > > git gui blame gcc ChangeLog > > instead, and doesn't that just seem nicer? (*) > > The difference is that the GUI one does it incrementally, and doesn't have > to get _all_ the results before it can start reporting blame. > > Not that I claim that the gui blame is perfect either (I dunno why it > delays the nice coloring so long ... git-gui waits to color until after it gets the move/copy annotations back from the -C -C -w second pass it does. This way the coloring is based on the original source location, not on the move/copy that caused it to be placed where it is now. I played around with this for a while and finally made it work the way it does as I assumed most users would want to see where something originally came from more than how it got moved to where it is now. IOW the (very expensive) -C -C -w pass is usually much more interesting than the default (fast) pass, so that is the line annotation data we color with. But it takes longer to get and is run second, so yea, coloring takes a while. -- Shawn. - 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
