git: change styling (whitespace) without changing ownership/blame?

11,396

Solution 1

In an ideal world there would be some way to rewrite history to look like the violations were never introduced

git filter-branch does precisely that.

http://git-scm.com/docs/git-filter-branch

This has the same issues as all history rewriting commands do, as it essentially invalidates all cloned repositories.

Solution 2

If you are trying to get a Root Cause issue using blame, don't forget use the -w flag to ignore all the white-spaces or indentation changes. So you'll get the last real change to the code, instead just an indentation, or removing trailing spaces.

git blame -w app/to/file.rb

or you can just use, git slap command..

git config alias.slap "blame -w";
git slap app/path/to/file.rb

having same results :D

Solution 3

Building on Mario's answer, I would suggest git shame as a global git-alias:

git config --global alias.shame 'blame -w -M'

...and use it instead of git-blame:

git shame path/to/file

To explain:

  • -w Ignores whitespace changes, so not to blame someone who re-indented the code
  • -M Detects lines that were moved or copied, and blames the original author

EDIT:

Some argue that the -M is misleading, blaming the wrong person
(i.e.: don't blame me if someone rearranged what I wrote).
If you feel the same, please use the original suggestion: git slap

Solution 4

I did a pull request to the TextMate git Bundle, to set this "-w" parameter by default for the "Browse Annoted File (Blame)" command. Thanks Mario Zaizar, you made my day.

diff --git a/Support/lib/git.rb b/Support/lib/git.rb
index 5e8de13..5192953 100644
--- a/Support/lib/git.rb
+++ b/Support/lib/git.rb
@@ -307,6 +307,9 @@ module SCM
       file = make_local_path(file_path)
       args = [file]
       args << revision unless revision.nil? || revision.empty?
+      # Ignore whitespace when comparing the parent's version and
+      # the child's to find where the lines came from.
+      args << '-w'
       output = command("annotate", *args)
       if output.match(/^fatal:/)
         puts output 
Share:
11,396

Related videos on Youtube

Jay Paroline
Author by

Jay Paroline

VP of Engineering at BetterHelp, former Grooveshark VP.

Updated on September 19, 2021

Comments

  • Jay Paroline
    Jay Paroline almost 3 years

    We have a massive, ancient codebase that needs a lot of cleanup. We have always had coding standards and everyone has always tried to follow them, but they were not enforced so over time a lot of violations have creeped in. Many of them are just whitespace issues, like using tabs instead of spaces, or spaces where there shouldn't be any, or missing spaces where they should be. We are going to start actively enforcing our coding standards to make sure more violations don't creep in, but it's difficult to enforce them in an automated way on only the changes, so it would be nice to clean up these old files.

    There are tools that can automate fixing these issues, however if I do that then blame is going to show me as the owner of those lines, when in reality I may never have even seen them. I know there is a setting to make blame ignore whitespace changes, but I can't make everyone use blame the same way, including other visual tools and things like gitstats. In an ideal world there would be some way to rewrite history to look like the violations were never introduced, without covering up who introduced the actual code, but I can't find anything like that.

    • Cascabel
      Cascabel over 13 years
      Rewriting history is a bit awkward - once you change the commits, others are going to have to pick up those changes. Not part of an ideal workflow. You might want to look into enforcing your coding standards using hooks. You can use an update hook to do the final enforcement when pushing to a central repo, and you can give developers a pre-commit hook to do the same validation for them, and even automatically fix things if it's safe to do so. (If you want to fix what's already there, I'd just do it in a single commit - no need to go through the headache of rewriting the entire history.)
    • CB Bailey
      CB Bailey over 13 years
    • Jay Paroline
      Jay Paroline over 13 years
      I don't think this is exactly a duplicate of that question. In my question I specifically stated that changing the flags on blame is not adequate, and the accepted answer to that question is exactly that.
  • Jay Paroline
    Jay Paroline over 13 years
    Thanks, looking into this now!
  • Jay Paroline
    Jay Paroline over 13 years
    Got it working! git filter-branch --tree-filter 'git diff-tree --name-only --diff-filter=AM -r --no-commit-id $GIT_COMMIT | php cleanup.php' HEAD
  • Cybot
    Cybot about 11 years
    how does your cleanup.php look like?
  • blinry
    blinry almost 10 years
    @ErikAllik I'm not sure what you mean, but one line before git slap is used, it's defined as an alias for git blame -w.
  • Joseph Casey
    Joseph Casey over 7 years
    One of the downsides to the -w whitespace argument is that it does take into account refactoring the order of methods, removal of loose comments, and so many more things.
  • Timmmm
    Timmmm over 7 years
    What if my whitespace cleanup can't be done by a script? (E.g. space indentation is used inconsistently.)