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? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html