1

OpenSSH ( Roumen Petrov の X.509v3 実装) にコミュニティが管理するパッチを、私たち自身のパッチと一緒に取り込もうとしています。私の知る限り、これは通常のソリューションには当てはまりません。このパッチは巨大であり、このパッチのすべてのリリースは OpenSSH の特定のアップストリーム バージョンに大きく依存しているためです。パッチを適用したバージョンの上に OpenSSH をアップグレードするのは明白なマージの競合であり、まさに私が避けたいことですが、Git ではアップストリーム バージョンとパッチを適用したバージョンを区別します。

現在、ブランチを使用して Git でこれを行っています。

master
gert/develop
vendor/orig
vendor/roumenpetrov

と

  • vendor/origコードの単純なオリジナルの OpenSSH ブランチであり、コミットごとに OpenSSH リリース バージョンの 1 つがタグ付けされています。5.9p1
  • vendor/roumenpetrovvendor/orig対応するパッチが適用された分岐したブランチであり、タグも付けられています。5.9p1+x509-7.1
  • gert/developに基づいた「毎日の開発」ブランチであり、vendor/roumenpetrov影響の少ないローカル コミットがいくつかあります。
  • masterリリース準備完了コードのブランチであること

私の目標は基本的にこれです：

  • コードのすべての変更の検出可能性。例: 「すでに 6.0p1 を使用していmasterますか?」->git branch --contains <commit-of-openssh-6.0p1>はい/いいえの答え。
  • OpenSSH と Roumen のパッチの両方を簡単にアップグレードでき、ローカル パッチとの競合を最小限に抑えることができます。
  • View は新しいバージョンを単一のコミットとしてアップグレードします。たとえば、「X509-7.4 へのパッチへのアップグレード」と「新しいアップストリーム 6.0p1 へのアップグレード」です。

実際には、上記のモデルに問題があります。Roumen からの対応する新しい 7.4 パッチと共に 6.0p1 にアップグレードしたいとします。私は何をすべきか？次のオプションが見つかりました。

  • アップグレード、元に戻す、アップグレード、マージ

    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

    問題: 1) 取るべきアクションが多い、2) ログを読むときに復帰アクションが別のコミットで混乱する ("6.0p1 release" -> "revert X509 7.1" -> "merge vendor/orig" -> "apply" X509 7.4".), 3) その後の再パッチ操作を伴う元に戻すと、競合が発生する可能性が理想以上になりますよね?

    プラス面：git log vendor/orig..vendor/roumenpetrov4つのコミットをリストしていますが、実際の変更を示しています。

  • 同じですが、--no-commit

    1. でvendor/roumenpetrov：git revert -n <patch-7.1>
    2. でvendor/roumenpetrov：git cherry-pick -n <openssh-6.0p1>
    3. In vendor/roumenpetrov:git commit 魔法のようにこれをメッセージと同じコミットとして認識します。

    問題:git log vendor/roumenpetrov..vendor/orig別のコミット ハッシュ (diff=empty) があるため、openssh-6.0p1 が適用されていないことが示されます。

  • マージ--squash

    問題: 上記と同じですが、別の理由があります。

  • リベース

    問題: このリポジトリを中央の (まだ公開されていない) 場所にプッシュします。したがって、他の人がこのブランチでも作業しているかどうかを知る限りvendor/roumenpetrov、新しいブランチのリベースはオプションではありません。vendor/origこれは、他のリモート ブランチにも当てはまります。リベースが私の場合のオプションではないと私が信じる理由については、この回答を参照してください。

    そして、 svnpenn が言及していることは本当ですか?

    リベースがなければ、醜いマージコミットを行う以外に選択肢はありません。

では、一歩下がって、これを保守可能にするための最良のオプションは何ですか? 特定の OpenSSH バージョンに依存する Roumen からのパッチという避けられない理由で、犠牲を払う必要がありますか? この分岐モデル全体を修正する必要がありますか? それとも、非常に基本的なことを見逃していますか?

4

1 に答える 1

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これにより、マージコミットが回避され、人々がそうすることに決めた場合に、マスターへのマージが非常に簡単になります。

参照

于 2013-01-29T23:24:24.553 に答える