• 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31

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

remoteにlocal_deployブランチを作成

   1  $ git push origin local_deploy  #間違って作成
   2  $ git branch -a
   3  * master
   4    origin/HEAD
   5    origin/deploy
   6    origin/local_deploy #ローカルにも反映されている
   7    origin/master

remoteブランチを削除

   1  $ 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と表示されています。

   1  $ git remote show origin
   2  * remote origin
   3    URL: ssh://git.s21g.com/mnt/git/blog.git
   4    Remote branch merged with 'git pull' while on branch master
   5      master
   6    Stale tracking branch (use 'git remote prune')
   7      local_deploy
   8    Tracked remote branches
   9      deploy master

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

   1  $ 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

posted by Png satoko on Fri 31 Oct 2008 at 12:51

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

posted by Png satoko on Thu 30 Oct 2008 at 17:05

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

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

.git/hooks/pre-commitをshellスクリプトで

   1  $ chmod 744 .git/hooks/pre-commit
   2  $ cat .git/hooks/pre-commit 
   3  #!/bin/sh
   4  rake test

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

   1  #!/bin/sh
   2  rake spec 2> /dev/null

.git/hooks/pre-commitをrubyで

   1  $ cat .git/hooks/pre-commit
   2  #!/usr/bin/env ruby
   3  if `whoami`.strip != 'deploy'
   4    puts "You need to be `deploy`!" 
   5    exit 1
   6  else
   7    exit 0
   8  end

その他のhooks

.git/hooksには下記のようなファイルがあるので、preもpostもできるようです。

   1  post-commit                        
   2  post-receive
   3  post-update                        
   4  pre-applypatch
   5  pre-commit                         
   6  pre-rebase

pre-push hookはないのか

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

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

posted by Png satoko on Thu 30 Oct 2008 at 16:34

札幌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は角谷さん製です!

posted by Png satoko on Mon 27 Oct 2008 at 13:24

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

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

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

   1  $ cat .git/HEAD
   2  ref: refs/heads/master

posted by Png satoko on Mon 27 Oct 2008 at 12:09

追記 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の数式画像が表示されない
  • その他
posted by Png satoko on Wed 22 Oct 2008 at 11:31

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

まとめ

   1  $ chmod 755 /home/hibi/bin
   2  $ ls ./bin -al
   3  drwxr-xr-x  2 hibi hibi   45 2008-09-22 10:29 .

chmodについて:/usr/local/binで学ぶ

   1  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の鍵設定していたら、参考になりそうなものを見つけました

[追記おわり]

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

SetUIDを設定していると,そのプログラムのプロセスのUIDは,所有者になります。SetUIDを設定する場合は

   1  $ 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

posted by Png satoko on Tue 7 Oct 2008 at 11:51

git-pullで私なりの解釈で aha!が来たのでメモします。
これからは git-pull --rebaseにしよー
下記をそのままという感じなのですがw
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での開発の流れがわかってかなり++

posted by Png satoko on Fri 3 Oct 2008 at 17:43

自分用メモ。
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はフルパスで書いています。

   1  escape ^tt
   2  
   3  hardstatus alwayslastline "[%02c] %`%-w%{=b bw}%n %t%{-}%+w"
   4  scrollback 4000
   5  vbell off
   6  #idle 1200
   7  #blankerprg /usr/local/bin/tss
   8  
   9  chdir "/home/hibi/blog.git" #メインのprojectに移動
  10  
  11  #screen -t emacs 0 /usr/bin/emacs #emacs 21.4
  12  screen -t emacs 0 /usr/local/bin/emacs
  13  screen -t bash 1
  14  stuff "ruby ./script/server -d" #開いたwindowにこのコマンドだけ入力しとく、実行してもいいのですが実行したくない時も多いので
  15  
  16  screen -t tail 2 tail -f log/development.log
  17  
  18  screen -t console 3 ruby ./script/console
  19  
  20  chdir "/home/hibi/my.prawn.git"
  21  screen -t prawn 4 #前の行でcdしてからwindowを開く
  22  
  23  chdir "/home/hibi/test/vendor/rails/actionpack/lib/action_controller"
  24  screen -t rails 5
  25  
  26  chdir "/home/hibi/blog.git" #以後開くすべてのwindowをblog.gitにするため
  27  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

posted by Png satoko on Fri 3 Oct 2008 at 15:48

できた(というか切り出してきた)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にコピペするのが正解のようです。

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

結果をspec.filesにコピペ。

   1  Gem::Specification.new do |spec|
   2    spec.name = "prawn"
   3    spec.files = ["copy & past the result of Dir.blog"]  +
   4                        ["Rakefile"]

gemspecでローカルで正しいgemが作れるかテストする

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

   1  $ gem build prawn.gemspec

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

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

posted by Png satoko on Thu 2 Oct 2008 at 10:09 with 1 comment
Contents
[git] 削除されたremoteブランチがローカルRepoで消えなくなったとき
Gitに関するリンク集その2
.git/hooks/pre-commitでコミット前にrake testしよう
gem cucumberの使い方例・サンプル リンク
gitのHEADとは、現在のブランチのこと
s21gブログの記事がPDFで閲覧できるようになりました
/home/hibi/binの権限設定:chmod 755
git-pull、git-pull --rebaseをめぐる冒険+コンフリクトした場合の作業
my .screenrc: chdir(cd)したり、stuffしたり
gemspecファイルの書き方
Comments
KingofSmack: Here also good reads for this mobile applicatio... '14-5
satoko: stackoverflowでも同じエラーを挙げている人がいたので、1.3でアップロードしたよっ... '10-12
ujihisa: :%s/blog/glob/g '10-7
satoko: しゅが〜様 返事が遅くなって申し訳ありません。また、投稿百景ご購入ありがとうございます。 ... '09-10
しゅが~: こんにちは。投稿百景を発売日翌日から利用しています。本当にいいAppを作っていただきました。罫... '09-10
Services from s21g
twpro(ツイプロ)
Twitterプロフィールを快適検索
地価2009
土地の値段を調べてみよう
MyRestaurant
自分だけのレストラン手帳
Formula
ブログに数式を埋め込める数式コミュニティ