「不具合の出たコード」が欲しいと言われた。
開発中に難しい不具合が出たので対応している時の話。ヘルプを求めていたら、上のようなリクエストが来た。
諸々の事情で Git のリポジトリーを共有できなかったので、Zip に固めて渡すことにした。けれど、手元のリポジトリーは別のコミットが 3 つくらい入っている。今の修正も stash に入れて作業するのは面倒だし、この前記事にした git worktree を使うほどでもない。
そこで使ったのが git archive コマンド。
$ git archive --format=zip コミット・ハッシュ値 > failed.zip
コミット・ハッシュ値は git log で調べた。
コマンド一つで .git ディレクトリーとか無視して欲しいファイルを除いて zip ファイルを作成してくれる。ハッシュ値を指定して、古い状態を直接 zip 化できるのもありがたい。
こういう、ちょい面倒な作業をシンプルにしてくれるコマンドはもっと覚えていきたい。
Emacs のバージョンを調べる方法について。
一般には変数 emacs-version を参照すれば良い。
emacs-version
"26.0.50.1"けれども、ぼくのように開発版の Emacs を使っている場合はこの情報だけじゃ不十分。バグを見つけたとしても、数コミット先では修正されているかもしれない。
そんなケースでは Git のハッシュ値を見る。Emacs も Git でバージョン管理するようになったから (数年前まで CVS だったのが信じられない!)
嬉しいことに、コンパイル時の Emacs のハッシュ値を調べる関数がある。
(emacs-repository-get-version)
"308d5962236448a84795f49d775601599688d78d"すごい!!
emacs-repository-get-version については下記記事で知った。感謝。
Git 2.5.0 から git worktree コマンドで「今とは別」のブランチを他のディレクトリーに書き出すことが可能になった。
$ git worktree add path branch
例えば、feature/fix-a で作業中に hotfix/2.1.1 のコードが読みたくなったとする。その場合、こんな風にする。
$ cd ~/project/foo $ git branch develop * feature/fix-a hotfix/2.1.1 master $ git worktree add ../foo-hotfix hotfix/2.1.1
これで ~/project/foo-hotfix に hotfix/2.1.1 ブランチの内容がコピーされた。
このコマンドの面白いところは、リポジトリーをコピーしているのではないところ。リポジトリーはあくまで一つで、別の worktree を作っている。worktree はリポジトリーにひも付いた作業場のこと。git init や git clone した後に「作業をしている場所」のこと。
リポジトリーが同じなので、worktree コマンドで作った場所 (上の例では ~/project/foo-hotfix) でのコミット等は自動的に ~/project/foo でも参照することができる。git merge など不要。
複数のブランチを参照したい時、複数のブランチをほぼ同時に編集したい時に便利。
普段とは違う PC で作業をしていたら、Git の Committer と Author を変更するのを忘れてた。いつも使ってるコミッターと作業になってしまうのは気持ち悪い。一つ程度なら手作業で直してしまうんだけど、今回は 7 つもコミットしていた。一括で変更したい。やり方を探したら、ピッタリの記事を見つけた。
次のコマンドを叩く。実際に使う時は \ の後ろの改行を消して! (名前は ataka, メアドは masayuki.ataka at gmail.com にしている。適当に読み変えてください)。
$ git filter-branch -f --env-filter \ "GIT_AUTHOR_NAME='ataka'; GIT_AUTHOR_EMAIL='[email protected]'; \ GIT_COMMITTER_NAME='ataka'; \ GIT_COMMITTER_EMAIL='[email protected]';" HEAD
これでリポジトリーの全てのコミットを修正できた。
やってから思ったのだけど、これ、破壊力が大きい。今回は自分のコミットしかないリポジトリーだったけど、他の人のコミットとかあったら色々困ったことになってた。用法・用量はよく理解して使いたい。
こちらのドキュメントを読むと、その強力さが良く分かる。今度、ちゃんと勉強してみよう。
Emacs の git フロントエンド magit の解説ムービーが紹介されていた。
英語だけど、英語が分からなくても大丈夫。画面を 2 分割して右画面にどのキーを打ったのか見せてくれる。どのキーを押して、どんな操作が出来るのか分かる。magit 初心者には良い教材になると思う。
stage, commit, stash, fetch そして rebase。初級から中級まで。
ぼくは、このビデオを見て l l でコミット・グラフを magit の中で表示できることを知った!
git で diff を取る時、空白(スペース) に関わる変更を無視したい時がある。コードの可読性を上げるためとか、インデントを修正しただけとか、行末のスペースを消しただけとか、そういった「空白まわり」の変更が入っている時。スペースの変更を気にせず、メインの修正にだけ注目したい場合、空白を無視するオプションを使うと便利。
git diff に -b オプションを付けるか、--ignore-space-change オプションを付ける。
空白無視 diff のサンプル。まずは普通に diff を取ってみる。
$ git diff
diff --git a/chatwork.el b/chatwork.el
index b3a96e5..5f8cd9c 100644
--- a/chatwork.el
+++ b/chatwork.el
@@ -249,9 +249,9 @@ CALLBACK sould be a callback function"
(goto-char (point-max))
(mapc (lambda (plist)
(let ((message-id (plist-get plist :message_id))
- (account-id (plist get (plist-get plist :account) :account_id)
- (send-at (plist-get plist :send_time))
- (body (plist-get plist :body)))
+ (account-id (plist-get (plist-get plist :account) :account_id))
+ (send-at (plist-get plist :send_time))
+ (body (plist-get plist :body)))
(insert chatwork-page-delimiter
(number-to-string message-id) " "
(number-to-string account-id) " "
メインの修正は最初の一行だけ。続く 2 行は alignment を揃えただけ。
ここで -b オプションを付けて diff を取ってみる。
$ git diff -b
diff --git a/chatwork.el b/chatwork.el
index b3a96e5..5f8cd9c 100644
--- a/chatwork.el
+++ b/chatwork.el
@@ -249,7 +249,7 @@ CALLBACK sould be a callback function"
(goto-char (point-max))
(mapc (lambda (plist)
(let ((message-id (plist-get plist :message_id))
- (account-id (plist get (plist-get plist :account) :account_id)
+ (account-id (plist-get (plist-get plist :account) :account_id))
(send-at (plist-get plist :send_time))
(body (plist-get plist :body)))
(insert chatwork-page-delimiter
空白修正以外の diff が取れた。このコミットの変更の本質が浮かび上がる。変更点が分かりやすい。便利!
Emacs のパッケージ管理システムで magit をアップデートしたら、次のような警告が現れた。
Error (magit): git-commit-mode has to be removed
Magit is no longer compatible with the library `git-commit-mode', which was used in earlier releases. Please remove it, so that Magit can use the successor `git-commit' without the obsolete library getting in the way. Then restart Emacs.
Error (magit): git-rebase-mode has to be removed
Magit is no longer compatible with the library `git-rebase-mode', which was used in earlier releases. Please remove it, so that Magit can use the successor `git-rebase' without the obsolete library getting in the way. Then restart Emacs.
コンパイル中に一瞬現れる。確認するには、*Warnings* バッファーを開く。
要点は、最新の Magit では git-commit-mode パッケージと git-rebase-mode パッケージを使わなくなったので削除してね、ということらしい。
パッケージ・システムで対象のパッケージを削除。念のため、magit パッケージも削除。Emacs を再起動して、magit パッケージをインストール。これでおしまい。
時々、git add するつもりじゃなかったファイルを git add して困ることがある。その度に元に戻す方法をネットを探すハメになるので、ブログに書いておく。
foo.txt を誤って git add してしまった場合の対処法。
$ git reset HEAD foo.txt
いつも忘れちゃうんだよね〜。
Github で milkypostman/melpa を fork して ataka/melpa を作った。
Pull Request を作って、本家にマージしてもらった。それから数か月経った。また Pull Request を作ろうと思った。ところが、ローカル・リポジトリーは最新じゃない。リモート・リポジトリーを pull しても意味がない。何故なら、リモート先はオリジナルのリポジトリーじゃなくて、ぼくが Fork したリポジトリーだから。Fork したリポジトリーをオリジナルに同期させなきゃいけない。
サイトを探したら、英語の説明があった。自分用メモとして訳しておく。
$ git remote add upstream [email protected]:milkypostman/melpa.git $ git fetch upstream $ git checkout master $ git rebase upstream/master $ git push origin master
upstream リモートを作って fetch。master ブランチで upstream/master を rebase。最後に push で Github に反映させる。以上。
master ブランチから大きく fork したトピック・ブランチを master へマージする時のお話。
小さな変更 (数日分) ならまだしも、数週間・数か月近くブランチが分岐したままだと、merge はどこかで conflict する。そこで力技に走っている人を見かけたので、アドバイスした。
merge 専用のブランチを作りなさいよ。
$ git branch * big-change master
例えばこんな風に bag-change branch がある場合、直接、merge は行なわない (トラブルが起きないなら、直接 merge しても構わないと思うけど)。
$ git checkout master $ git merge big-change
代わりに一回 merge 用の branch を作ってそこで conflict 解消の作業を進める。
$ git checkout master $ git checkout -b merge-big-change $ git merge big-change
こうしておけば、merge-big-change branch で取り返しの付かない失敗をしてもブランチを削除すればいいだけだし、master ブランチも big-change ブランチも綺麗なままなので、修正を加えることもできる。
一番好ましくないのは、conflict を起こして、その間 master も big-change ブランチもコンパイルが通らない (もしくはテストが通らない) 状況が続くこと。
意外と、こうやって「作業」を分割して、リスクを下げることに無頓着な人がいるのでエントリーにしてみた。まあ、それだけ git という VCS というか、ワークフローが磨かれて、泥臭い作業に直面する機会が減ったということなのかもしれない。
Emacs がバージョン管理システムに Git を採用した。ぼくが初めて Emacs のソースコードを読んだ時 (このブログを始める前のこと!)、Emacs は CVS で管理されていた。Subversion がリリースされても CVS で開発が続いた。2009 年末、Emacs は CVS から bzr へと移行した。
そして、2014 年 11 月。10 か月に渡るディスカッションを経て Git へとバージョン管理を移行した。
Emacs の Git Repository は Savannah (FSF のリポジトリー・ホスティング) の中にある。
$ git clone git://git.savannah.gnu.org/emacs.git
Emacs コンパイルのチュートリアルがある。
英語なので、要点だけ日本で。
コンパイル方法は次の通り:
$ make
コンパイル前に必要なパッケージを入れておく。
一番シンプルな方法。
$ sudo apt-get build-dep emacs24
apt-get build-dep が動かない場合は、必要なパッケージを指定する。
Debian/Ubuntu なら:
$ sudo apt-get install gcc automake autotools libmagick++-dev \ libgtk2.0-dev libxft-dev libgnutls-dev libdbus-1-dev libgif-dev
Fedora なら:
$ sudo yum-builddep emacs
もしくは
$ sudo yum install gcc makeinfo texinfo gtk3-devel gnutls-devel\ giflib-devel ImageMagick-c++-devel autotools automake \ libXaw-devel libpng-devel ncurses-devel libxml2-devel
おっと、Mac で Homebrew を使ってる場合はどうするんだろう? 分かったら、また書く。
新しいフレームワーク、新しいツールを使ってプロジェクトを開始する時、当然そのプロジェクトは git で管理するとして、.gitignore をどうするかは頭痛のタネになる。
例えば、ぼくは XCode で iOS アプリを開発しようとしているけれども、どのファイルを Git で管理すれば良いのか分からない。どのファイルを無視して良いのか分からない。そこで役に立つのが GitHub が集積している .gitignore ファイル一群。
XCode ならば Objective-C.gitignore というファイルをコピーすればいい。
# Xcode # build/ *.pbxuser !default.pbxuser *.mode1v3 !default.mode1v3 *.mode2v3 !default.mode2v3 *.perspectivev3 !default.perspectivev3 xcuserdata *.xccheckout *.moved-aside DerivedData *.hmap *.ipa *.xcuserstate # CocoaPods # # We recommend against adding the Pods directory to your .gitignore. However # you should judge for yourself, the pros and cons are mentioned at: # http://guides.cocoapods.org/using/using-cocoapods.html#should-i-ignore-the-pods-directory-in-source-control # # Pods/
内容充実な .gitignore ファイルが用意されている。
CocoaPods を使う場合は Pods ディレクトリーを .gitignore に含めることを勧めない、とのコメントもあり。ぼくは Pods ディレクトリーを ignore しちゃう派だけど、そこら辺は自己責任で決められたし。Pods ディレクトリーを含める・含めないについては下記記事を参照とのこと。
ここには Objective-C の他にも、Android, Elisp, Rails, Scala, Swift, TeX と様々な言語・フレームワークへの gitignore ファイルが集まっている。gitignore ファイルをどうするか頭を悩ます時間があったら、サクッとここのファイルを使わせてもらおう。時間の節約にもなるし、勉強に繋がることもある。
GitHub は一人が複数のアカウントを持つことを良しとしていない。とはいえ、何らかの事情で複数のアカウントを取得する人もいると思う。例えば、個人と会社でアカウントを分けなければいけない場合など。
ここでは仮に ataka-private と ataka-work という 2 つのアカウントを取得した場合を考えてみる。
仕事用アカウントで big-project リポジトリーを作成したとする。この場合、git clone/pull/push は次のようになる。
$ git clone [email protected]:ataka-work/big-project.git $ git pull [email protected]:ataka-work/big-project.git $ git push [email protected]:ataka-work/big-project.git
仕事用の設定は特に問題ない。ところが、同じ様に ataka-private アカウントに git でアクセスすることが出来ない。
まず、プライベート用の ssh キーを作る。
$ ssh-keygen -C ataka@private
デフォールトでは id_rsa というファイル名になるけれど、ここは id_rsa_private という名前に変えておく。github の ataka-private アカウントに id_rsa_private.pub の中身を登録。
ataka-private アカウントにアクセスするのに、id_rsa_private を使う様、~/.ssh/config に次の設定を追加する:
Host github.com-ataka-private
HostName github
User git
IdentityFile ~/.ssh/id_rsa_private
ataka-private アカウントにある misc プロジェクトを git clone してみよう。github が推奨するように remote を設定する。ただし、github が提示する URL に一つ変更を加える。
$ git remote add origin [email protected]-ataka-private:ataka-private/misc.git
これで、clone/pull/push が出来るようになる。
$ git clone [email protected]:ataka-private/misc.git $ git pull origin master $ git push origin master
アカウントの数が増えても、同様に対処していけばいいだけ。
ここでは仕事用をデフォールトにしたけど、逆にしてしまっても良いし、.ssh/config に仕事用の設定を追加してもいい。ま、どうしても複数アカウントを作らなきゃいけない場合に参考にして頂ければ嬉しい。
Qiita にやり方が書いてあったんだけど、自分のブログにも書いとかないとすぐ忘れちゃうんでメモ。元ネタはこちら。
この記事が書いてる通り、リモートのリポジトリーでブランチを誰かが削除しても、ローカルにはブランチが残ってる。これは気持ち悪い。そこで、誰かがリモートでブランチを消したら、ローカル環境にも反映させたい。
remote が origin だとした場合、次のコマンドでローカルのブランチも消せる。
$ git remote prune origin
ちなみに、リモートのブランチを消す方法は次の通り:
$ git push origin :branch
消したいブランチ名の前に : (コロン) を置くのがコツ。
せっかくなので少し解説すると、git で branch を push する場合、次のようにする。
$ git push origin local-branch-name:remote-branch-name
つまり、ローカル・ブランチとリモート・ブランチの名前は変えられる。けど、普通、ブランチ名を変える必要はないので、こうなる。
$ git push origin branch-name:branch-name
branch-name を二回書くのは煩わしいので、上のコマンドは下のコマンドと同じという扱いになっている。
$ git push origin branch-name
さて、話は戻ってリモート・ブランチを消す方法。空のブランチをリモート・ブランチに push すればいい。「空のブランチ」は空白で良いので、結果、コロンをブランチ名の前に置いたらリモート・ブランチが削除できたようなコマンドが出来上がる。
$ git push origin :branch
以上。
Git で他人が作った branch を見たり修正したりする機会があったので、やり方をメモ。
まずはブランチの確認。
$ git branch --all master remotes/origin/HEAD -> origin/master remotes/origin/develop remotes/origin/feature/foo remotes/origin/master
おや、手を入れたい branch は feature/bar なのだけど見当たらない。
そうか、feature/bar がある remote は origin じゃないのか。remote 先は review 用のリポジトリーだった。review のブランチを取得する。
$ git fetch review * [new branch] develop -> review/develop * [new branch] feature/bar -> review/feature/bar * [new branch] master -> review/master
取得成功。この feature/bar ブランチも見つかった。さて、feature/bar ブランチをいじりたい。checkout -b を使う。
$ git checkout -b feature/bar review/feature/bar
修正が終わったら、
$ git push review feature/bar
で、おしまい。
review リモートを使ってない人は、普通 origin リモートがあるはずなので review 部分を origin に置き換えて読まれたし。
MacBook Air に自作 EmacsLisp スクリプト fcopy.el を chef-solo を使ってインストールした。fcopy.el は git で管理してて、GitHub にホスティングしてる。つまり、今回は Mac に chef-solo で git 管理されてるツールをインストールする話。chef-solo のインストールについては過去記事を参照のこと。
fcopy 用の cookbook を作る。
$ cd /etc/chef $ bundle exec knife cookbook create fcopy
fcopy 用の recipe は /var/chef-solo/cookbooks/fcopy/recipes/default.rb を編集。install リソースを使わず、git リソースと bash リソースを使ってる。
git "/tmp/fcopy" do
repository "git://github.com/ataka/fcopy.git"
reference "master"
action :checkout
end
bash "install-fcopy" do
install_dir='/usr/local/share/emacs/site-lisp'
not_if {
File.exists?("#{install_dir}/fcopy.el")
}
code <<-EOC
install -m 664 /tmp/fcopy/fcopy.el #{install_dir}/
EOC
endchef-solo を実行して fcopy.el をインストールする。レシピを指定してインストールする場合:
$ cd /etc/chef $ sudo env PATH=$PATH bundle exec chef-solo -o fcopy
node.json を指定するなら、次の様に node.json を書く。
{
"screen": {
"users": [ "ataka", "ataka_work" ]
},
"run_list": [
"recipe[screen]",
"recipe[fcopy]"
]
}chef-solo の実行では -j オプションを使う。
$ sudo env PATH=$PATH bundle exec chef-solo -j node.json
今回の recipe では .emacs の編集までは行なわない。使う人は、~/.emacs.d/init.el に次の二行を追加。
(autoload 'fcopy-mode "fcopy" "copy lines or region without editing." t)
(define-key mode-specific-map "k" 'fcopy-mode) ; C-c kgit リポジトリーからコードを clone して、bash を使ってインストールするレシピを書いた。今回の recipe には、更新 (update) が入っていない。どういう recipe を書くのが良いのかな? まだまだ勉強することが多い。分からないことも多い。
git status にせよ、git log にせよ、色が付けば嬉しいもの。色を付けるには次のコマンドを打つだけ。
$ git config --global color.ui auto
試しに git status。
うん、綺麗に表示されてる。
さて、ディストリビューションによっては git log すると文字化けをおこすことがある。git status だと問題ないのに、git log だと駄目。
その理由は?
git log はログを眺めるために PAGER ツールを使っているから。普通は less が使われる。この less がカラー対応していないと、色出力用のコードがそのまま見えて「文字化け」したかの様に見える。
less ならば -R オプションを、lv なら -c オプションかな。git の PAGER 設定で対策するのも手だけれども、カラー出力するのは git だけじゃないので、.bashrc なりに alias を突っ込んじゃいましょ。
alias less="less -R"これで git log してもカラー化されたログを眺めることができる。
満足、満足。
Redmine はローカル・マシンにあるリポジトリーしか参照できない。なので、Redmine 用のサーバーとリポジトリー用のサーバーを分けて運用している場合、チケットとコミット・ログを紐付けることができない。
これは不便なので、公開リポジトリーに commit したら Redmine サーバーにデータを転送するようにした。
なお、掲題の通り今回は git リポジトリーを扱う。
Redmine を動かしているサーバーを server_redmine と呼ぶ。
Git の公開リポジトリーを置いているサーバーを server_git と呼ぶ。リポジトリーは /var/git/sample.git にあるとする。
server_git から server_redmine へ ssh ログインできる様に設定をしておく。
server_git で上 ssh 鍵を作り、server_redmine へ公開鍵をコピーする。
server_git ~$ ssk-keygen -t rsa server_git ~$ ls .ssh/ id_rsa id_rsa.pub server_git ~$ scp .ssh/id_rsa.pub server_redmine:~/ server_git ~$ ssh server_redmine server_redmine ~$ mkdir .ssh server_redmine ~$ chmod 700 .ssh server_redmine ~$ touch .ssh/authorized_keys server_redmine ~$ chmod 600 .ssh/authorized_keys server_redmine ~$ cat id_rsa.pub >> .ssh/authorized_keys server_redmine ~$ rm id_rsa.pub server_redmine ~$ exit
以上で設定は終了。ssh ログインできれば成功。
server_git ~$ ssh server_redmine server_redmine ~$ hostname server_redmine
まずは、server_redmine に server_git の git リポジトリーを clone する。
server_redmine ~$ cd /var/git/ server_redmine /var/git$ git clone --mirror ssh:server_git:/var/git/example.git
--bare と --mirror の違いがいま一つ分かっていないけれども、--mirror の方が今回の用途に合っていそう。
なお、この作業には server_redmine から server_git へ ssh ログインできることが前提になっている。もし出来ない場合は、上の server_git から server_redmine へ ssh ログインする設定をもう一度、逆方向にして欲しい。
ここまでで、server_git にある最新の git リポジトリーを server_redmine に持って来れた。けれど、今のままでは server_git のリポジトリーにコミットされた内容が server_redmine 側に反映されない。
たいていのバージョン・コントロールには hook という機能がある。コミット直前に何かするとか、コミット直後に何かするとか、そういう機能。
git にも hook 機能があるので、それを使う。今回使うのは post-update フック。
post-update は、全てのコミットが公開リポジトリーに push された後に実行されるフック。server_git 内の /var/git/example.git/hooks/post-update を編集する。中身は次の通り:
#!/bin/sh # # An example hook script to prepare a packed repository for use over # dumb transports. # # To enable this hook, rename this file to "post-update". # exec git update-server-info ssh -t -t server_redmine <<EOF cd /var/git/example.git git fetch --all exit EOF
server_redmine に ssh ログインして、git fetch している。git の公開リポジトリーから redmine 側のリポジトリーに push できれば話は簡単なのだけど、「公開リポジトリー (--bare 付きで作ったリポジトリー)」からは git push できない制約がある。仕方がないので、server_redmine 側に移って git fetch している。
ファイルを作ったら、実行権限を付けるのを忘れずに。
server_git ~$ chmod +x /var/git/example.git/hooks/post-update
他サーバーにある git repository を同期する手段には、cron を使って定期的に git fetch (or git pull) する方法もある。この方法の欠点は、git push 後、Redmine にデータが同期するまでにタイムラグが出来ること。また、git repository が更新されていなくても、git fetch が実行されてしまうこと。
hook を使えば、誰かが git push したら、自動的に Redmine 側の git repository に反映される。タイムラグもないし無駄な git fetch も発生しない。ぼくは、こちらの方法を好む。
2010 年 3 月、Redmine の git による公式ミラー・リポジトリーについて書いた (Redmine の開発は Subversion で行なわれている)。
今日、サイトを見てみたら公式 git リポジトリーと hg (Mercurial) リポジトリーが載っていた。昔、紹介した git のミラー・リポジトリーも生きている様だけど、今後はこちらの方を使っておくのが良いかな。
ミラー・リポジトリーのプロジェクト・ページは以下の場所にある:
git における開発版の入手方法:
$ git clone git://github.com/redmine/redmine.git
Mercurial (hg) における開発版の入手方法:
$ hg clone https://bitbucket.org/redmine/redmine-trunk redmine
開発版に手を出したい方はどうぞ。
最近 MacPorts をアップデートしていなかった。久々にアップデートしようとしたら、make の途中でディスク容量が足りなくなった。面倒なので、ディスク内の要らないファイルを掃除して、最新版の MacPorts をクリーン・インストールした。今後のために、メモを残しておく。
旧 MacPorts は 2.0.8。2012-01-16 現在の最新版は 2.1.2。
まず、インストールしたパッケージをアンインストールする。
$ sudo port -f uninstall installed
次に、関連ライブラリーや設定ファイルを削除する。
$ rm -rf /opt/local \ /Applications/MacPorts \ /Applications/DarwinPorts \ /Library/Tcl/macports1.0 \ /Library/Tcl/darwinports1.0 \ /Library/LaunchDaemons/org.macports.* \ /Library/StartupItems/DarwinPortsStartup \ /Library/Receipts/MacPorts*.pkg \ /Library/Receipts/DarwinPorts*.pkg \ ~/.macports
MacPorts のページからリンクを辿り、Lion 用の dmg ファイルをダウンロード。ダブル・クリックで展開してインストール開始。ここいらは、他のアプリと同じなので気が楽。
MacPorts をインストールした後は、下記コマンドで最新版にアップデートする。
$ sudo port -v selfupdate
今回は MacPorts 最新版のリリースから日が経っていなかったので、アップデートする項目はなかった。
ぼくが MacPorts で必要としているのは、三つだけ。すなわち、git, ImageMagick, LaTeX。これらをインストールした。オプションは以下の通り。
$ sudo port install git-core +doc +svn
$ sudo port install ImageMagick +rsvg
$ sudo port install texlive-lang-cjk texlive-documentation-japanese
make に時間がかかったことを除けば、トラブルもなくスムーズに事が進んだ。これも、過去ログを書いておいたおかげかな。各 Port の詳細は過去ログ参照のこと。