If GIT doesn't track file renames how do we keep from losing these changes in merges?

Question

In our application we often need to rename a file/package on a release branch and then merge this change (along with many others) to the trunk. A big problem is that many SCM solutions (our current is SVN) do not track file renames. When we go to merge a release branch of our product back to the trunk it becomes easy to lose these changes as the SCM is not intellijent enough to know that MyOriginalFileName and MyRenamedFileName are the same file/class/etc.

It seems to me that we might be doing something wrong, what would be the GIT way of handling this?

Answer 1

I believe Git can track this.

As an example I created an test git repository, I added one file named test.txt in it and committed it.

I then renamed that file and committed my changes.

Here is the git log from my commit:

[master cf5c827] test
1 files changed, 0 insertions(+), 0 deletions(-)
rename test.txt => test_renamed.txt (100%)

What I suggest is to use git-svn to create a git repository from your svn repository. Then you can play with it and see if it fulfill your needs

Answer 2

Git does not use rename tracking, but it does use heuristic similarity based rename detection. It means that Git compares / checks changed files and decides about renames, and which files should match which during resolving a merge. It works quite well, actually.

Note that because of algorithm of rename detection if you use too simple test case it could not work; but on real merges it should work well.