Git Renaming Issues

Question

A friend and I are working seperately on a project. At first, I pushed a folder named old-name and he pulled from it. In the middle of it, I decided to rename the old-name folder to new-name to better distinguish it from other projects (let's just say old-name is too generic and new-name is more specific). So I told my friend to rename his project folder to new-name too. And then we're working seperately.

Now, he's pushed what he's done to the remote server (under new-name folder), when I try to pull from the server, all these conflicts (rename/add) occur and apparently there's one extra copy of every single file in the new-name project now.

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 git conflict renaming issue? Of course I can resolve the conflict manually, but there's just too many files to check and delete because of this new extra copy that git has pulled to my repo.

Thanks

Answer 1

Just a guess, but it sounds to me like Git's rename detection didn't detect the renames when merging. Are there a lot of files in this directory? Were all of the files heavily modified?

Try redoing the merge/pull after increasing the value of the merge.renameLimit or diff.renameLimit config settings. 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 the -Xrename-threshold=70 to lower the rename similarity 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 (i.e. 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 happens when line endings are converted between Unix style and Windows style. Git might think the files are 100% different even if the only difference is the line endings, so make sure you're both using the same line endings.

Answer 2

Just add all of your files. Anything that is a simple rename will be identified as having no difference and removed from the index. So even though a 'git status' shows loads and loads of issues, after the 'git add -A' there will be few remaining (and all that remain will have real diffs). You ought to checkout a new branch right away (prior to the 'git add -A') so that you can easily back track if it goes south.