Jeff King <peff@xxxxxxxx> writes: > If you have before-and-after numbers for just this patch on some > repository, that would be an interesting thing to put in the commit > message. It's a hen-and-egg problem regarding the benchmarks. The most impressive benchmarks arise with the git-blame performance work in place, and the most impressive benchmarks for the git-blame performance work are when this or something similar is in place. Of course, when there are two really deficient things slowing operations down, fixing only one is going to be much less impressive. So I decided to tackle the low-hanging fruit here first. But it would appear that this amounts in far too much work since it means I have to search for and create some _other_ benchmarking scenario not hampered by substandard code like the current git-blame is. I have enough on my plate as it is, so even though it puts the _real_ git-blame work in a worse light, I should rather get that finished first (nobody will argue to keep the useless threshing of it around). Of course, the person then creating the two-line change to deltaBaseCacheLimit will be able to claim much larger performance improvements in his commit message afterwards than what I can claim regarding the git-blame work when going first, but that's life. -- David Kastrup -- 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