I heartily recommend using `tig blame` from <a href="https://jonas.github.io/tig/" rel="nofollow">https://jonas.github.io/tig/</a> -- it allows you to interactively navigate the blame history; navigate to the line of interest, press one key to see details of the commit that last touched it. Not the right one? Press `,` to move to before that commit. Moving past bulk changes and finding the actual origin of a line of code is usually a breeze with this tool.<p>I don't use tig much otherwise, but for this purpose I've not yet seen a better (and faster!) tool.
This is a dangerous feature for git repository hosts like GitHub to support. It makes it all too easy for subtle vulnerabilities to be introduced and omitted from visible blame history, with reviewers presuming trust based on historic content. Example: codebase went through an audit, was approved, then someone sneaks in some subtle changes to some files under the guise of a bulk change, adds the commit to the ignore list, continues making more commits to other files. Pulling a report to see historic changes could result in the file made vulnerable being skipped because it appeared to occur before the last audit. Hard pass.
The one feature of perforce (which my current employer uses) that I miss going back to git is the "time lapse" view. It's like git blame but you also have a slider that can scroll through the revisions to a file. This is sorta similar to that, but I still think p4's version is still a better UX.
What I do, is I run loop like<p>(1) git blame <file>
(2) git blame <uninterestinghash>^ <file><p>which tells blame to go back to before the hash and do the blame.<p>I run that loop repeatedly, picking the most recent hash each time (by date/time), until I get back to the change that interests me.
Also discussed here a few days ago:<p><a href="https://news.ycombinator.com/item?id=27643608" rel="nofollow">https://news.ycombinator.com/item?id=27643608</a>
current $job has been switching to prettier & among many other changes we've been doing the (one true wayl tabs to (ignoble cowardly top-down-force) spaces.<p>I added generating a .gitignorerevs file during these conversion to our process document. what sucks egg though is that there's no standard for what to name these files. there's no out of box support. there was a confusing nasty mess of a thread for how to modify vscode's ultra-popular git lens plugin to add a git ignore revs file but 70% of the advertised "works for me" threads were wrong. in multiple ways often. we never found how to open the gui screenshots folks were showing to modify blame arguments; we had to resort to json modification which scared the crap out of some weakling junior devs with shitty constitution. the use of ${workingDir} or whatever in the config never worked, as other people latter pointed out. it wasn't clear what we needed in the json. it was a bloody nightmare. just for the very first medium grade engineer I tried getting this working with.<p>holy shit I wish git would normalize a --ignore-revs-file so bad.<p>to those wringing pearls about how this is a vector for people to sneak changes in: tool up. build safeguards. holy shit the complaining & fear & uncertainty & doubt over basic stuff, as if we can't see these changes happening, as if everyone is a hapless idiot who can't notice... I fear the society of losers your attitude suggests. just get better. write tools to notice these changes. which you would already, if you look at your git pulls. I do.
A friend of mine recently been mentioning that it is possible to hide bulk changes when introducing a linter to a repository. This is how! Thought it's very useful and not well known.
If you're interested in who added, modified or deleted a line you could also use the git pickaxe.<p>> git log -S"Hello World"<p>shows you all commits that either introduced, or deleted 'Hello World'.
This looks like a worthwile change, helping in specific situations, when used sparsely.<p>Personally I see bulk changes as something that is legitimate change and should appear in the blame history, the same way refactorings are supposed to be functionnaly equivalent but we all know it’s not that easy and need to keep an eye on when they were done.<p>Having massive commits clutter history also looks like a good incentive to avoid massive commits in the first place.
Or you can just run git blameall and see the complete history at once. <a href="http://1dan.org/git-blameall/" rel="nofollow">http://1dan.org/git-blameall/</a> still have no idea why this is not more popular / core.
I’m glad this tooling is improving, but it’s better not to need it. If a trusted contributor has a good reason to rewrite a bunch of code, that is the appropriate time to reformat it; the best bots don’t compare to anyone on my team.
Having a look around, this seems a bit unsupported by the common git tools (github, gitlab, ado etc), but otherwise incredibly useful, going to push this into a repo we recently hammered with a `prettier` format!