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

score 1 · Answer 1 · answered Mar 29 '12 at 14:01

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.

score 1 · Answer 2 · answered Mar 29 '12 at 15:34

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.

You can tell git to ignore whitespace changes, that solves the line endings issue. See also http://stackoverflow.com/questions/861995/is-it-possible-for-git-merge-to-ignore-line-ending-differences — Adam Shiemke, Mar 29 '12 at 17:29

score 0 · Answer 3 · edited May 23 '17 at 11:45

You should pull down a new working copy to a new local folder, right next to the code you worked on first. Then using a Diff style tool to compare and merge your work into the new local copy. Then commit changes on the new pull down and bam, you have your changes committed. I know this does not save all of your change log on what you did, but if doing it manually isn't an option this is the next best thing.

Git Renaming Issues

3 Answers3