問題タブ [quilt]

私は Inkscape の開発者の 1 人です。さまざまなフリー ライブラリのいくつかの変更されたチャンクをコード ベースに組み込み、ソフトウェアへのパッチをより保守しやすい方法で処理したいと考えています。

Quilt パッチ ツールを使用して、Debian パッケージのアップストリーム コードにパッチを適用しました。Inkscape のビルドで使用することを検討しました。

つまり、

1. Quilt を使用して関連するすべてのアップストリーム ファイルにパッチを適用する
2. ソースをコンパイルする

これにより、アップストリーム ライブラリの元のコピーと別のパッチ セットを維持し、それをアップストリームに転送できます。

私の問題は、Debian のドキュメントを除けば、Quilt を Makefile にきちんと含める方法の例が見つからないことです。誰でもこれを行うプロジェクトを教えてもらえますか?

現在 Automake を使用しているので、メイン ビルドの前に「パッチ」ルールを実行するエレガントな方法があれば、それは素晴らしいことです。

Debian パッケージにパッチを追加しようとしています (Ubuntu 14.10 "Trusty" を実行している amd64 マシン上)。

問題のトラブルシューティングを行っている間、パッチを 1 つのファイルを追加するものに減らしました。(文脈上、このファイルはデバッグ シンボルを含むファイルfluxboxも作成するようにパッケージを変更します。)fluxbox-dbg

次の手順に従ってパッチを作成しました。

• （既存のパッチがすべて適用されていることを確認してください。）
• quilt new add-dbg-package.patch
• quilt add debian/rules.d/70-debug-symbols.mk
• （私が欲しかった内容でそのファイルを作成しました。）
• quilt refresh

パッチは問題ないようです：

• すべてのパッチを適用すると、ファイルが存在し、正しい内容になります。
• パッチには、ファイルの完全な内容を追加するデルタが含まれており、他には何も含まれていません。
• このファイルを参照する他のパッチはありません。
• 新しいパッチをポップすると、ファイルが削除されます。もう一度押すと、再作成されます。

ただし、でパッケージを再構築しようとするとdebuild、次のようになります。

私がそのアドバイスを受けるquiltと、パッチが最新であることがわかります (そうであるように見えます)。 quilt diff変更はないと言っています。

quiltDebian 制御ファイルの変更にパッチを追加するのは間違っているのでしょうか?

私が気分を害するために何をしたかを理解するのを手伝ってくれる人はいますdebuildか?

私たちのプロジェクトでは、アップストリーム ソフトウェア (U-Boot) の上に機能を実装しています。1 年または 2 年に 1 回、新しいハードウェアの開発が開始され、アップストリーム ソフトウェアの新しいバージョンがベースとなります。以前に実装された機能の一部は、ほとんど変更せずに、ほとんどそのままで新しいプロジェクトに適しています。

したがって、特定の機能の範囲内で行われた作業を追跡して再利用できるワークフローが必要です。コード ベース全体から削り取る必要はありません。頻繁に必要とされるわけではないので、完璧であってはなりませんが、苦痛であってはなりません。

主な問題は、最初の実装から数週間/数か月後に機能が修正/調整される場合があり、これが数回繰り返される場合があるため、バニラの「機能ブランチ ワークフロー」がそのまま機能しないことです。

チームとコード ベースはどちらも比較的小規模です (それぞれ最大 5 人、アップストリーム コードの上に最大 15 の LoC)。通常、一度に特定の機能に取り組むのは 1 人だけです。

ここでは、考えつくことができた 2 つのオプションを示します。複雑さの唯一の原因であるため、上記の問題のあるシナリオの処理についてのみ説明します。

方法 A

初期状態: 機能の最初/前のバージョンはブランチ X にあり、最後に変更されたのは数か月前であり、マスターにマージされています

1. git checkout X; git merge --no-ff master
2. 変更を加えてコミットする
3. git checkout master; git pull; git merge --no-ff X; git push

次にgit log --first-parent --no-merges、このブランチで最初から行われたコミットのリストを表示します。

このアプローチの主な問題は、脆弱で制限があることです。

• 誰かがステップ 1 で早送りを使用してマージした場合、履歴を取得するための上記の方法はその後機能しません。AFAIK --no-ff はリポジトリレベルで強制できますが、誰もがそれを行う必要があり、忘れないでください。
• ステップ 3 の rebase-and-then-merge も歴史を壊すものであり、多くの人がこのアプローチとリベース全般を好んでいます。リベースを完全に禁止する方がおそらく安全ですが、強制する方法がわかりません。

方法 B

誰かが機能 X の作業に戻るたびに、新しい X_fix_this、X_change_that などを作成します。

欠点: 見苦しく乱雑なブランチ リスト、これからコミットのリストを作成するために必要なスクリプト。

現在、パッチのセットをキルトに保管しています。これは上記の問題を完全に解決しますが、他の点では非常に醜いです。

（より良い）アイデアはありますか？