間違ってremoteブランチを作ってしまったのですが、勉強になったので記事にしておきます ；P

###remoteにlocal_deployブランチを作成

shell>>
$ git push origin local_deploy #間違って作成
$ git branch -a

• master
  origin/HEAD
  origin/deploy
  origin/local_deploy #ローカルにも反映されている
  origin/master
  <<--

###remoteブランチを削除
shell>>
$ git push origin :local_deploy
<<--
これでサーバ側は反映されました。

###別のローカルリポジトリ(cloned)で削除が反映されない
しかしもう一つ別のディレクトリで同じgitリポジトリをcloneしていて、そちらで削除が反映されない状況に。

下記の1.の説明にあるように、(remoteブランチの追加は自動でされるが)削除されたものはローカルで明示的に削除しないといけないようです。

Delete unneeded branch
$ git clone git://git.kernel.org/.../git.git my.git
$ cd my.git
$ git branch -d -r origin/todo origin/html origin/man (1)
$ git branch -D test (2)

  1. Delete remote-tracking branches "todo", "html", "man". Next fetch or pull will create them again unless you configure them not to. See git-fetch(1).  
  2. Delete "test" branch even if the "master" branch (or whichever branch is currently checked out) does not have all commits from test branch. 

http://www.kernel.org/pub/software/scm/git/docs/git-branch.html

(上によると、git branch -d -r origin/removed_branchでもremoteブランチが削除できるようですね)

###コマンドgit remote show origin, git remote prune origin
git remote辺りにコマンドがあると知ったので見てみると、git remote showがありました。
確認すると、腐りかけた(Stale)tracking branchと表示されています。

shell>>
$ git remote show origin

• remote origin
  URL: ssh://git.s21g.com/mnt/git/blog.git
  Remote branch merged with 'git pull' while on branch master
  master
  Stale tracking branch (use 'git remote prune')
  local_deploy
  Tracked remote branches
  deploy master
  <<--

そして、pruneで削除。ヘルプには、--dry-runでやるとどのブランチをpruneするかレポートしてくれて、実際のactionはしない旨が記述されているのですが、私の環境では削除されてしまいました。

shell>>
$ git remote prune origin --dry-run
<<--

###Refs
http://www.kernel.org/pub/software/scm/git/docs/git-remote.html
http://www.kernel.org/pub/software/scm/git/docs/git-branch.html
http://reinh.com/blog/2008/04/18/git-push-just-the-tip.html

Gitに関するリンク集
http://blog.s21g.com/articles/548

gitをやり始めて時間が経ちますが、まだまだ知らないことばかり。
もう一度リンク集作ってみました。

###複数で開発するとき
git-pushのコツ：remoteブランチとか
http://reinh.com/blog/2008/04/18/git-push-just-the-tip.html

ブランチを使った開発の流れ
http://b.lesseverything.com/2008/3/25/got-git-howto-git-and-github

###gitリポジトリからのdeploy
CapistranoでGitを使う方法のメモ
http://blog.s21g.com/articles/807

rakeタスクからdeployする手順/ワークフロー
http://www.brynary.com/2008/8/3/our-git-deployment-workflow

###初心者にも役立つもの
Git It, Got It? Good!：pdf。これシンプルで分かりやすいと思います
http://assets.reinh.com/talks/GIT.pdf
http://reinh.com/blog/2008/02/19/git-it-got-it-good.html

Git用語Glossary
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#glossary

毎日使うgitコマンド：gitコマンドサンプルが多いのが良
http://www.kernel.org/pub/software/scm/git/docs/everyday.html

via http://ozmm.org/posts/git_post_commit_for_profit.html

gitのrefspecがよくわからなくて、調べていたら出会った記事です。

###.git/hooks/pre-commitをshellスクリプトで
shell>>
$ chmod 744 .git/hooks/pre-commit
$ cat .git/hooks/pre-commit
#!/bin/sh
rake test
<<--

こういうのもありました。
http://reinh.com/blog/2008/02/21/git-pre-commit-hook.html

shell>>
#!/bin/sh
rake spec 2> /dev/null
<<--

###.git/hooks/pre-commitをrubyで
shell>>
$ cat .git/hooks/pre-commit
#!/usr/bin/env ruby
if whoami.strip != 'deploy'
puts "You need to be deploy!"
exit 1
else
exit 0
end
<<--

###その他のhooks
.git/hooksには下記のようなファイルがあるので、preもpostもできるようです。
shell>>
post-commit
post-receive
post-update
pre-applypatch
pre-commit
pre-rebase
<<--

###pre-push hookはないのか
と思ったら、こういうパッチを書いている方がいます。パッチほとんどやったことないので、今度やってみよう。

http://kerneltrap.org/mailarchive/git/2008/8/19/2996404

札幌Ruby会議01で発表してきました
http://kakutani.com/20081025.html#p01

角谷さんの資料にあったcucumber。
サンプルがcucumberのgithubにあったのでリンク。

http://github.com/aslakhellesoy/cucumber/tree/master/examples
http://github.com/aslakhellesoy/cucumber/tree/master/examples/japanese_calculator
http://github.com/aslakhellesoy/cucumber/tree/master/examples/calculator

japanese_calculatorは角谷さん製です！

少し前にgitでのHEADが何か・どこか解決したので、リブログしておきます。

http://www8.atwiki.jp/git_jp/pub/Documentation.ja/user-manual.html#manipulating-branches

特別なシンボル "HEAD" 使用すると、常に現在のブランチを参照することができます。実際 git は .git ディレクトリにある "HEAD" という名前のファイルを使用して現在のブランチの場所を記憶しています。

shell>>
$ cat .git/HEAD
ref: refs/heads/master
<<--

追記
PDF生成が重いようなので、backgroundで処理するように変更しました。
PDFで閲覧するためには、

• 既存の記事について
  更新するとPDFが生成されます(キューに入り、生成処理終了後に記事表示するとPDF URLへのリンクが表示されます)
• 2008年10月以降の記事について
  順次PDF生成処理を行っていきますのでしばらくお待ちください
• 今後の作成される記事について
  作成・更新ごとにPDF生成されるようになっています。

gem prawn、plugin prawntoを使って実現しています。

###条件：BlueCloth形式で書かれた記事であること
書いた記事を(意図したとおりに)PDFで表示させるには、ピュアなBlueCloth形式で記述する必要があります。BlueCloth形式を選択して記述していても、HTMLタグを含む記事についてはPDFで表示した場合、HTMLタグがそのまま表示されてしまいます。

###制限：仕様

• HTMLタグは(展開されずに)そのまま表示されます
• 画像はJPG, PNGのみ(prawnの制限)
• リンクは下記のように展開されます(PDFのリンクアイテムにはなりません)
• ［title］(link先URL) => title(link先URL)
• <URL> => URL
• 太字(＊＊で囲まれたもの)は通常の文字として展開されます
• 表中の||、==は空のセルになります(マージされません)

###制限：バグ
現状下記のような制限があります。

• 長いタイトルの記事だと、タイトルが切れてしまう
• 画像が表示されない場合がある
• [math]タグを使ってのformulaの数式画像が表示されない
• その他

今さら何をという感じなのですが。自分用メモ。

###まとめ
shell>>
$ chmod 755 /home/hibi/bin
$ ls ./bin -al
drwxr-xr-x 2 hibi hibi 45 2008-09-22 10:29 .
<<--

###chmodについて：/usr/local/binで学ぶ
shell>>
drwxr-sr-x /usr/local/bin
<<--

• 最初の3文字（rw-）は所有者のアクセス権，
• 次の3文字（r--）は所有グループメンバーのアクセス権，
• 最後の3文字（r--）はその他のユーザーのアクセス権

アクセス権は「r」「w」「x」で表され，アクセス権がない場合は「-」
http://itpro.nikkeibp.co.jp/article/COLUMN/20080617/308467/?ST=develop&P=3

さらに、

• r 4 読みだし可
• w 2 書き込み可
• x 1 実行可能

http://www.k-tanaka.net/unix/chmod.html

[追記 2008.11.12]
sshの鍵設定していたら、参考になりそうなものを見つけました

• 所有者のみrwx .ssh ディレクトリー(0700)
• 所有者のみrw 秘密キー(0600)
• 所有者rw それ以外はr 公開キー(0644)

http://www.gadgety.net/shin/tips/unix/ssh2.html

[追記おわり]

ちなみにsはセットIDというものらしく

SetUIDを設定していると，そのプログラムのプロセスのUIDは，所有者になります。SetUIDを設定する場合は
shell>>
$ chmod u+s samplepgm
<<--
http://itpro.nikkeibp.co.jp/article/Keyword/20070405/267555/

他にもg+s, o+sがあるそうです。

###Refs
http://www.k-tanaka.net/unix/chmod.html
http://itpro.nikkeibp.co.jp/article/COLUMN/20080617/308467/?ST=develop&P=3

git-pullで私なりの解釈で aha！が来たのでメモします。
これからは git-pull --rebaseにしよー
下記をそのままという感じなのですがｗ
http://www8.atwiki.jp/git_jp/pub/Documentation.ja/user-manual.html#using-git-rebase

###そういえばトッポさんが言ってた：git-pull --rebaseを使うといいよ
git-pullよりgit-pull --rebaseを使うといいよ(ただしという注意(下記太字)があるのでその辺は注意。ほとんどの人は関係ないと思うんだけど。。。)

Here's a tip for keeping up to date: In lieu of using git pull to download the latest changes, use git pull --rebase. Instead of cluttering the history with a merge commit, it reapplies your changes to the latest upstream. The only caveat is that you shouldn't use this method if you've already published the changes to another repository. Doing so would cause problems for anyone who has already downloaded the original commits.
http://www.tpope.net/rails-git-best-practices

でgit-pullとgit-pull --rebaseの違いをgit-rebaseの説明を読んで理解する

###状況
o--o--O--o--o--o <-- origin
         \
         a--b--c <-- mywork

"mywork"は"origin" から単純に並行に行なわれています
プロジェクトの上流では他の興味深い変更が行なわれ、 "origin" は発展します

###で、(上の状況から)git-pullした場合
o--o--O--o--o--o <-- origin
         \          \
         a--b--c--m <-- mywork

"pull" を使用して変更をマージさせることができます；結果として新しいマージコミットが生成されます

###で、(上の状況から)git-pull --rebaseした場合
originが最新であればgit rebase originでいいと思うのだけど、(originが)最新でない場合はgit-pull --rebaseすればいいのだと解釈しました。

o--o--O--o--o--o <-- origin
                      \
                      a'--b'--c' <-- mywork

これは、mywork からあなたの各コミットを削除し、一時的に (".dotest" という名前のディレクトリ内に)パッチとして保存し、 mywork を origin の最新バージョンの位置に更新し、その後で保存した各パッチを新しい mywork ブランチに適用します。

コンフリクトがある場合は、下記にあるように修正してaddしてgit rebase --continueすればok。

###各git-somethingでのコンフリクト時のリカバリ

• git merge 時のリカバリ

      o 手動マージ -> 動作確認 -> add -> commit  

• git rebase 時のリカバリ

      o 手動マージ -> add -> git rebase --continue  

• git pull 時のリカバリ

      o メンテナの場合 -> 一蹴  
      o ユーザの場合 -> 手動マージ -> add -> commit  

• git-am 時のリカバリ ( apply mail = メールで送られるパッチの適用 )

      o メンテナの場合 -> 一蹴    
      o ユーザの場合 -> 手動マージ -> add -> git-am --resolved  

http://d.hatena.ne.jp/conceal-rs/20080928/1222612534

###Refs
http://www8.atwiki.jp/git_jp/pub/Documentation.ja/user-manual.html#using-git-rebase
http://www.tpope.net/rails-git-best-practices
http://blog.s21g.com/articles/535:tpope.netさんのRails with Gitのためのベストプラクティス
http://d.hatena.ne.jp/conceal-rs/20080928/1222612534：gitでの開発の流れがわかってかなり++

自分用メモ。
screenでは複数windowを開いていますが、最近なんとなく開く数が決まってきたので、最初から開いておくようにしました。瀧内さんは以前8つ開いてるって言ってたので(!)、私の6つなんか かわいいものなハズ。

###windowの役割
現在のメインプロジェクトはブログなので、それをベースに以下の5つを開いています。

• 0 emacs, エディタ
• 1 shell
• 2 tail -f log/development.log
• 3 script/console
• 4 同時進行のプロジェクト： folked prawn.git
• 5 railsのdir ソースを読むのに使う

###2008.10.03の.screenrc
他の人よりはショボショボなのですが、ご愛敬ということで。
emacsclientを使っているので、emacsはフルパスで書いています。

rails>>
escape ^tt

hardstatus alwayslastline "[%02c] %`%-w%{=b bw}%n %t%{-}%+w"
scrollback 4000
vbell off
#idle 1200
#blankerprg /usr/local/bin/tss

chdir "/home/hibi/blog.git" #メインのprojectに移動

#screen -t emacs 0 /usr/bin/emacs #emacs 21.4
screen -t emacs 0 /usr/local/bin/emacs
screen -t bash 1
stuff "ruby ./script/server -d" #開いたwindowにこのコマンドだけ入力しとく、実行してもいいのですが実行したくない時も多いので

screen -t tail 2 tail -f log/development.log

screen -t console 3 ruby ./script/console

chdir "/home/hibi/my.prawn.git"
screen -t prawn 4 #前の行でcdしてからwindowを開く

chdir "/home/hibi/test/vendor/rails/actionpack/lib/action_controller"
screen -t rails 5

chdir "/home/hibi/blog.git" #以後開くすべてのwindowをblog.gitにするため
select 1 #window1を選択
<<--

###Refs
http://www.limy.org/program/screen_command.html：日本語リファレンス
http://www.pervasivecode.com/blog/2007/06/12/gnu-screen-and-my-screenrc/
http://technique.sonots.com/?UNIX/設定、設定ファイル/.screenrc

できた(というか切り出してきた)gemspec
http://github.com/satoko/prawn/tree/master/prawn.gemspec

forkしているprawnにはprawn.gemspecファイルがありません。
で、自分で適当にでっち上げようとしたのですが、どうやらgemspec(spec.files)の内容が正しくない様子で、動作するgemが作れません。いちいち使用するすべてのファイルを上げなければいけないのだけれど、どうしたら簡単にできるものか...と思ったら、project内のRakefileにgemspecがあった！というので、それを切りだしました。
そこに至るまでのポイントぽいものを挙げます。

###gemspecで重要な属性

Important Attributes
name .. version .. platform .. summary .. require_paths .. files .. dependencies
http://docs.rubygems.org/read/chapter/20

###spec.fileの便利な書き方:Dir.blog
(注意)githubの場合Dir.globはgem生成時にエラーになるようで(エラー通知メールが来てた)、irbでDir.blogして展開したものをgemspecにコピペするのが正解のようです。

shell>>
irb(main):001:0> Dir.glob("{examples,lib,spec,vendor,data}///*")
<<--

結果をspec.filesにコピペ。

rails>>
Gem::Specification.new do |spec|
spec.name = "prawn"
spec.files = ["copy & past the result of Dir.blog"] +
["Rakefile"]
<<--

###gemspecでローカルで正しいgemが作れるかテストする
下記のコマンドで生成されたgemをインストールし、展開後のdirを見たりテストを実行したりして正しくgemが作られているかテストします。

shell>>
$ gem build prawn.gemspec
<<--

###githubでgems.githum.comの一覧に入れてもらう手順

1. prawn.gemspecというファイルを用意する
2. コミット
   shell>>
   git push prawn.gemspec -m "add gemspec file"
   <<--
3. https://github.com/satoko/prawn/editでRubyGemにチェックする
4. gem searchで所望のgemが出てくるのを待つ(max 15分くらい？)
   shell>>
   $ gem search satoko-prawn -r
   *** REMOTE GEMS ***
   satoko-prawn (0.2.99.2)
   <<--

(注意)一覧とはここです。

###Refs
http://d.hatena.ne.jp/akm/20080621#1214036969
http://docs.rubygems.org/read/chapter/20
http://code.google.com/p/rubeus/source/browse/trunk/rubeus.gemspec#