Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > Actually, the code to finding one '\n' is still needed to avoid the > (pathological) case of getting a "\No newline", so scrap that one which > was too aggressive, and use this (simpler) one instead. > > Not that it matters in real life, since nobody uses -U0, and "git blame" > won't care. But let's get it right anyway ;) Actually "blame won't care" is a bit too strong. It's only we (you) made it not to care. It is a different story if the change to make it not to care was sensible. The diff text "git blame" will see is affected with the tail trimming optimization exactly the same way as the optimization triggered this thread. With the common tails trimmed, the hunks match differently from the way they match without trimming (the gcc changelog testcase has differences between the unoptimized blame and the tail-trimming one --- your original to put this logic only in blame and my rewrite to move it in xdiff-interface produce the same result that is different from the unoptimized version, although both are 4x faster than the original). When there are multiple possible matches, any match among them is a correct match, and a match with a line in a blob is a match to the blob no matter what line the match is anyway. The usual workflow of checking blame to find the commit that introduced the change and then going to "git show" to view the bigger picture won't get affected. But the blamed line numbers will be different from the unoptimized blame, and it may not match the expectation of human readers. It won't match "git show" output of the blamed commit. > This whole function has had more bugs than it has lines. I have to agree. It started as a brilliant idea but then it was enhanced (in an attempt to support context) and executed not so brilliantly. - 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
