对不同的GIT分支应用相同的文件重命名更改

我有一个项目，它有一个主分支和一个稳定的分支——分支很久以前就分开了。现在我在稳定分支上有几个提交，我也希望在主分支上有这些提交（bug修复）。我无法合并，因为分支发生了分歧，并且有大量未合并的更改-我只需要4次提交

所以我试着摘樱桃。但是，这失败了，因为顶级模块名称从“项目模块”方案更改为“模块”。当cherry拾取时，GIT会在旧目录中创建新文件（就像在旧分支上一样）：不会检测到重命名。这可能是因为我收到了以下警告：

warning: too many files (created: 278 deleted: 5364), skipping inexact rename detection

我尝试了git格式的patch+git-am，但这会再次在旧目录中创建文件

如何将提交应用于主分支

谢谢，

---

Adam

我怀疑您可以通过更改

merge.renameLimit

的值使其工作（但需要很长时间）：

merge.renameLimit

<>在合并过程中执行重命名检测时要考虑的文件数量；如果未指定，则默认为diff.renameLimit的值

---

我相当肯定cherry pick也会尊重这个价值。如果没有，您可以找到两个分支的共同祖先，在那里应用提交，然后将它们合并到两个分支中，以确保使用合并机制。（请注意，这实际上是我建议首先要做的。合并比cherry pick更可取，因为它们不会创建重复的提交，并且保留了历史流。）

我不再收到错误，但cherry pick仍然像在旧分支中一样创建目录，而不是修补新分支中的文件。我想我需要一种方法来应用一些提交，做一些路径转换。。。除了git格式修补程序+旧UNIX修补程序-n之外，还有其他方法吗？谢谢你给我的关于共同祖先的建议，我下次会试试的。虽然在这里我合并了一个拉请求，所以我对什么是父请求没有太多的控制权……嗯，是的，我可能会回到“手动”（即

sed

）补丁编辑。但是，您仍然应该使用

git-apply

，而不是

patch

。它支持git对补丁格式所做的所有小扩展。@adamw：我刚刚注意到git.git中有一个commit:-您的文件可能不在阈值范围内，您可以通过更宽松的方式让它以您想要的方式工作。（假设您还没有手动完成。）