丁稚な日々

◆GitとGitHubを使ってみる

_ Linusのバカ発言はどうかと思う。
SubversionはSubversionで素晴らしいし、作ってる人たちは絶対バカじゃないよ。焦点の当て所が違うというだけだよね。

_ が、それはそれとして、Git(とGitHub)が提供するワークフローは非常に素晴らしい。それは認めよう。
というわけで、重い腰を上げてGitを触ってみることにする。

_ ではまずGitのインストールから。

_ うちはWindowsで、まあそうすると当然のようにcygwinでバイナリ配布があるわけだけど、cygwinのシェルじゃなくコマンドプロンプトで生活してる人にとってはcygwin版というのは非常に不便だったりする。
滅多に引数にパス名を指定することがない、とかなら害はぜんぜんないんだけど、この手のツールでパス名の指定に苦労するととてもじゃないがやってらんないということはcvsとsvnで嫌というほど身にしみている。
というわけで、Windowsネイティブなバイナリは... ... ...... え、ないの?

_ いや、あるにはある。msysgit。
今、「あるにはある」というネガティブな表現をしたけど、たぶんこれはすごく頑張っている代物だと思う。偉い。
でもね、偉いんだけど、まだβというかなんというか、とにかく作ってる人たちが「リリース版」と認めたものが存在しないのよ。
たぶん、そこには技術的な残存課題以外の理由があったりして、今存在するpreviewとかいうのもほとんど問題はないんだろう、とかいうことも推測できるんだけど、やはり正式なリリース版でない開発ツールを常用するというのはちょっと敷居が高い。
もちろん、敢えてそういうところに飛び込んでドッグフード食うのも一つの生き方なんだけど、個人的にはそれはrubyだけでもう十分だ。

_ もうこれで諦めてもいいんだけど、とりあえずWindowsネイティブなバイナリの方は将来に期待することにして保留として、うちのもう一つの環境であるNetBSDの方でGitを使ってみることにしよう。
とうぜんpkgsrcに... ... あれ、ないよ? と思ったら、devel/scmgitという名前で存在した。どうやらmiscにgitというパッケージがあって名前がぶつかったのが原因らしい。
ふーん、Git作った人は(ってLinusなんだけど)そんなことも調べないで名前付けたんだねえ。昔ならいざ知らず、このご時世にねえ...
ま、当事者でもないのに嫌味を言っても仕方ないので、インストールしよう。
... あれ、GNU tarなんか入れだした。なあ、コマンド作る過程で絶対にGNUのtarが必要な理由があるのか? そりゃいったいどんな理由だよ。
で、次はPerlが必要なのか。まあそれはよくあることなんだが... おい、なんで5.10以上が必要なんだよ。お前はPerl5.10のどの機能が構築に絶対不可欠だっつーんだ。
うちは5.8でPerlの環境ができあがってて、必要性すらまだ証明できてない開発ツール1個のためにその環境を壊すわけにはいかねーんだよ!
というわけでpkgsrcから入れるのは断念。
これはたぶんGitが悪いんじゃなくて、パッケージ作った人が悪いんだろう。

_ 仕方ないので、あんまり気は進まないが野良ビルドすることにする。
tarball拾ってきて展開して、えーとconfigure... ... が、ないね。
Makefileは既にある。かなり嫌な予感がしたが、とりあえずINSTALLファイルを見てみよう。
それによるといきなりmakeでいいよとか書いてあるわけだが、それを鵜呑みにできるほど無邪気な人生は送ってきていない。
続きを読むとmake configureでconfigure作ってそっから始めることもできる、と書いてあるのでそっちへ進むことにする。
で、実行すると... エラーだらけ。
ああ、これはもう慣れてるからすぐわかる、GNU makeじゃないとダメなわけね。
gmake configureっと。... 今度は大丈夫。
とりあえずいったん./configure --prefix=/usr/localとやってみたが、-lcryptoがyesで-lcurlがnoで-lexpatがnoで... ってこれはまずい。
libcurlやlibexpatは/usr/pkg/libに存在するわけで、できれば使っていただきたい。また、うちの環境ではlibcryptoは/usr/libと/usr/pkg/libの両方にあったりするんだけど、これも後者を使っていただきたいのだが、libcurlやlibexpatを見つけられなかったのにlibcryptoが見つかってるということは、前者を使ってしまっているのだろう。
ま、常識だとこの手のパスの指定はconfigureの引数にあるはずなので、./configure --helpしてみる。予想通り、--with-curl、--with-expat、--with-opensslでそれぞれパスが指定できるようになっている。
というわけでそれら全部に/usr/pkgを指定してやり直し... ても、やっぱりnoとか言いやがる。なんでやねん。
しばらく引数の指定の仕方をいろいろ試したりしたが、どうしてもうまく行かない。諦めてconfigureスクリプトそのものを読んでみる。
... configureの引数の指定とconfigureがやってるチェックとが、ぜんぜんまったくこれっぽちも関係ないんでやんの。configureで実行されるチェックは引数で指定したパスとは無関係。で、チェック結果とはぜんぜん関係なしに、引数で指定したパスがmake時に使われるファイルに変数として指定されているようだ。
まあ、そうだよね。Git作った人にとっちゃLinuxできちんと動けば十分だろうしね。
気を取り直して、configureはこれでよかったことにしてmake、じゃなくてgmake。
なんかいちおう正常に終わった。gmake docしたらasciidocがないとか言ってたけど、docなんかもうどうでもいいや。gmake install。
入れてから、嫌な予感がしたのでldd gitしてみる。
ああ、思ったとおり、/usr/pkg/lib/libcrypto.soと/usr/lib/libcrypto.soと両方にリンクしてる。ま、あんないい加減なconfigureじゃ当然そうだよな。
手を入れてどうにかする気力もないので見なかったことにしよう。

_ さて、ここまで延々と付き合って読んでくれた人は当然気付いてるだろうけど、仮にかつて私がGitに対して好意を抱いていたとしても、もはやそんなもんは一片のかけらも残ってはいない。
実際にはもともと好意なんか持ってなかったので、残っているのは敵意だけである。
それでもここまで作業を進めたのは、前述したようにGitとGitHubで実現されるであろうワークフローに非常に大きい期待があるからである。
ここまでで出会った山のようなクソには目をつぶって、輝かしい未来に向かって先に進むことにしよう。

_ ではまずGitの使い方から。
とりあえずオフィシャルのドキュメントに当たってみることにしよう。
とりあえず、体験したいのは、既存の誰かのレポジトリを手元でいじることなので、参考例は... Exampleがあった(*1)。Tony LuckがLinuxカーネルをIA64版メンテナとしていじる例、らしい。
ふむ、私がGitを使う際に想定される例に非常に似ている気がする。見てみよう。
えーと、Andrewが-mm、って何それ?(*2) git-fetchにgit-remoteねえ。で、それはいつどこで使うの? え、youって誰? 私? これTonyの話じゃないの?
... ふむ、よくわかった。Linux知らない人はわからんでいいですよ、ってことだね。
世間の人たちがRubyのドキュメントがどうとかこうとか叩く理由がすごーーーーくよく理解できた気がするよ。
それでもRubyは『初めてのRuby』読んで『たのしいRuby』読んで『プログラミング言語Ruby』読めば済むわけだけど、Gitは何読めばいいの?
... え、ないの? へーそうなんだ。

_ そろそろ敵意が殺意に変わってきたんだけど、いったい何にこの殺意を向ければいいんだろうね。
しかし、ここは忍耐力を限界まで振り絞って、一連の操作は気合で理解したことにする。
LinusさんがバカにしてたSubversionについての知識がなければまったく理解できないままだったと思うけどね!

_ では実際になんかいじってみることにしよう。
しかし、さしあたって現在GitHubにあるプロジェクトで、さっそく触ってみたい、というものはない。しかし、ちょうど手元にnadokaさん用の私家パッチが転がっているので、GitHubにnadokaさんのプロジェクトを勝手に作ってそれにこのパッチを入れてみることにする。
実はなぜか既にGitHubにアカウントは持っているので、プロジェクトの作成から。
プロジェクトはアカウントにぶら下がるので、Project Nameは他人との衝突を恐れる必要はないらしい。というわけでnadokaでOK。
「Create Repository」すると、持ってるレポジトリを入れろや的な説明が出てくるわけだけど、ここではnadokaさんのSubversionレポジトリをimportすることにする。
ぽち、ぽち、と進むと、svnユーザko1とznzの実名を入れろや、とか言われる。
実名つっても例を見る限りメールアドレスがほしいんだろうけど... まあ知ってるわけだけど、二人ともGitHubにアカウント持ってるんだよねえ。
ここで彼らがGitHubに登録したメールアドレスを入れると結び付けてくれたりするんだろうか? それとも単にGit的な都合で情報がほしいだけなのだろうか?
なお、両方入れるか両方入れないかどっちかにしろ、的なことも言っているので、何も入れないという選択肢もある。うーん。
... 考えてもわからないので、ko1とznzとだけ入れといたらGitHubアカウントと結び付けてくれたりしねーかな、とか思いながら先に進んでみる。
...
...
...
「Hardcore Importing Action」とかいう説明が出たまま、importが終わらない。
終わらないんだけど、GitHubからメールが届いた。曰く、「失敗したよ。ko1って誰? ま、やり直してよ」
どうも、やっぱりさっきのはちゃんとメールアドレスを入れないといけなかったらしい。
うーん、それなら何も入れない方がよさそうだな。
で、やり直すための説明によると、えーと、手動でやれ、ってか。
確かにWebの画面にはimportをやり直せそうな表示は一切ない。というか、まだ「Hardcore Importing Action」のままなんですけど。
うーん、あれだけGit入れるのに苦労したことを考えると、この上svn2gitとかgit-svnとかすんなり入れられる気がしない。というかできることならもうGit絡みのものは何も入れたくない。
というわけで、さっき作ったプロジェクトは削除して最初からやり直そう。

_ ... というわけで今度はアカウント情報のところで何も入れないということで、ちゃんとimportが完了したというメールが来た。ぱちぱちぱち。
Webは相変わらず「Hardcore Importing Action」のままだけどね。
ま、たぶんレポジトリの情報がWebに反映されるまでちょびっと時間がかかるのだろう、と好意的に受け止めておいて、できたはずのレポジトリをさっそくローカルでいじってみることにする。
git cloneは... おお、成功した。
とりあえずmasterブランチはいじらないことにして、git branch exprimentalでexprimentalブランチを作る。そしてgit checkout exprimentalで今手元にあるこのソースツリーの向いてる先をexperimentalブランチにする。
どうやらここまでは理解は正しそうな雰囲気。
ではこのソースツリーに既にある私家パッチを適用して、git commit -a。
そしてこのcommit結果をGitHubに反映するためにgit pushして... ふむ、成功したらしい。
ではGitHub側がどうなったかWebを見てみよう。
...
「Hardcore Importing Action」
...
...
いやあのさ、もうさっきから1時間は経ってるんですけど。いくらなんでも反映されるの遅すぎじゃね?

_ こりゃなんか問題を踏んだかな、というわけで、Supportサイトで"Hardcore Importing Action"で検索してみると...
出るわ出るわ山のように。
「ごめんね直したよ」とかいう返答がついているものもあれば、数日放置された後「今見たら問題ないみたいだけど?」とかいう返答がついてるものもある。
「『ごめんね直したよ』ばっかりだけど、つまりそっちでなんか作業しない限りどうしようもないってことなわけ?」と言ってる人もいる。
ふーん、そうですか。

_ というわけで、使ってみた結論。
いやあ、素晴らしい。GitとGitHubを使えば、開発ワークフローが劇的に変化することは間違いないね!
だって二度とこんなもん使った開発なんか関わるもんか、って心の底から納得できちゃうんだから。

_ ... まあ、そんなこと言いつつも、いつの日か「Hardcore Importing Action」が解消される日が来たら、もうちょっとだけ触ってみるつもりではある。
とはいえ、現時点でも一つだけ断言できることがある。
Rubyの開発レポジトリがGit＋GitHubに移行するような日が来たら、それでRubyとはお別れだ。

◆GitとGitHub

_ ちょ、お前ら釣られすぎ。
いや、釣ろうと思って書いたわけではないんだけどね。単なるFUD。

_ で、GitHubの方なんだけど、60時間以上経過してもまだimport中扱い。
これ報告しない限り直らねーのかなあ。まあ1週間くらいは様子を見てみよう。
しかし金曜の夕方に検索したときは228件だったのに、今見ると239件になってるね。
私のように報告しないで様子を見てる人とかも多数いるであろうことを考えると、これ誰がやってもSubversionレポジトリインポートできないんじゃね?

_ DragonFly BSDのdevelopment(7)が、Gitでなんかを追っかける例としてシンプルでわかりやすいことを発見。