git-blame

This question already has answers here : Git blame — prior commits? (13 answers) Closed 7 days ago . I use git blame command to see in which commit have been added some particular code line, but sometimes I bump into the same problem: someone has made some kind of code formatting, or has changed function interface and refreshed all client code. Eventually git blame show me only this last commit on particular code line. How ignore this commit and see what happened before it? Of course I can checkout on commit before format-edited commit and see blame again, but it may take a lot of time on huge

I am using IntelliJ's annotate feature to see in the editor who last changed a line in a file. Now I am using JGit to read the same annotations and they differ. For me it seems that Intellij checks that a line has not been changed between commits and still uses the old commit message. JGit does not see it and so makes an other message. Can anybody confirm that the behavior of JGit blame and IntelliJ differs? Whats the reason and how can I force IntelliJ to behave the same like JGit? Maybe IntelliJ ignores whitespace changes? I am using IntelliJ 15.0.1 and JGit 4.1.1 IntelliJ IDEA does not have

I've been using Fugitive's Gblame recently but don't quite understand what "reblame" does. Can someone describe a little more clearly what these options do: - reblame at commit ~ reblame at [count]th first grandparent P reblame at [count]th parent (like HEAD^[count]) Think of reblame as navigating to a commit and then running blame on your file or git blame <commit> -- <file> - the simplest case. Use the commit in question under your cursor and reblame the file. ~ Is equivalent to running git blame <rev>~[count] -- <file> P Is equivalent to running git blame <rev>^[count] -- <file> For the

When I run git blame on a file in a folder e,g,: git blame Foo/FileA.txt it returns fatal: no such path 'Foo/FileA.txt' in HEAD I can clearly see that this file exists on the file system, and other files in the same folder can be successfully blamed - so what is going on? I'm posting this question and answer as it had me stumped for a while today, and I couldn't find a single answer that hit all of the solution. This is due to renaming a parent folder on the file system with a new name that varies only by case - and some files were added in a commit occurring before the rename of the folder.

Understanding the Git Workflow article says, So you add a new rule: “When you merge in your feature branch, use –no-ff to force a new commit.” This gets the job done, and you move on. Then one day you discover a critical bug in production, and you need to track down when it was introduced. You run bisect but keep landing on checkpoint commits. You give up and investigate by hand. You narrow the bug to a single file. You run blame to see how it changed in the last 48 hours. You know it’s impossible, but blame reports the file hasn’t been touched in weeks. It turns out blame reports changes for

I've used a perl script to modify all tab characters in a php git repository and changed them all to 4 spaces. $ find -iname \*.php -exec perl -pi -e "s/\t/ /g" {} \ I can commit this change with git commit , but it will mark me as the author of all changed lines inside git blame after this commit is made. Is there any way to commit this massive change that doesn't mark me as the author of the changed lines, but retains the original author? That's a lot of history we don't really want to lose in our project. Our purpose in replacing tabs with 4 spaces is not to make things appear different in