Isn't this sort of an inconsequential point? The commit still has one and only one author and that's almost certainly what I'm looking for so I know who to go ask questions about their code. I also use it to find the commit but less frequently.
And the committer and author don’t even need to be the same!
But the point, as I read it, is: what matters is the context, i.e. if a line is faulty, how did things look like when it wasn’t faulty? The commit’s content is more often more important than the committer, although the committer is useful because you can ask them if they’re still around.
Linking a line of code back to the commit is useful even if you can't ask the author about it. It tells you what other lines of code are involved and what the overall purpose is. It's significantly more useful if you can link it into documentation outside the code: ticketing systems, requirements docs, etc.
The main limit to svn blame in that situation was that quite often it would hit commit 1, when the codebase had been imported from Visual SourceSafe.
I really want to find or build a tool that can automatically traverse history this way, like git-evolve-log.
(Work hardening is a metalworking term where metal bent back and forth (or hammered) too much becomes brittle; an analogous effect shows up in code, where a piece of code that has been bugfixed a couple of times will probably be need more fixes; there was a published result a decade or so back about using this to focus QA efforts...)
Example output based on Linux kernel @ "Cregit-Linux: how code gets into the kernel": https://cregit.linuxsources.org/
I learned of Cregit recently--just submitted it to HN after seeing multiple recent HN comments discussing issues related to line-based "blame" annotation granularity:
"Cregit-Linux: how code gets into the kernel": https://news.ycombinator.com/item?id=43451654