Gitにパッチを送るメモ

コンピュータ メモ Git

コードを書く

起点をどこにするか

バグ修正の場合
maint（無い場合はmaster）
新機能の場合
master（puに依存する場合はpu）

コミットを作る

Documentation/SubmittingPatches を読む。

  • パッチは論理的な単位に分ける。
  • git diff --check で無駄な空白が無いかチェック。
  • コメントアウトしたコードや不要なファイルが無いかチェック。
  • コミットメッセージ
    • 最初の一行は、50文字程度の短い要約にする。最後にピリオドは付けない。
    • 二行目は、空白行にする。
    • 三行目以降に、コミットメッセージの本文を書く。
    • 命令形、現在時制で書く。
    • コミット以前と以後で何が変わるのかを、明確に。
    • コードを書いた理由、何がしたかったのか、目的を明確に。
    • 最後の行に、サインオフ（原作者の証明書に同意する署名）を書く。実名のみ。
Signed-off-by: Your Name <you@example.com>
  • コミット後
    • バグを修正した場合、それが本当に直っているか、チェック
    • テストツールがパスするか、チェック

テストツール

t/READMEを読む。

  • makeすると全テストを実行（けっこう時間かかる）
  • 最新版のproveなら並列実行できるらしい
prove --timer --jobs 15 ./t[0-9]*.sh
  • 個別にテストするには、シェルで実行する
sh ./t3010-ls-files-killed-modified.sh

全て(?)のテストスクリプトでは test-lib.sh がsourceされている。これにより"t/trash directory.テスト名"というようなディレクトリが作られて、そこに cd して git init されるので、各テストスクリプトはその砂場でテストを実行する。この砂場はテスト成功時には削除されるが、スクリプトにデバッグオプション（--debug、-d）を付けると消されずに残る。

パッチを送る

電子メールの形式でパッチを作る

現在のブランチにあるコミットのうち、origin/masterに存在しないものを指定ディレクトリに出力

mkdir outgoing
git format-patch -M origin/master -o outgoing

outgoingディレクトリにそれぞれのコミットがパッチとして出力されるので、確認し、必要があれば編集する。
出力されたファイルは電子メールの形式で、Subjectはコミットメッセージの一行目、bodyは以降のコミットメッセージになっている。
コミットメッセージの最後の行（Signed-off-byのはず）の後には、三本ダッシュだけの行があり、以降にdiffstat、続いてパッチ本体がある。
コミットメッセージには含めないけどメールには書きたい内容は、この三本ダッシュ以降パッチ本体以前に書く。diffstatの手前など。

メーリングリストにパッチを送る

git-send-emailを使う。

gmailのSMTPから送る方法でやってみる
~/.gitconfig か .git/configに以下を追加

[sendemail]
    from = Your Name <you@example.com>
    smtpencryption = tls
    smtpserver = smtp.gmail.com
    smtpuser = you@gmail.com
    smtpserverport = 587

まずは自分に送ってテスト

git send-email outgoing/0001-hoge.patch

送り先、In-Reply-To（誰かに返信する場合は入れたほうが良い）、SMTPのパスワード等を聞かれるので入力する。

自分宛に届いたら、そのメールをmbox形式でファイルに保存して、実際にパッチを当ててみる。

git checkout origin/master
git am hoge.mbox

この結果は、git format-patchしたブランチの内容と同じになるはず

git diff HEAD..master

大丈夫そうなら、メーリングリストとメンテナ（あるいは自分の変更点を知るべき人が分かるならその人）宛に送る。

気をつけること

パッチを添付しない

パッチについてメーリングリストでディスカッションする際に、引用できなくなるので。

英語を頑張る orz

「以前はこう、そしてパッチ後はこう。〜がしたくて、やった」という説明を明確に書かないと、レビュアを混乱させる結果になる。
英語苦手でも、そこはちゃんと書くことorz

入門Git

今回、やはり入門Gitがとても参考になった。

入門Git

入門Git

版管理とは何か、ということ（新しいコミットを作るというのはどういう意味を持つ行為なのか、など）から、オープンソースのプロジェクトにおける役割分担、分散型システムでのコミットアクセス（コミット権限）がCVSやSubversionとどう違うのかなど、ワークフローの部分、そして特にすごいのが「Chapter 10.9 オープンな開発プロセス」で語られる、メーリングリスト上での議論の進め方。大半がネイティブスピーカーではない中で、どう議論を組み立てていくべきか、どうやったら無用な意地の張り合いを避けてプロジェクトを発展させられるのか、パッチレビューで反対意見を書く際に誤解されないための文章の組み立て方まで、ものすごいノウハウと、思想が詰まっている。

そうした互いの知識と経験を活かして、プロジェクト全体をより良くするための共同作業をしているのだ、という気持ちから始めれば、「譲れるところ」と「譲れないところ」という対立が出てくる余地はありません。あるのは、「こうするとプロジェクト全体に良い」か、「これだけではダメで別のやり方をしないとプロジェクト全体には役に立たない」かの違いだけです。

ー濱野 純 『入門Git』 秀和システム、 p.179