Thread (2 messages) flat view 2 messages, 2 authors, 2016-06-15

Re: Detection of relocations within a file

From: Jakub Narebski <hidden>
Date: 2016-06-15 22:49:25

On Mon, 30 Aug 2010, Tim Mazid wrote:
Matthieu Moy wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help