"-X他们的"选项似乎不适用于某些Git冲突 [英] "-X theirs" option does not seem to work with certain Git conflicts

问题描述

这很烦人.

我使用此命令合并两个分支

I use this command to merge two branches

git checkout -b temp public/master
git merge -Xtheirs --squash -m "squashed with devtemp" devtemp

我遇到一些冲突:

CONFLICT (rename/delete): public/github.css deleted in devtemp and renamed in HEAD. Version HEAD of public/github.css left in tree.
Removing public/extra-html/exit-codes.html
Removing public/.gitkeep
Auto-merging package.json
Squash commit -- not updating HEAD
Automatic merge failed; fix conflicts and then commit the result.

如何忽略这种类型的冲突?尽管我/他们/我们(或那些命令使用的正确的Git API是什么)可以解决此类问题?有没有更好的方法可以实际起作用?

How can ignore this type of conflict? I though --theirs/--ours (or whatever the right Git API for those commands is) would solve this type of problem? Is there a better way that actually works?

推荐答案

-X theirs策略参数仅针对一个文件中的单个冲突而不是高层的完整文件冲突来指导合并的冲突解决.

The -X theirs strategy-argument only directs merge's conflict resolution for individual conflicts within one file, not for high-level full-file conflicts.

在这种情况下，如消息所示，冲突是他们"(devtemp)完全删除了"public/github.css"，而您"(HEAD)重命名了它.您的Git不确定该怎么做，并且已将文件保留为新名称.

In this case, as the message says, the conflict is that "they" (devtemp) removed public/github.css entirely, while "you" (HEAD) renamed it. Your Git is not sure what to do here and has left the file in place under its new name.

如果您想做他们所做的事情，只需git rm以新名称命名文件，以便将其删除.但是...请注意，重命名是通过内容相似性来检测的，因此它们实际上可能根本没有删除该文件，而是删除了另一个与内容(在删除之前)非常相似的文件.您创建的新文件.在这种情况下，删除文件可能是错误的.

If you wish to do what they did, simply git rm the file under its new name, so that it is removed. But ... note that renames are detected by content similarity, so it's possible that they did not actually delete that file at all, and instead deleted another file whose content (before being deleted) was pretty similar to a new file you created. In this case, removing the file is probably wrong.

在所有情况下，每当进行合并时，明智的做法是在提交之前测试结果.当将-X与ours或theirs一起使用时，尤其如此. Git不知道要合并的内容，仅依赖于文本相似性，并且可以进行无意义的合并，尤其是当在冲突情况下盲目偏爱一侧时，同时使用两侧时，尤其如此. '这些更改不会发生冲突的更改(这是-X选项所执行的操作.)

In all cases, whenever doing a merge, it's wise to test the result before committing. This is especially true when using -X with either ours or theirs. Git has no idea what it is combining and merely relies on textual similarity, and can make nonsensical merges, especially when blindly favoring one side in a case of conflict but using both sides' changes where those changes do not conflict (this is what the -X options do).

由于您正在运行git merge --squash，由于某种原因它总是会抑制最终的git commit(la git merge --no-commit)，因此您已经期望必须单独运行git commit.只需解决冲突(并像往常一样进行彻底测试)并提交即可.

Since you were running git merge --squash, which for some reason suppresses the final git commit anyway (a la git merge --no-commit), you will already be expecting to have to run git commit separately. Just resolve the conflict (and test thoroughly, as always) and commit.

编辑(针对每个评论):如果您希望以编程方式执行此操作(尽管我会建议您这样做)，则可以使用git ls-files --stage(也许与-z一起使用，以获得更好的机器可读输出) ).任何非零阶段的条目都暗示合并失败.索引的内容将告诉您发生了什么:

Edit (per comments): if you want to do this programmatically—though I would advise against this—you can use git ls-files --stage (perhaps with -z to get better machine-readable output). Any nonzero stage entries imply that the merge failed. The contents of the index will tell you what happened:

• 基本版本存在，我们的存在，而他们不存在:重命名/删除冲突，在该冲突中Git保留了我们的"重命名版本.删除我们的(git rm -- <path>)以删除他们".
• 基本版本存在，它们的存在，我们的不存在:重命名/删除冲突，在该冲突中，我们删除了文件但他们重命名了Git.工作树可能(我尚未测试)在其名称下具有该文件.添加它(git add -- <path>)以对其进行重命名. (您将需要设置一个测试用例，并验证这是正确的路径.)
• 基本版本不存在，它们的存在，我们的存在:创建/创建冲突.毫无疑问，Git将我们文件的版本保存在树中.使用git checkout --theirs -- <path>将其版本提取到工作树，然后使用git add -- <path>切换到其版本.

• base version exists, ours exists, theirs does not: a rename/delete conflict in which Git kept "our" renamed version. Remove ours (git rm -- <path>) to take "their" deletion.
• base version exists, theirs exists, ours does not: a rename/delete conflict in which Git where we deleted the file but they renamed it. The work-tree probably (I have not tested this) has the file under their name. Add it (git add -- <path>) to take their rename. (You will want to set up a test case and verify that this is the right path.)
• base version does not exist, theirs exists, ours exists: a create/create conflict. Git no doubt keeps our version of the file in the tree. Use git checkout --theirs -- <path> to extract their version to the work-tree, then git add -- <path> to switch to their version.

我认为，这应该涵盖所有未解决的案件.或者，如果您遇到的情况是根本没有任何实际的重命名，那么您将从Git的重命名检测代码中得到错误的点击，并且您将希望-X no-renames禁用它.

That should, I think, cover all the unresolved cases. Or, if you have a situation where there are never any actual renames, you are getting false hits from Git's rename detection code, and you will want -X no-renames to disable it.

这篇关于"-X他们的"选项似乎不适用于某些Git冲突的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！