问题标签 [git-rerere]

我正在开发一个带有 git 版本控制的项目。它有很多贡献者。在项目的最初几天，许多提交都是在没有作者的情况下进行的。我读了这篇文章，还有这篇文章。我已经尝试过，git rebase -i <Original commit SHA>但是我用标签标记的所有提交edit都有合并冲突需要解决！我考虑调用rerere以使用旧修复程序，但由于rerere更改被缓存并且我最初没有true在 gitconfig 中将其设置为，所以这里不是一个选项。

如果没有逐个提交并重新解决合并冲突，我能做些什么来更改那些早期提交的作者？

因此，如果我git rebase -i -p <commit>在主题分支上使用并且在某个地方之间有一个合并提交，我预计将由 git 重做。但是我最后一次进行合并提交时非常麻烦，并且进行了很多更改以支持另一个分支中的大修复。我没有rerere on。

我git cherry-pick -n <merge commit> -p <parent number>在变基中间使用了 a 并且它起作用了。我只需要说git checkout --theirs一切来解决冲突。

但我想知道我们是否可以在交互式 rebase 中途运行 rerere？还有一个很好的选择来代替 rerere 吗？

我可以告诉 Git 重新使用现有合并提交中的冲突解决方案吗？我在提交时已重新禁用。新的合并提交在合并的“我们”一侧包含一些额外的提交（但它们不应该引入新的冲突，因为它们修改了一组不同的文件）。

例如，采用以下 DAG：

现在，我想做的是将提交带入分支（m然后将其设置为新的主控）。我不想简单地合并到，因为它会创建一个新的合并提交（尽管没有冲突）。我想与父母一起重新创建承诺。m^old-mastermasterold-masteroma

新的 DAG 应如下所示：

我不介意使用 rerere，如果我之后可以告诉它记录现有合并提交 ( o) 的分辨率。

I'm trying to rebase a branch B over a branch A, but one of the newest commits in A deletes one folder replacing it with a git submodule.

After running git rebase A, git stops at every single commit of B (about 200) asking me to resolve conflicts. Then I run git mergetool and I get:

I tried to enable git rerere by running git config --global rerere.enabled 1 and I did call git rerere after having "resolved" (by just typing L).

The problem is: by looking in the .git/rr-cache/ folder I can see that it has recorded one resolution, but it is about the only time (in over 20 resolutions) where I did have to really resolve a conflict.

Maybe rerere doesn't record this type of resolution? If that's the case, how could I do it?

由于业务需求和旧习惯的结合，我们的 QA/BA 团队成员似乎认为他们需要能够在发布时为潜在的发布候选者挑选任何开发工作组合。这让我很担心，因为目前这会留下很多 git 的“疤痕组织”，以还原和还原还原提交以及“注释掉”和“取消注释”提交，这些提交有时会更糟。（除了悲伤：在 darcs 中，使用给定的工具会更容易实现，但当然我们没有使用 darcs，我们使用的是 git。）昨天在做一些研究时，我遇到了每个功能的分支(BPF) 工作流自动化工作及其维护“完全隔离、完全集成”(TITI) 的过程。现在我正试图弄清楚我是否可以在我们的工作环境中实现类似的东西，希望不会增加太多额外的开发过程工作，也不会把婴儿和洗澡水一起扔掉。（更不用说我如何在我们的 QA/BA 结构中显示一些自动化的其他问题......）

BPF 中的 TITI 过程严重依赖于共享的 git rerere 缓存，因此可以在一次性分支或集成分支中完成集成合并，但在构建候选发布 (QA) 分支时可重用于樱桃采摘过程。这里的特别之处是不要合并到“源”分支以保持源分支完全隔离。因此，我试图弄清楚这在我们使用 GitHub PR 作为集成合并的工作流程中是如何工作的。显然 PR 目前不允许复杂的合并，并且当前的工作流程是修复源分支中的合并冲突，但是如果我们尝试 BPF，那将违反隔离原则。理论上我们可以使用一次性合并技术，但是如何设置 GitHub 来共享 rerere 缓存？

TL;DR：处理共享 rerere并继续使用 GitHub 的拉取请求的最佳方式是什么，可能仍作为集成单元/仅需要集成合并？

（Hacky Aside：目前我们只“需要”在我们的一个存储库上执行此操作，并且该存储库当前托管在 GitHub for Enterprises 的本地，因此我可以说服具有 SSH 访问权限的管理员破解 git在机器上配置该存储库以打开共享 rerere 和 auto-rerere. 但是，依赖这样的 hack 有很多弱点，包括来自其他业务部门的潜在问题，为什么他们不能做我们正在做的事情公共 GitHub 以及潜在的 GitHub 更新问题，这些问题破坏了任何 git config hacks，假设它们甚至可以在第一时间工作......）

我正在阅读 Git Book 的 Git-Rerere 部分。我刚刚跑了git checkout master; git merge rerere2; git rerere diff。这是输出。

有三个不同的部分。

1. <<<<<<<显示什么？
2. <<<<<<< HEAD显示HEAD分支想要贡献的内容。
3. >>>>>>> rerere2显示rerere2分支想要贡献的内容。

看起来第一个差异部分是对rerere2想要贡献的内容的否定。不过，这对我来说没有意义。第一部分是什么意思？

这是交易。master 有一个文件，file1。我分支，并在分支中删除该文件。同时，我修改了master上的file1。轰隆隆，冲突。

当我将我的分支合并到 master 时，解决方案是删除该文件。我试图使用git rerere能够多次执行相同的分辨率，但正如您在下面看到的那样，在您删除文件的情况下它不会记录分辨率。

我找不到任何关于此的文档，这只是一个限制rerere吗？

在这里，我们应该看到类似“file1.txt 的记录分辨率”之类的内容，但我们没有。为了确保它没有记录我们的分辨率，我们继续进行并再次进行完全相同的合并：

在这里您可以看到它git rerere不记得冲突解决方案（实际上错误地将文件留在树中）。

Git rerere提供了在 rebase 期间重用以前的冲突解决方案，甚至可以通过设置来暂存已解决的文件rerere.autoupdate = True（详见另一个问题）。但是，即使解决了所有冲突并暂存了所有文件，我仍然必须运行git rebase --continue以继续 rebase 操作。

如果已解决所有冲突并暂存所有更改，我该如何自动继续？rerere

I received a conflict when trying to merge two files:

When I looked into user.py, there is no git-conflict-notation/mark that I was used to:

What could be the problem?

可以配置 gitrerere使其仅记住并在某些文件模式上应用合并分辨率吗？即：就在模式上pom.xml。