コミットログに「どのプラグインに関わる修正」なのか明記して欲しい

[AmaiSaeta]

どのコミットがどのプラグインへの変更か判別しにくいので。
そういったガイドラインを制定してはどうでしょう。
例えば以下のような感じで。

hoge.jsプラグインにpiyoオプションを追加する例

[hoge.js] Add piyo option.

fuga.jsプラグインのtypo修正時の例

[fuga.js]Fix typo.

[anekos]

うーん、git log などの工夫ではいけないんですかねぇ。
コミットからファイル名はわかるので、冗長に思えるんですよね。

[anekos]

忘れることもありますし、以前のコミットもあるので。
もしやるなら、hook スクリプトがあると良いきがしますね。
(それでできれば)

[AmaiSaeta]

うーん、git log などの工夫ではいけないんですかねぇ。

特にGitHub上で見る時困る感じで…… https://github.com/vimpr/vimperator-plugins の"Latest commit to the～"の部分とか、 https://github.com/vimpr/vimperator-plugins/commits/master/ で。

---

6/17追記: 2つ目のURLをミスって1つ目と同じ物にしていたので修正しました。

[tyru]

git whatchangedを使うのはダメですか？

[anekos]

git whatchanged イイですね。

考えてみたんですが、やはり手動でやるのは嫌ですね。
絶対忘れますし、自動で出きるのが前提条件ですね。

それはともかく、複数ファイル(あるいは一定数以上)の時は後ろにつけるほうが良い気がしますね。
たまに、vimperator の変更などで一斉にかきかえる時がありますが、ファイル名ばかり先にくるとそれはそれでわかりづらい気がします。

以上、どうでしょうか。

[AmaiSaeta]

git whatchanged イイですね(←知らなかった)。長いし後で何か適当にalias設定しとこうかな。

閑話休題。先日、このIssueについてTwitter上でanekosさんと話した内容を、ログを残す目的で、以下に転載しておきます。漏れは無い……筈。

---

AmaiSaeta: vimprのissueに書いた提案、「自動化出来ないとヤダ」と言われたのでGitのhookの勉強も兼ねて作ってみてるけど、どうも自動化すると問題が有りそう。つまらんミスの誘発を招きそう。
anekos: @AmaiSaeta github 用のグリモン書くという方向はどうですかね
AmaiSaeta: @anekos GitHubのコミットメッセージ側に対象プラギン名を付加するグリモンって事ですかね?
anekos: @AmaiSaeta あと、自動化無しではありえない、というだけで、それが好ましいということじゃないです。
anekos: @AmaiSaeta そうですね。そのコミットメッセージ表示部分に、挿入する感じで。
AmaiSaeta: @anekos ああそれは分かってます。
AmaiSaeta: うーん
AmaiSaeta: まぁぶっちゃけグリモンでの解決というのは全く思いつかなかった
anekos: @AmaiSaeta 言っておいて、なんですけど、グリモンもまあ BK ではありますね…
AmaiSaeta: @anekos ああいや、あのissueの需要が俺しかないというなら別グリモンでも良いんですけど。その"うーん"は「自動化だと微妙に問題が有る」という意味での唸りですね……
anekos: @AmaiSaeta 他の人の意見は目にしたことはないものの、欲っする人が他にいてもちっともおかしくないとは思ってます。
AmaiSaeta: @anekos ええと、Gitのhook、グリモン双方に自動化する場合に引っかかる点が在って、(続)
AmaiSaeta: @anekos (続)Gitのhookで当てはまるものとして「エディタでメッセージを保存せず終了させる事でcommitをabortさせる際に自動挿入分を手で消さないといけない=abortしたつもりで出来ていないcommitが紛れる可能性が出てくる」というのが先ず一つ。(続)
AmaiSaeta: @anekos (続)双方で問題となるケースとして、「『プラギンを構成するファイルが1つである』という大前提が必要になる」というのがもう一つ。双方とも「運用時に注意しろ」でカバー出来るっちゃ出来ますけど、そうすると「何の為の自動化なんだよ」という話になっちゃうと言う。
anekos: @AmaiSaeta 一つでないと問題になるのは、なぜでしょうか？ 長くてみづらいとかですか？
AmaiSaeta: @anekos 「commitされた複数のファイルが、同じプラギンを構成する物か、別のプラギンの修正を1 commitで行ったかがプログラム上で判別出来ない」からですね。1つのプラギンに対する修正なのに、10も20もファイル名(!=プラギン名)が列挙される事に。
anekos: @AmaiSaeta たとえば、vimperator の変更に追従するために、複数のプラグインを一挙に変更みたいな時の話ですか。たしかにそういう時にどうすべきかは、また別意見がありえそうですね。
AmaiSaeta: @anekos はい。「複数のプラグインを一挙に変更～」は、もう、commit方法の是非という別の話になっちゃいますが。
anekos: @AmaiSaeta そういう事であれば、実装の事を抜いていえば、グリモンのほうが良いんですかねぇ。個人個人で適用するか選べますし。改造もできますし。
AmaiSaeta: @anekos ですね。ただ、そうなると、GitHubのHTMLが変更された時のコストとか考えると鬱になれますがｗ
anekos: @AmaiSaeta ですよねー。 API とかあればマシでしょうけど、どうなんですかね。
AmaiSaeta: うん?GitHubのAPI……?在るのか……?
AmaiSaeta: GitHubにAPI在った……意外だ……すげー意外だ…… → GitHub API http://t.co/iTdYe6l3
anekos: @AmaiSaeta このあたり使えそうにみえますね http://j.mp/LuLJn1
AmaiSaeta: @anekos 「認証どうしよう」という不安がありますけど、使えそうですね……
AmaiSaeta: あー、いや、完全に個人利用であれば不案無いじゃん。
thinca: Gitのコミットフックってプロジェクト全体で適用しようとしたらコミッタ全員にフック入れてもらわないといけないからOSSだと実質無理じゃね?
AmaiSaeta: http://t.co/gUnDiAOS しまった。これまた頭から抜けてた……
AmaiSaeta: まあ何にせよ、 http://t.co/7mOKWohu http://t.co/RUs1krdM の理由であんまりやる気出てこない訳だが……ｗ
anekos: @AmaiSaeta 認証はいらないっぽいですけど、コミットのファイルリストはなんかできなさそうに思えてきました
AmaiSaeta: @anekos 実際に試してないのでイマイチ確証持ててないですが、　http://t.co/pb1daF6B のGet a single comitかな?という気が。
anekos: @AmaiSaeta あ、たしかに。見逃してました。ファイルのリストもありますね。

[AmaiSaeta]

tyruさんの、https://t.co/s2Tar706 にvim-jp/vitalの話も交えて「『こうあるべき』でルール作っても枕を濡らすことにしかなりませんよ」と言おうとしたけど、hook script作ってくれるならvim-jp/vitalにも流用できると思い、水を差さず黙っておいたwという発言も在りますし、hookの勉強がてらちょっと作ってみました。 https://gist.github.com/2953543 (anekosさんの言ったようにファイルリストは末尾に付与するようにしてます)

ただし、上のTwitterログ転載内にもある通り、以下の理由で、自動化は筋が悪いように思えます(vim-jp/vitalの都合は分かりませんが……)。

• コミットメッセージ入力時、コミットをabortさせる目的でメッセージ入力時のエディタを非保存で終了させると、ファイル名のリストだけをコミットメッセージとしたcommitが成されてしまう。誤操作を誘発する可能性。
• 「複数のファイルで構成されるプラグイン」に対応出来ない。このIssueの趣旨は「プラグイン名の明記」であって「ファイル名の明記」ではない。

[tyru]

自分としてはthincaさんのこの発言になるほどーと思ったりしました。

https://twitter.com/thinca/status/214365026302181376

Gitのコミットフックってプロジェクト全体で適用しようとしたらコミッタ全員にフック入れてもらわないといけないからOSSだと実質無理じゃね?

あと

ただし、上のTwitterログ転載内にもある通り、以下の理由で、自動化は筋が悪いように思えます(vim-jp/vitalの都合は分かりませんが……)。

@AmaiSaetaさんが書いてくれれば流用「できるかもしれない」し黙っておこうかなーという程度のもので、vim-jp/vitalの都合まで考えてくれる必要はないです。
完璧に変更なしで流用できるとも思ってませんでしたし。