[gwbas1c]

BTW, one of the more frustrating things about "git blame" comes about when cleaning up an old codebase: In my current job I had to move a lot of files, combine repos, reformat code, ect, ect.

"git blame" and similar tools often always show my name, even though I didn't write the code.

[alisonatwork]

Most places I worked have a blame.ignoreRevsFile[0] somewhere on the top level to inhibit this. It's a bit awkward because first you need to commit, then you need commit again to update the commit hash in the ignore revs file, but it's great for filtering out pure refactor churn.

[0] https://git-scm.com/docs/git-blame#Documentation/git-blame.t...

[follower]

"Cregit" tool might be of interest to you, it generates token-based (rather than line-based) git "blame" annotation views: https://github.com/cregit/cregit

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

Of course, in your situation I guess such a tool would only help if other people use it. :D

[graemep]

I was thinking that I would really like a tool that shows the history of bad code, and who actually wrote it and amended it, not just who last changed it.

Particularly so if I can see that someone wrote bad code, so I can review the rest of their code.

[Izkata]

git log/blame have -C and -M to follow modified lines across files. Unlike other version control, you don't have to have used a special command to rename files, because it doesn't track files that way in the first place. The maximum -C can even look for sources in other commits.