CODEWITHSUNDEEP
git
Henson
Henson

Reputation: 5923

Git Renaming Issues

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

Upvotes: 6

Views: 1994

Answers (3)

Richard Hansen
Richard Hansen

Reputation: 54263

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.

Upvotes: 1

GoZoner
GoZoner

Reputation: 70245

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.

Upvotes: 1

JustinDoesWork
JustinDoesWork

Reputation: 538

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.

Upvotes: 0

Related Questions