Go
Git
GitHub

whichprを速くした

whichprという便利なソフトウェアが存在している。これはGitのコミットハッシュからGitHub上のPull-Request番号を引くツールである。

https://github.com/pocke/whichpr

$ 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は今までの問題点が解消され、より使いやすくなった。
いままで使用していなかった方はぜひインストールを、すでに使用していた方はぜひアップデートをしてほしい。