ghq(1) は Git プロジェクト以外にも使える
作業ディレクトリの管理に ghq を取り入れている。 もともと $HOME/work 以下に作業ディレクトリを切っていたが、 配下のディレクトリが日に日に増えていくのを見るのが辛かった。 ghq を使えば、作業ディレクトリがリポジトリのURL に基づいて整理される。 不便もあるが、何より秩序が生まれることが気持ちいい。
ところで、巷では peco との連携が必要以上に取り上げられているが、無理に併せて使う必要はない。 相性がいいのは確かであるが、とりあえず grep でしばらく使ってみるのがよろしい。 個人的には、ghq look がファジー検索に対応すれば、それだけで解決するのではないかと思う。 ちなみに、どうせ使うのであれば、別の対話型 grep ツールをお薦めする。 例えば、世界的に最もシェアの高い fzf や、percol（peco は percol を再実装したもの）である。
ghq は、Git 以外のバージョン管理システム（VCS）にも対応している。 対応している VCS は、Git, Subversion, Mercurial, Darcs の4つである。 1世代前のシステムとも互換性が取られているというのは、ツールとして素晴らしい。 ところで、ソースをみる限り ghq は、各 VCS のクライアント機能を自前で実装しているわけではない。 アプリ上から子プロセスを生成して、システムにインストールされているコマンドを実行するだけのようだ。 なので、実際に get するには、対応するクライアントツールがシステムにインストールされている必要がある。
試しに Subversion プロジェクトを get してみる。 この時、コマンドオプションや設定ファイルで、特別な指定を与える必要ない。 ghq には、対応する VCS をツール内で検知するような実装がなされている。 もちろん指定することも可能で、これには README.md の Configuration の項が参考になる。 指定してやることで、冗長なサーバ問い合わせをスキップすることが出来る。
$ ghq get {プロジェクト URL}/trunk
clone {プロジェクトURL}/trunk
git ls-remote {プロジェクトURL}/trunk
hg identify {プロジェクトURL}/trunk
svn info {プロジェクトURL}/trunk
svn checkout {プロジェクトURL}/trunk
...
リビジョン XXX をチェックアウトしました
$ ghq list
...
{プロジェクトパス}/trunk
ん、ディレクトリ名が trunk ...。 コマンドオプションが足りていないかとも思ったが、そういう訳でもないようだ。 致命的な問題でもないが、余裕のできたタイミングで ghq のリポジトリに issue を上げてみようと思う。 ちなみに、git-svn にも対応しているようなので、慣れている人はそちらも評価してみて欲しい。
