It'll work until the next big rewrite of that component :).
I love it when people put this level of detail into their commit messages, but this technique has one weak spot I don't know what to do about: if someone makes a change that confuses git's semantic heuristics - rename a function, split a file into two, etc. (or maybe all of them in a single commit), it creates a boundary for blame/log-trace that's hard to bridge.
But then, maybe I'm just not clever enough with git log -L ...
Hopefully whoever is git blaming understands enough about git to hop past any intermediate changes back to the source
I've never done any kernel development, but with commercial code it's pretty common to have to dig backwards including going back to the issue tracker or even searching through company chat (Slack, email, etc) if the shop doesn't do [a good job with] documentation
The --follow, -M, and -C options have usually helped me out of most blame dead ends, but sometimes I do still have to look up each blamed commit manually to keep following history.
I love it when people put this level of detail into their commit messages, but this technique has one weak spot I don't know what to do about: if someone makes a change that confuses git's semantic heuristics - rename a function, split a file into two, etc. (or maybe all of them in a single commit), it creates a boundary for blame/log-trace that's hard to bridge.
But then, maybe I'm just not clever enough with git log -L ...