Question

我正在尝试在OpenSSH（Roumen Petrov's X.509v3 implementation）上添加社区维护补丁以及我们自己的补丁。据我所知，这不适合常规解决方案，因为这个补丁非常庞大，而且这个补丁的所有版本都与OpenSSH的特定上游版本绑定在一起。 OpenSSH在补丁版本之上的明显升级是一个简单的合并冲突，正是我想要避免的，但在Git中保持上游和修补版本不同。

现在，我已经使用分支在Git中完成了这个：

master
gert/develop
vendor/orig
vendor/roumenpetrov

使用

vendor/orig是一个简单的，原始的OpenSSH代码分支，每个提交一个OpenSSH发行版本，也被标记，例如5.9p1
vendor/roumenpetrov是来自vendor/orig的分支，其中应用了相应的补丁，也标记了，例如5.9p1+x509-7.1
gert/develop是“每日开发”分支，基于vendor/roumenpetrov，现在只有一些本地影响较小的提交。
master是发布就绪代码的分支

我的目标基本上是这样的：

代码中所有更改的可检测性。例如。 “我们已经在master已经在6.0p1了吗？” - ＆GT; git branch --contains <commit-of-openssh-6.0p1>是/否答案。
轻松升级OpenSSH以及Roumen的补丁，与本地补丁的冲突最少。
查看将新版本升级为单一提交：例如“升级到X509-7.4补丁”以及“升级到新上游6.0p1”。

实际上我的上述模型存在问题。假设我想要从Roumen升级到6.0p1以及相应的新7.4补丁。我该怎么办？我找到了以下选项：

升级，还原，升级，合并
1. 在vendor/orig中，升级OpenSSH版本。
2. 在vendor/roumenpetrov中，还原先前的提交（git revert 12345678，7.1补丁）。
3. 在vendor/roumenpetrov中，与vendor/orig合并。
4. 在vendor/roumenpetrov中，应用新的修补程序并提交。
5. 在gert/develop中，与vendor/roumenpetrov
6. 相同，但--no-commit
  1. 在vendor/roumenpetrov：git revert -n <patch-7.1>
  2. 在vendor/roumenpetrov：git cherry-pick -n <openssh-6.0p1>
  3. 在vendor/roumenpetrov：git commit 中，将此识别为与来自邮件的提交相同。
  4. 合并--squash
    
    问题：与上述相同，但出于其他原因。
  5. 底垫
    
    问题：我们将此存储库推送到中央（尚未公开）的位置。因此，如果其他人也在这个分支上工作，那么在新vendor/roumenpetrov的{{1}}分支中重新定位是不可取的。这也适用于其他远程分支。请参阅this answer，了解为什么我认为变基不是我的选择。
    
    而且svnpenn mentions是什么？
    
    没有rebase，除了做丑陋的合并提交之外别无选择。

所以，退后一步，我最好的选择是什么才能保持这种可维护性？根据特定的OpenSSH版本，我是否必须为Roumen补丁的不可避免的原因做出牺牲？我是否需要修改整个分支模型？或者我错过了一些非常基本的东西？

Answer 1

OpenSSH在补丁版本之上的明显升级是简单合并冲突和我想要避免的，但保持上游和修补版本与Git不同。

我处理这个问题的方法是将更改保存在单独的分支上

A--B--C
       \
        X--Y--Z

然后如果提交上游

A--B--C--D--E--F
       \
        X--Y--Z

您可以将分支重新绑定到新的HEAD

 A--B--C--D--E--F
                 \
                  X'--Y'--Z'

这可以避免合并提交，并且如果upstream人决定这样做，将很容易合并到master中。

ref

如何使用git管理软件上的外部维护补丁？

1 个答案: