ghq的なやつを作った

背景

loves ghq

ghq良いですよね。
無思考でGoPath配下の構造に倣ってプロジェクトを管理できるの、最高だと思います。

ところで、僕は横着者なので、プロジェクトがPythonで出来ていようがC#だろうがVimScriptだろうが、ghqでgetしてたりします。
要するに「何も考えずにプロジェクト管理はghqに委ねる」というスタンスをとりたいのです。
そして、そのスタンスだとghqはちょっといくらか不足があり、それをPRとして本家に出そうと考えたときに、内部のちょっとしたメンテナンスしにくさを感じました。

forked ghq

ちょっとこれは根本的に違うもの作ったほうが自身のニーズを満たせそうだ、と思い立ったので、
別のプロジェクトとして gogh を作ってしまいました。
（あんまりそういうスタンスでのForkは良くないと思うんですが）

gogh の目指すところ

• 目的
  • GitHub(+GHE)でホストしているプロジェクトの、ローカルでの配置を管理する
    • ghqにならい、Golang風構成（i.e. ./github.com/kyoh86/gogh）でClone
    • 対象ホストごとに設定を切り替える。デフォルトはgithub.comをターゲットとする
  • プロジェクト間をまたぐような操作を極力サポートする
    • ローカルでの操作も、リモートでの操作も
    • 逆にプロジェクト内に収まるようなものは hub の領域と捉える。サポートしない。
    • プロジェクトがまだない状態での操作もサポート対象とする
      • create
      • fork
      • etc...?
• ghq との差異
  • 設定や一つ一つの機能をシンプルにする
    • そのためにもGitHub以外のホストはサポートしない。
    • 最大公約数的な機能ではなく、最小公倍数的な機能を作る。
  • ghq look は作らない
    • jump into project とされてはいるものの、実態は当該ディレクトリをWDとするシェルの起動。
    • つまり cd - は機能しないし、気づくとプロセスツリーがエライことになってる。
    • 代わりにzsh/bash functionとして似たような機能を提供する。（gogogh）
  • 重複した名前のプロジェクトも分かりやすく表示する
    • 重複した名前のプロジェクトが増えてくると、全部長ったらしいパスで表示されたりするのは困る。
    • --unique オプションの出力がとても難解なので、もっとシンプルに。-f=short
  • git config によらない。
    • いろんなツールの設定がgitconfigにあふれて管理めんどくさいし分かりづらい。
    • そして設定値の呼び出しがとても重い。
  • 設定ファイル自体を対象ホストごとに分ける
    • git config 内に設定を持とうとしたこと（と、おそらく歴史的経緯）で、ホストごとに分けられる設定、分けられない設定がややこしい
    • ホストごとに設定しないと変な挙動を示すこともままある
  • GitHub 以外の何かは対応しない
    • そちらは別の何かで管理するほうが良さそう
    • 今の所そもそも向き合ったことがないけど…
  • hub との間を埋める
    • ghqでできることとhubでできることの間に、いつもちょっと面倒なこと、が発生していたのを解消する
    • 新たにforkするとき：元プロジェクトをClone、forkしてプロジェクトを作る
    • 新たにプロジェクト作るとき：ローカルにプロジェクトフォルダを作り、GitHub上にもリポジトリを作る。
  • （些末な宗教） github.com/onsi/gomega と github.com/urfave/cli が好きではない。github.com/stretchr/testify と github.com/alecthomas/kingpin がいい。
  • （実験的・ニーズ不明）単なるCLIとして作るのではなく、同時にライブラリとして使える何かを作ってみたい。(github.com/kyoh86/gogh/gogh package)。 hub リスペクトなのだけど。