20

私はMercurialmq拡張機能に慣れており、アップストリームで一連のカスタムパッチを維持しています。これらは、アップストリームとは別に別のリポジトリとして公開できます。今gitではプライベートブランチとを使用rebaseしていますが、パッチを他の人と共有したいまではうまく機能します。

Mercurialでは、パッチキューは独立したリポジトリであり、通常どおり公開できます。Bitbucketは、親リポジトリにリンクするためのパッチキュー機能も提供します。Gitでは、パッチを使用してプライベートブランチを公開すると、（マージを解除しない限り）パッチをリベースする機能が失われますが、パッチは時々更新する必要があります。

私が見つけた別のSOの質問から、Gitの世界ではStGitがの同等物として提案されていることがわかりましたmq。使用法はと似ていmqますが、StGitでパッチキューを公開するにはどうすればよいですか？

（stg publishパッチ自体を公開するのではなく、新しい「マージフレンドリー」ブランチを作成することを目的としているようです）

Gitでパッチキューを公開する他のアプローチは何ですか？

4

4 に答える 4

8

回答とコメントを要約します。リモート アップストリームを介して小さなカスタム変更を公開するにgitは、次の 2 つの方法があります。

  • 忘れrebaseて、必要に応じてブランチと新しいマージを公開します
  • ブランチがリベースしていることを宣言し、リベースして公開するだけです (賛成: 履歴を消去、反対: 他の誰かが継続的に使用するのは苦痛になる可能性があります。例: linux-next)

これまでのところ、純粋なパッチ キュー ワークフローは git では実行できないようですが、罪悪感mqはコマンドの名前でさえも非常に近いようです。バージョン管理された (および公開可能な) パッチ キューは許可されません。

于 2011-02-21T10:18:16.623 に答える
1

与えられたコメントを考慮すると、Mercurial の mq と多かれ少なかれ同等のアプローチは罪悪感を使用するようです。mq とは異なり、guilt は「パッチ リポジトリ」のインターフェイスを直接提供しませんが、.git/patches/<branch>手動で .git リポジトリに変換できます。

于 2011-03-09T21:13:01.367 に答える
-2

Mqに関する提供されたリンクからのAFAICT、git rebaseとほぼ同じ発行の問題がありますか?

全体として、リベースブランチであるという警告を付けて、ブランチを公開することが最善の選択肢だと思います。たとえば、linux-next ブランチはこのように維持されています。

于 2011-02-19T20:40:23.167 に答える