2

If I do

git difftool -y --find-renames master

I get diffs of any file with the original version on the branch, so if I've renamed 'a' to 'b' and changed it, I get the differences between the current 'b' and the original 'a'. But if, instead, I do

git difftool -y --find-renames master b

it gets compared with /dev/null. This is quite confusing.

Is there any way to get git diff to do what I expect?

Tom Tanner
  • 9,244
  • 3
  • 33
  • 61
  • possible duplicate of [git diff renamed file](http://stackoverflow.com/questions/7759193/git-diff-renamed-file) – John Szakmeister Dec 26 '13 at 11:40
  • no, because in that question and answer it's assumed you know the file is renamed and from what. That's not always the case. – Tom Tanner Jan 01 '14 at 10:26
  • Did you read the answer? I believe it does answer your question. The short form: no. When you specify a path, you need to specify both (the original and the new path) or you're out of luck. – John Szakmeister Jan 01 '14 at 10:50
  • Yes I did and no it doesn't - it explains how to do what I want if you know what you want. it's not so helpful if you don't know what you want. I did check that question before i posted this one – Tom Tanner Jan 01 '14 at 11:17

1 Answers1

2

You can always be explicit about your comparison,

$ git diff master:a b

The -M (find-renames) and the -C are heuristics, and in your case you know that it was a that was explicitly renamed to b.

If a and b are not known in advance you can leverage your first command to get a list of suggestions first, followed by an excursion into the file histories:

$ git diff --find-renames --name-only master

invoking log --follow on every suspected rename:

$ git log --follow <renamed file>
mockinterface
  • 14,452
  • 5
  • 28
  • 49
  • I don't always know that. I happen to know in the example given, obviously. But it's not always the case - especially if someone else has renamed the file in another commit. – Tom Tanner Dec 26 '13 at 12:27