Re: Detection of relocations within a file

From: Jakub Narebski <jnareb@gmail.com>
Date: Aug 31, 2010, 01:43 UTC
Message-ID: <201008310343.05280.jnareb@gmail.com>
In-Reply-To: <SNT124-W40BFB8E681711F9CD33D9AC4890@phx.gbl>

On Mon, 30 Aug 2010, Tim Mazid wrote:

> Matthieu Moy wrote:

Show 23 quoted lines

> > 2. I am mystified not by some particular piece of code but by an
> > entire file.  The command
> > $ git gui blame -- git.c
> > works okay.
> 
> It does, to an extent.
> 
> The specific case I was thinking of is when, as a function grows
> larger, you decide to break it down and move a section of it to a new
> function.  Now, if the two lines remain exactly the same, there is no
> problem and git gui blame does the job.
>
> However, if there is any change in the line at all, even leading
> whitespace, as moving code around usually changes its "tabbage", then
> "git gui blame" will not detect that as being the same line of code
> sitting somewhere else, as it sees the two as "different".   
> Is there any way to get around this?
> 
> Further, in the previous point regarding a movement patch, it too
> should not be overly sensitive to leading whitespace. 
> 
> Actually, git in general shouldn't be too sensitive to leading
> whitespace (or at least should have an option to turn this on/off).

You can always pass `-w' option to git-blame:

  -w   Ignore whitespace when comparing the parent's version and the
       child's to find where the lines came from.

I'm not sure if you can pass other diff whitespace options to git-blame (-b, -w, --ignore-space-at-eol).

Note that "git gui blame" shows *two* blames: ordinary and '-C -C -w', i.e. with copy detection and ignoring whitespace changes.

-- 
Jakub Narebski
Poland