[andrewray]

It's been my experience, especially in the startup scene where business requirements change often, that `git blame` rarely shows you what you want. Files get renamed, moved, re-indented, etc, frequently.

I wrote a tutorial on a more effective (at least for me) solution to find the true author of a change: http://blog.andrewray.me/a-better-git-blame/

[versteegen]

Nice tutorial, but aren't you aware that "git blame -w" ignores whitespace changes? git blame also always follows renames. git's rename detection isn't foolproof (if I edit and rename A.cpp to A-star.cpp at the same time as adding a new A.cpp file it won't detect it), however there are two more blame options for that: -C to follow lines copied between files, and -M to follow lines moved within a file.

Unfortunately, adding -M and -C will quite badly increases the time to compute the blame. Both take an adjustable parameter (min number of characters to match), but I found I actually had to reduce it to catch all the lines in an example of the A.cpp -> A-star.cpp move I did yesterday.

[sadgit]

I would love to be able to use left and right to skip quickly through revisions when viewing a blame, do you know anything for that?

[versteegen]

That's something I've wanted for a long time too.

tig (a curses-based git interface) fits the bill, though it can be quite confusing (too many keybindings). "tig blame -w <file>" to view a blame (-w to ignore whitespace), and then you can press , on a line to recompute the blame using the parent of that commit, while moving to the ancestor of that line (but tracking the line frequently doesn't work). And < to go back to the previous commit.

I remember that tortoisesvn was fairly nice for viewing blames, IIRC you can move through history inside it with some clicking around, and the tortoisegit interface appears to be largely the same: https://tortoisegit.org/docs/tortoisegit/tgit-dug-blame.html Windows only however.

[chx]

I found http://1dan.org/git-blameall/ an incredibly useful tool for similar (not identical) purposes.

[cyphar]

> It's been my experience, especially in the startup scene where business requirements change often, that `git blame` rarely shows you what you want. Files get renamed, moved, re-indented, etc, frequently.

Blame follows renames in most cases (unless you're doing something like creating a new file with the same name as the renamed one in the same commit), and you can use the -w flag to ignore whitespace changes.