Geek Answers Handbook

If GIT does not track file renaming, how can we not lose these changes in merges?

In our application, we often need to rename the file / package to the release branches, and then merge this change (along with many others) into the trunk. The big problem is that many SCM solutions (our current SVN) do not track file renaming. When we move to merging the release branch of our product back into the trunk, it becomes easy to lose these changes, since SCM is not intelligent enough to know that MyOriginalFileName and MyRenamedFileName are the same files / classes, etc.

It seems to me that we can do something wrong, what will be the GIT way to handle this?

+4
source share
4 answers

I believe that Git can track this.

As an example, I created a test Git repository. I added one file to it called test.txt and committed it.

Then I renamed this file and made 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%)

I suggest using git-svn to create a Git repository from your svn repository. Then you can play with him and see if he suits your needs.

+6
source

I am not familiar with SVN, so I'm not sure if you have a problem, but Git seems to handle renaming well.

After renaming, you must make sure that you have added the file to the Git index, otherwise it will think that you simply deleted the old file and not renamed it.

If you rename the file and make a couple of changes; you may also have renamed one of the #include files. When you commit, you will receive a message like:

 rename: MyOriginalFilename -> MyRenamedFileName (99%)

A percentage means that the source file is similar to the new one, so it does not even have to be an exact copy of the contents of this file.

+4
source

Git does not use renaming tracking , but uses heuristic affinity based on renaming . This means that Git compares / checks the changed files and decides on renaming and which files should match with them when merging is resolved. This actually works well.

Note that due to the renaming algorithm, if you use too simple a test case, it may not work; but on real mergers, it should work well.

+4
source

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

Of course, this only works when the moved pieces are large and unique, but especially when renaming entire files it works like a charm.

+3
source

More articles:


All Articles