Git Rename

Question

My friend and I are working separately on the project. First, I clicked on a folder called old-name , and he pulled it out. In the middle of this, I decided to rename the old-name folder to new-name in order to better distinguish it from other projects (just say, old-name is too general, and new-name more specific). So I told my friend to rename my project folder to new-name too. And then we work separately.

Now he pushed what he did to the remote server (in the new-name folder), when I try to pull it from the server, all these conflicts (renaming / adding) occur and, apparently, there is one additional copy of each individual file in the new-name project new-name .

 new-name/index.php (MINE) new-name/index.php~98789491981agsagasga98a914a98wt (his commit ID I believe) 

My question is, how can we solve this without this problem of renaming git conflicts? Of course, I can resolve the conflict manually, but there are too many files to check and delete due to this new extra copy that git pulled to my repo.

thanks

Answer 1

Just add all your files. Everything that is a simple renaming will be identified as being indistinguishable and removed from the index. Therefore, even if the git status shows loads and a lot of problems, there is not much left after "git add -A" (and everything else will have real differences). You should immediately check the new branch (before "git add -A") so that you can easily track if it goes south.

Answer 2

Just a guess, but it seems to me that Git rename detection did not detect renames when merging. A lot of files in this directory? Have the files been changed much?

Try reusing merge / merge.renameLimit after increasing the value of the configuration options merge.renameLimit or diff.renameLimit . From git help config :

 diff.renameLimit The number of files to consider when performing the copy/rename detection; equivalent to the git diff option -l. merge.renameLimit The number of files to consider when performing rename detection during a merge; if not specified, defaults to the value of diff.renameLimit. 

You can also try -Xrename-threshold=70 to lower the rename affinity detection threshold. From git help merge (also in git help pull ):

 rename-threshold=<n> Controls the similarity threshold used for rename detection. See also git-diff(1) -M. 

From git help diff :

 -M[<n>], --find-renames[=<n>] Detect renames. If n is specified, it is a threshold on the similarity index (ie amount of addition/deletions compared to the file's size). For example, -M90% means git should consider a delete/add pair to be a rename if more than 90% of the file hasn't changed. 

Note that I'm not sure what will happen when line endings are converted between Unix style and Windows style. Git might think that files are 100% different, even if the only difference is line endings, so make sure you both use the same line endings.

Answer 3

You should put the new working copy in a new local folder, next to the code that you worked on first. Then, using the Diff style tool to compare and combine your work with the new local copy. Then commit the changes to the new pull and bam, you have a change. I know that this does not save your entire change log in what you did, but if you do it manually, this is not an option, this is the next best thing.