当上游重写历史记录时,我怎样才能改变我所有的本地Git分支(和标签)？

Question

特定(嵌入式)linux内核repo的维护者修改了一堆古老的提交以清理历史.因此,所有提交都有不同的SHA.

当我从这个重写的历史中获取git时,我需要将我的本地分支重新定位到本地跟踪分支入口点,该入口点对应于我自己的分支开始的本地树中的点.标准方案:

git rebase --onto SHAxx master ownbranch

(SHAxx对应于下图中遥控器/ origin/master的c2).

但是,当我有几个自己的分支在master中有一个单独的祖先时,我必须为每个分支应用一个rebase.相反,我希望将所有带有任何关联标记的分支转移到单个操作中的获取跟踪分支中的新入口点.

在图形上,获取之后的状态,在任何操作之前(简化 - 超越左侧是深度主历史记录):

    c1'--c2'--c3'--c4'--c5'--c6'--c7--c8--c9 remotes/origin/master
   /
--o--c1--c2--c3--c4--c5--c6 master
           \
            o---o---o---o---o  branch1
                     \
                      o---o  branch2 (etc.)

确切地说:当我自己的工作从主提交c2开始时,我希望将我自己的子树及其所有标签(如果存在)在一个动作中重新定义到遥控器/ origin/master的c2'(与主人的c2相比具有不同的SHA) ).

那时我可以完全删除master并使用我自己的工作制作遥控器/ origin /掌握新的master:

    c1--c2--c3--c4--c5--c6  (old master, not referenced anymore)
   /
--o--c1'--c2'--c3'--c4'--c5'--c6'--c7--c8--c9 master = remotes/origin/master
            \
             o---o---o---o---o  branch1
                      \
                       o---o  branch2 (etc.)

然后我将测试构建过程是否产生与之前相同的结果,如果确定:继续将合并的主更新递增(例如,每个子索引在2.6.nn中的步骤)到我自己的(特定于板)分支中.

或者是否有其他/更好的方法来实现相同的结果？

Rebasing包括其所有子项的分支都提供了一种可能的解决方案,但标签不会移动.

Answer 1

下面介绍了使用相对较新的git replace命令的一系列步骤。使用此命令而不是rebase --onto ...，不会发生由于自己与 master 合并而引起的麻烦 - 可能需要冲突解决的合并，因为 rebase 实际上“重放”提交。

备注：最好克隆历史记录被重写的远程存储库并在此处插入您自己的分支，而不是“像往常一样”将此远程存储库获取到本地存储库，然后重新设置您自己的分支的基础。主要优点：当在重写的存储库中删除或重命名时，任何不属于您自己的旧内容都不会出现在新克隆的存储库中。当将重写的存储库提取到本地存储库时，在新历史记录中重命名的分支将导致旧命名的分支进一步存在。

拟议程序

• 克隆远程存储库及其重写的历史记录，大概只有与您的工作相关的分支 - 这有助于检查下一步操作。
• 指定remote add tmp当前本地存储库的路径。
• 在本地存储库上：在分支的起点（与 master 共享的点）添加一个标签（例如ownstart ）。
• 从这个 tmp 远程获取你自己的分支（一些git fetch tmp <branch>:<branch>）。与分支主并行的许多（重复）提交可能会出现在标签 ownstart 下方。进行下一步后该现象就会消失；或者，您可以在执行提取之前通过移植和 git filter-branch 在您自己的分支标记中创建一个新根）。
• 寻找新的对应起点，其中 ownstart 在重写的历史记录中有其等效提交，并按如下方式应用其 SHA：git replace ownstart SHA。这将创建从此时到新历史记录中相应条目的所有本地工作的虚假连接，并让“ ownstart ”下方的其余历史记录消失，因为引用失败。

注 1：这些操作之后的任何日志都应该已经显示所需的提交链（例如使用 gitk）。然而，被替换的提交并没有融合在一起：它们仍然是独立的，并且现在具有来自重写历史的共同祖先。这是设计所固有的，不会影响您自己工作的（正确）整体集成。可以（甚至推荐 - 请参阅注释 2）通过执行来删除这些双精度数git filter-branch -- --master..ownstart --all（这可能很耗时）。它将更改您自己的所有工作的 SHA，但上游提交链不受影响。该git filter-branch操作创建备份分支。联机帮助页的尾部filter-branch建议进行克隆操作，以获取没有这些备份的新存储库（在本地克隆时使用 --no-hardlinks）。但这将使您自己的所有分支都开始跟踪遥控器，同时分配另一个上游源。

注 2：在执行测试序列时，我自己的分支中某个提交（来自任意主提交）的任何合并在执行所述命令后都会自动重新链接到适当的重写历史提交git filter-branch。太棒了。然而，在另一次测试中，这种合并“消失”了。它可以通过发出带有 SHA 的命令来与重写的历史记录联系起来git replace，其中合并的主控端父级等于主分支的适当提交。然后git-filter-branch必须重复a。