Using Git diff to detect code movement + How to use diff options

Question

Consider that a file (1.c) contains three functions and changes made by authors M and J. If someone runs git blame 1.c, he will get the following output:

<

Answer 1

As of Git 2.15, git diff now supports detection of moved lines with the --color-moved option. It even detects moves between files.

It works, obviously, for colorized terminal output. As far as I can tell, there is no option to indicate moves in plain text patch format, but that makes sense.

For default behavior, try

git diff --color-moved

The command also takes options, which currently are no, default, plain, zebra and dimmed_zebra (Use git help diff to get the latest options and their descriptions). For example:

git diff --color-moved=zebra

Answer 2

This was the best answer at the time it was written, but it is no longer accurate. In 2017, Git 2.15 upgraded its diff to do move detection. As explained in the now top voted answer, use git diff --color-moved

Original answer:

What you're running up against here is that Git largely stays out of advanced diffing like this. There's a reason Git allows configuration of external diff and merge tools: you'd go insane without their assistance. Beyond Compare and Araxis Merge would both catch this movement, as an example.

The general class of problem you're looking to solve is a "structured merge": Structural Diff of two java source files

You might have a bit more luck with git-format-patch than with git-diff in this case because the former provides more commit info, including author and commit message and also generates a patch file for each commit in the range you specify. Source: What is the difference between 'git format-patch and 'git diff'?

If you're looking for tips on detecting code moves generally, it's interesting to note that detection of code movement is explicitly not a goal of the all-powerful pickaxe. See this interesting exchange: http://gitster.livejournal.com/35628.html

If you wanted to detect who swapped the order, it seems your only option would be to do something like:

 git log -S'public int multiplication(int y, int z){
    int result = y*z;
    return temp;
 }

 public void main(){
    //this is a comment
 }
 public int add(int x, int y)  {
    int z = x+y;
    return z;
 }'

What you're looking for is git blame -M<num> -n, which does something pretty similar to what you're asking:

-M|<num>|
       Detect moved or copied lines within a file. When a commit moves or
       copies a block of lines (e.g. the original file has A and then B,
       and the commit changes it to B and then A), the traditional blame
       algorithm notices only half of the movement and typically blames
       the lines that were moved up (i.e. B) to the parent and assigns
       blame to the lines that were moved down (i.e. A) to the child
       commit. With this option, both groups of lines are blamed on the
       parent by running extra passes of inspection.

       <num> is optional but it is the lower bound on the number of
       alphanumeric characters that git must detect as moving/copying
       within a file for it to associate those lines with the parent
       commit. The default value is 20.

-n, --show-number
       Show the line number in the original commit (Default: off).

Answer 3

In this particular case, I don't think git diff is concerned about detecting code movement; rather, it's simply creating a patch that can be applied to transform the old file into the new file, which is what your git diff output plainly shows - the function is being deleted from one location and inserted in another. There are probably more succinct ways to output a series of edit commands that move code from one location to another, but I think git might be erring on the side of portability here - there's no guarantee the end user wound always use git apply or git am, so the patch is produced in a format that can be used even with plain patch.