とあるエンジニアの備忘log
2013年9月24日火曜日
git の Acked-by と Reviewed-by
git log に付けられるタグで Acked-by と Reviewed-by の使い分けがよくわからなかったので、調べてみた。 翻訳が間違っている可能性もあるので、原文は [https://www.kernel.org/doc/Documentation/SubmittingPatches](https://www.kernel.org/doc/Documentation/SubmittingPatches) の 13) と 14) を参照してもらうとして、 ざっくりと、以下のように理解した。 - Signed-off-by: そのパッチのコード開発に関わった人、および そのパッチが投稿からマージに至るまでに経由した人を表す。 - Acked-by: そのパッチの開発に直接関わったわけではないが、 そのパッチをレビューし、パッチを取り込むことに賛成したことを示す。 管理者はパッチをマージする際に "yep, looks good to me" といった類のコメントを Acked-by タグに置き換えることがある。 実際、 Acked-by タグは、そのパッチが影響する分野の管理者によってよく使われる。 Acked-by を発行する際に、そのパッチすべてに対し承認する必要はない。 例えば、そのパッチが複数のサブシステムに影響する場合、 少なくとも自分の管理するサブシステム上で受け入れ可能であれば、Acked-by を付けることができる。 - Cc: そのコミットが変更する分野に関連する人で、まだコメントをしていない人を Cc: タグとして追加する。 Cc: は、タグに示された本人が明示的なアクションを取らなくても、追加されることのある唯一のタグである。 - Reported-by: 自分以外の人が報告した問題を修正する場合に、このタグを追加する。 ただし、報告者に事前に了承を得た上で追加すること。 つまり、このタグが付いているということは、バグが解決するまで、 報告者の協力が期待されるということ。 - Tested-by: タグのついている人によってテストが行われたことを示す。 - Reviewed-by: このパッチがレビューされ、(そのレビュアーの見地内では) パッチを取り込んでも問題ないと判断したことを示す。 そのパッチに興味を持った人は誰でもこのタグを提供することができる。 管理者にとって、このタグはレビューの進行度の目安になる。 特にその分野のエキスパートからの Reviewed-by タグが付いている場合、 そのパッチが取り込まれる可能性が高くなる。 - Suggested-by: このパッチのアイデアが、このタグのついている人のものであることを示す。 ただし、事前に報告者に了承を得た上で追加すること。 つまり、このタグに示された人からの協力が、将来の改変に渡って、期待できることを示す。 で、結局のところ Acked-by と Reviewed-by はどう使い分ければいいのか、依然すっきりしないのだが、 [http://linux-kernel.2935.n7.nabble.com/acked-by-meaning-td551744.html](http://linux-kernel.2935.n7.nabble.com/acked-by-meaning-td551744.html) を読むとはっきり書いてあった。 ポイントは Acked-by は特定分野のメンテナーによって使われることが多いという点。 Acked-by は発行する人(のランク)によって意味が違ってくる。 あるサブシステムのメンテナーが Acked-by を付けた場合、 自分の管理範囲では、問題ない、ということを示していて、 通常の使い方においては Reviewed-by より強い意味を持つ。 逆に、何の管理者にもなっていない人によって付けられた Acked-by は Facebook の「いいね」程度の意味しかない、だそうだ。 その分野で、そこそこの重鎮になってもないのに、 Acked-by を使うと 「てめえにわざわざ Ack される筋合いねーよ、このペーペーが!」 ということになりかねないので、使い方に気を付けることにしよう。
2013年9月18日水曜日
Git tips
たまにしか使わないものなど、忘れがちなものをメモ。 ### リポジトリのトップディレクトリを表示 ### $ git rev-parse --show-toplevel ### bare repository として clone する ### $ git clone --bare
### bare repository で current branch を変更する ### bare repository は working tree は持たないので、 $ git checkout
fatal: This operation must be run in a work tree のようにはできないので、 $ git symbolic-ref HEAD refs/heads/
とする。 ### リモートネームを追加 ### 例えば、 origin という名前をつける場合 git remote add origin
これで、長ったらしい
の代わりに `origin` という名前が使える。 ### git push と同時に追跡ブランチ設定する ### git push -u
のように `-u` オプションをつける ### リモートブランチの削除 ### git push
:
新しい投稿
前の投稿
ホーム
登録:
投稿 (Atom)