whichprという便利なソフトウェアが存在している。これはGitのコミットハッシュからGitHub上のPull-Request番号を引くツールである。
$ whichpr show dc7eaf64ecb48e17524747ba78097bcb031ddc26 # => 7
$ whichpr open dc7eaf64ecb48e17524747ba78097bcb031ddc26 # Pull-Requestがブラウザで開かれる
詳しくは https://qiita.com/pocke/items/281e9157a530a6142178 を参照してほしい。
今回は、このwhichprを速くした。
whichpr以前の世界
人類はwhichprが誕生する前はコミットメッセージからヒューリスティックにPull-Requestの番号を推察していた。
See https://qiita.com/awakia/items/f14dc6310e469964a8f7
この手法には、Pull-Requestがrebase mergeされた場合や、コミットメッセージが複数行に渡るコミットがsquash mergeされた場合などに対応できないという問題がある。
何故ならば、これらの方法によってマージされたPull-Requestのコミットには、Pull-Request番号が含まれていないためである。
そのためそのようなケースでは、コミットメッセージからはPull-Requestの番号を取得することはできない。
今までのwhichpr
この問題を解決するためにwhichprは生まれた。
whichprはPull-Requestの番号を得るためにコミットメッセージを使用せず、GitHub APIを使用する。
これによりコミットメッセージにPull-Requestの番号が含まれていなくとも、Pull-Requestの番号を得ることができるようになった。
ところがAPIを使用するようにしたことによって、いくつかの問題点が発生した。
- APIリクエストが発生するために、従来のヒューリスティックな手法に比べて遅い
- APIリクエストを行うためにGitHubの認証情報が必要である
- 認証を行うアプリケーションを増やしたくない人にとっては、あまりうれしくないでろう。
これからのwhichpr
https://github.com/pocke/whichpr/pull/6
https://github.com/pocke/whichpr/pull/7
上記の2つのPull-Requestによって、先に挙げた問題は解消された。
今までのwhichprは常にAPIリクエストを発行していた。
しかし、上記のPRによって「コミットメッセージからPull-Requestの番号が推察できる場合」にはその推察した番号を使用するようになった。
これにより、APIリクエストを発行するのはコミットメッセージにPull-Requestの番号が含まれていない場合のみとなった。
多くのケースではコミットメッセージにPull-Requestの番号が含まれていると考えられるため、多くのケースでAPIリクエストの省略が期待できる。
またコミットメッセージにPull-Requestの番号が含まれていないケースを諦めれば、認証なしでwhichprを使用することも可能となった。
問題点
ただしこの新しいwhichprの手法にも若干の問題点がある。
Pull-Requestの番号の推測をヒューリスティックに行うため、コミットメッセージによっては間違ったPull-Requestの番号を提示してしまう可能性がある。
もっともそのようなコミットメッセージを使用することはほとんどないと考えられるため、ほとんどの場合は問題にはならないであろう。
この問題を解決するために--no-heuristicのようなオプションを追加することも検討しているが、まだ実装はされていない。
まとめ
whichprは今までの問題点が解消され、より使いやすくなった。
いままで使用していなかった方はぜひインストールを、すでに使用していた方はぜひアップデートをしてほしい。