GitX doesn't quite honor diff.renames

[RomainMuller]

I have recently walked into a use case where it made my life so much easier to have my diffs track renames in order for me to actually see the content change, rather than having it buried in the <delete,add> pair.

Hence I have git config --global diff.renames true in order to get basic renames detection in the "git show" and alike, which does the job just great.

However, it appears that GitX is still showing a full blown <delete,add> diff, so I would suppose the git command thrown in the background to read the diff prevents git from doing rename detection... It would be nice if that could be fixed (so it conforms to the standard git behavior).

[laullon]

Can you create a sample repo?

[RomainMuller]

I'll do at some point tomorrow :)

[dak180]

dak180/oxidizer@15997becc might be a good real world example of this.

[RomainMuller]

It turns out the reason it was not working was because -C90% -M90% was passed to diff-tree, and my files were more than 10% different after the move (since I did also do some edits in there, for probably 10-20% of the lines, but only a few bytes per line).

Commit 9fb475b gets it to the "default" behavior of Git, but got me wondering whether we should make these -C and -M values preferences? So they'd default to default (that is nothing after the C and M), but user can set them to N% if they prefer it so.

BTW, if you still want a test repo, I can still forge one. (That is in case the suggested real-life example from @dak180 doesn't do :D)