パッチを送る人への注意

パッチを送る場合は、いくつか心に留めておくべきことがあります。

パッチは一貫した手順で作成してください。バージョン管理システムを使用していれば、これは簡単なはずです。たとえばGitではgit diffを使用できます。それ以外の場合は、diff -Naur old newがよい方法です。oldとnewは、それぞれ変更前と変更後のディレクトリを表します。これらの名前にスラッシュを含めてはいけません。

ファイルの内容だけでなくタイムスタンプも伝える場合は、diffの出力ヘッダーに、従来のUnix形式を使った世界時の日付と時刻を含めるべきです。そうすれば、受け手は-Zまたは--set-utcを使用できます。次は、そのようなヘッダーを生成するコマンドの例です。Bourneシェルの構文を使用しています。

LC_ALL=C TZ=UTC0 diff -Naur myprog-2.7 myprog-2.8

受け手がどのディレクトリへcdし、patchにどのオプションを指定すればよいかを伝えて、パッチの適用方法を説明してください。オプションは-Np1を推奨します。自分を受け手とみなし、元のファイルのコピーへパッチを適用して、手順を試してください。

patchlevel.hファイルを用意し、送るパッチファイルの最初の差分でパッチレベルを増やすようにすれば、多くの人の苦労を減らせます。パッチにPrereq:行を入れておけば、順序を間違えて適用しようとしたときに、何の警告もなく適用されることを防げます。

/dev/null、またはエポック(1970-01-01 00:00:00 UTC)の時刻を持つ空ファイルと、作成したいファイルを比較する差分を送れば、ファイルを新規作成できます。これは、対象ディレクトリにそのファイルがまだ存在しない場合にだけ機能します。逆に、削除したいファイルとエポックの時刻を持つ空ファイルを比較するコンテキスト差分を送れば、そのファイルを削除できます。ただし、patchがPOSIXに準拠していて、-Eまたは--remove-empty-filesを指定しない場合は削除しません。ファイルを作成・削除するパッチを簡単に生成するには、GNU diffの-Nまたは--new-fileを使用します。

受け手が-pNを使用する場合、次のような出力を送ってはいけません。

diff -Naur v2.0.29/prog/README prog/README
--- v2.0.29/prog/README Mon Mar 10 15:13:12 2024
+++ prog/README Mon Mar 17 14:58:22 2024

2つのファイル名でスラッシュの数が異なり、patchのバージョンによってファイル名の解釈が異なるためです。混乱を避けるには、代わりに次のような出力を送ってください。

diff -Naur v2.0.29/prog/README v2.0.30/prog/README
--- v2.0.29/prog/README Mon Mar 10 15:13:12 2024
+++ v2.0.30/prog/README Mon Mar 17 14:58:22 2024

README.origのようなバックアップファイル名を比較するパッチは避けてください。patchが本来のファイルではなくバックアップへパッチを適用してしまうおそれがあるためです。代わりに、old/READMEとnew/READMEのように、別々のディレクトリにある同じベース名のファイルを比較するパッチを送ってください。

反転したパッチを送らないように注意してください。受け手が、すでにそのパッチを適用したのではないかと迷ってしまうためです。

パッチでは派生ファイルを変更しないようにしてください。たとえば、makefileにconfigure: configure.acという行がある場合のconfigureが該当します。受け手自身が派生ファイルを再生成できるはずだからです。派生ファイルの差分を送る必要がある場合は、UTCを使って差分を生成し、受け手には-Zまたは--set-utcを指定して適用してもらってください。また、パッチを適用したファイルに依存する未変更のファイルを、すべて(たとえばmake cleanで)削除してもらってください。

582個の差分リストを1つのファイルにまとめても済むかもしれませんが、問題が起きた場合に備え、関連するパッチごとにファイルを分ける方が賢明でしょう。