Detection of relocations within a file

Detection of relocations within a file

[Tim Mazid]

Hi git-list,

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.

If git does not currently do this, would it be a good/bad idea, and how hard would it be to implement?

Regards,
Tim.
 		 	   		  

Re: Detection of relocations within a file

[Jonathan Nieder]

Hi Tim,

Tim Mazid wrote:

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

1. I am mystified by some piece of code, and I want to know where
it originated.  Code movements is uninteresting to me (so grepping
through a patch won't do it).  The command

 $ git log -S'const char git_more_info_string[] =
	"See 'git help COMMAND' for more information on a specific command.";' \
      -- git.c

tells the originating commit pretty quickly.

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.

3. The origins of some piece of code make enough sense, but the code
changes since then are a mystery to investigate.  The command

 $ git log -L '/int main(/,/}/' git.c

with git from the "next" branch can help.

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.

Re: Detection of relocations within a file

[Matthieu Moy]

Jonathan Nieder <jrnieder@gmail.com> writes:

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

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

RE: Detection of relocations within a file

[Tim Mazid]

Hi guys,

>> 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?
 		 	   		  

Re: Detection of relocations within a file

[Jakub Narebski]

On Mon, 30 Aug 2010, Tim Mazid wrote:
> Matthieu Moy wrote:

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