Q:

Getting useful git diff output between branches after a file has been renamed

I'm trying to diff a file in another branch, that was renamed.  I've renamed the file back to its original name, using
git mv renamed.file original.file
git add -u original.file
git commit 

this looks right in the tree, i.e. it keeps the history. 
however, when I do a git diff between the file in two branches I am simply getting all of file a and all of file b - not a very useful diff output. 
is there a way of getting a more fine-grained diff in this case?  
I have tried: git diff -C, git diff -M, git diff --follow -M and -M with different percentages e.g. -M10% - in each case I get the same output
EDIT - Extra info that would have helped to solve the issue quicker: 
The file was renamed and edited on Windows and I am on OSX. ( different line endings). 

A:

Instead of trying to convince git that a rename happend, you could just "force" it to compare the two files. 
I'll assume that you renamed the file in your last commit. 
To address a file directly - even if this file only exists in a different branch/commit - you can use the <reference>:<path> syntax.  Taking advantage of this syntax a diff command could look like this:
git diff HEAD^:renamed.file original.file

Using this command you can compare the renamed.file from the previous commit (HEAD^) with the original.file of your current working tree. 

You can take a look at the git rev-parse documentation for details on the <reference>:<path> syntax. 

Still no success? 
If you are still recieving the same output it's possible that you have whitespace changes which let git consider the lines as changed. 
In such a case you can pass git diff further options to ignore whitespace changes:

--ignore-space-change or just -b will ignore all whitespace changes; alternativly you can use
--ignore-space-at-eol which will, as the name implies, only ignore whitespace changes at the end of the line

Take a look at the git diff documentation for further details.