views:

362

answers:

4

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?

+5  A: 

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

Aurélien Bottazzini
+3  A: 

I'm not familiar with SVN, so I'm not sure what the problem you're having is, but Git seems to do a good job with renames.

After doing a rename, you have to make sure you re add the file to the git index, otherwise it'll think you just deleted the old file instead of renaming it.

If you rename a file and make a couple changes; maybe you renamed one of the #include files too. When you commit, you'll get a message like:

rename: MyOriginalFilename -> MyRenamedFileName (99%)

The percentage means how similar to the original file the new one is, so it doesn't even have to be an exact copy of the contents of that file.

jonescb
+2  A: 

Git actually doesn't track the file as a file but tracks the contents inside a tree structure. The difference there is that even when moving chunks from one file to another git will automatically recognize this and apply merges accordingly - no need for manual interaction.

Of course this does only work when the moved chunks are big and unique enough but especially when renaming whole files this works like a charm.

johannes
+1  A: 

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.

Jakub Narębski