如何解决在第一个分支中删除并在第二个分支中重命名的文件的合并冲突？

Question

I am working on a branch where I have deleted some folders. In the meantime on the master branch all the root folders have been renamed, so the path of all files (including the ones I have removed) has been renamed.

When I attempt to merge I get a conflict on all the files of all the folders that have been both deleted (on my branch) and renamed (on master). I made a list of these (1000+) files which appear like this in git status's Unmerged paths :

added by them:   FolderRenamed/File1.ext
added by them:   FolderRenamed/File2.ext

I would like to restore them at this occasion, from the "theirs" version when I attempt to merge master in my branch (although you could have expected me to want to do the opposite, and have the files deletion been confirmed ; which would be the same concept with "ours" instead of "theirs").

I thought I could simply call the following command for every file :

git checkout --theirs FolderRenamed/File1.ext

But it does not seem like calling this command on a file achieves any change. My file is still in the "Umerged paths" list.

Can somebody help me identify what I am doing wrong ? Is git checkout not working as I expected because the local version had been deleted ?

Answer 1

TL;DR: you just need to git add them.

Longer

When I attempt to merge I get a conflict on all the files of all the folders that have been both deleted (on my branch) and renamed (on master) ...

Yes: when you run, eg:

git checkout branch
git merge master

Git:

• identifies your current commit ( HEAD aka branch : these select one particular commit by hash ID, which is the commit you have in your index and work-tree right now as well), also known as local or --ours , but I just call this L (left/local);
• identifies the other commit (aka master ), also known variously as remote , other , and --theirs , but I just call this R (right/remote);
• finds the merge base between these two commits. That's the most recent commit-in-common. I call this B for base.

(Note that if you check out master and run git merge branch you are just swapping L and R for this part of the process.)

Git then, in effect, runs two git diff s with rename detection enabled:

git diff --find-renames B L > /tmp/b-vs-l.patch
git diff --find-renames B R > /tmp/b-vs-r.patch

The result is a list of everything you did in L since the base B , and everything they did in R since the same base B . Git then combines these changes.

If you renamed a file and they deleted "the same" file (as detected by the rename detection), this is a rename/delete conflict. If they renamed a file and you deleted it you get the same conflict. Either way Git has a conflict.

In the special case of conflicts (but not in ordinary cases), Git will leave, in your index, all three versions of every file : the one from B , which Git leaves in the index as "stage 1"; the one from L , which Git leaves in the index as "stage 2" or --ours ; and the one from R , which Git leaves in the index as "stage 3" or --theirs .

These higher-numbered stage files are how Git remembers that you are in the middle of a conflicted merge. Normally, all the files in the index are at "stage zero". If Git were able to resolve the conflict on its own, it would erase the three higher stages and leave just a stage-zero resolved file in place.

The files in your work-tree are (mostly) independent of the files in your index, and of course you work-tree has no stage slot numbers. There can only be one somepath/file1.ext . In the case of a rename/delete conflict, there's a stage 1 entry for the base file and a stage 2 or stage 3 entry for the --ours or --theirs file. The other stage-slot (3 or 2 respectively) is left empty. The git status command shows this to you as added by us (1 and 2 occupied, 3 empty) or added by them (1 and 3 occupied, 2 empty).

Running git checkout --ours tells Git to copy the stage-slot-2 version to the work-tree. Running git checkout --theirs tells Git to copy the stage-slot-3 version to the work-tree. In either case, nothing happens to the stage-slot-1 entry, and the stage-slot-zero entry remains empty.

Running git add tells Git to copy the file from the work-tree to the stage-zero slot, wiping out the remaining slots entirely. The file is now resolved.

Since Git leaves the renamed file in the work-tree (under the new name), all you need to do in this case is git add the renamed file.

That's not the only way to do it though

If you run git checkout commit-specifier -- path , Git extracts the given path from the given commit-specifier . When Git does this, it copies the path into slot zero of the index. This wipes out any slot 1-3 entries for that path, so a side effect of checking out a file from a specific commit is that this resolves the file.

This is different from git checkout --ours and --theirs because those extract from the existing index entries , so they don't write into slot zero.

Hence you can also use git checkout MERGE_HEAD -- paths to extract the renamed files into their renamed names, resolving the merge conflict in the process.

Answer 2

git checkout --theirs does checkout "their" version, but it's checking out from the index, not updating it, and that doesn't mark the conflict resolved.

Checking out from a named commit updates the index, and the name of an in-flight merge's "theirs" tip is MERGE_HEAD . So

git checkout MERGE_HEAD -- paths/to/files`

to simply declare those the correct versions.

Of course git add also updates the index, so you could git checkout --theirs , inspect the result to be sure it's what you meant, then git add it.

Answer 3

Turns out the right way to proceed here was simply (as suggested by git...) :

git add FolderRenamed/File1.ext

Or, as I want to restore all the files inside my renamed folders, simply :

git add FolderRenamed

(And I would have used git rm if I had wanted to remove the folders and their content...)

Git is so powerful :).