RE: Detection of relocations within a file

Hi guys,

quoted

I was just wondering if git can/does detect relocations of sections of code/text within a file.

For example, moving a function from the top of a file to the end.

Depends what you are trying to do.
...
4. I want a simple, easy-to-review patch representing a code movement.
No one I know of has worked on this, and if you have ideas for it,
that would be very neat.

5. I have a history with a lot of code movement, someone branched from
me a while ago, modified various pieces of code which moved in the
meantime, and we want to merge.

Unfortunately, I don't think any VCS does a really good job here
either.

Yeah, go figure, the ones I'm after are the one that don't exist. :P

As for ideas, all I can really think of is that git detects that the '-' lines and the '+' lines are actually the same thing, and so instead of actually showing the changes as deletions and insertions, actually shows the change in the context surrounding the lines.

This should also be able to be mixed in with insertion and deletion lines.
For example, if you move a chunk of code, and then stick a comment (or code) line in the middle, or, conversely delete one, it should still see it as a movement patch, with an insertion or deletion.

I *think* that this *might* also work to "solve" or at least help with point 5, made by Matthieu (sorry if I misspelt your name).

However, as I haven't delved into the insides of git, I don't know how this would be represented internally, how it would differ from a normal patch, or exactly how horribly painful it would be to implement.

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).


Well, yeah, that's my ramblings, what do you guys think?
 		 	   		  

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