Git の仕組みシリーズの2回目です。目次がここにあります。 前回の記事では、Git オブジェクトとリファレンスが大きなツリー構造になっていることを説明しました。 また、Git オブジェクトがどのように記録されているか、 ファイルツリーの変更がルート tree オブジェクトの ID に反映される仕組みなどを見てきました。 今回は commit オブジェクト、ブランチ、タグ、stash の仕組みについて説明します。 実際のデータが見たいときは、Git Object Browser にアクセスしてみてください。 5. commit オブジェクト 先に説明した通り、Git オブジェクトデータベースには、複数のファイルツリーを保存できます。 個々のファイルツリーは、最上位 (ルート) にある tree オブジェクトの ID で区別することができます。ファイルツリーは、大抵の場合、過去のファイルツリ

(追記) 要点を整理をした記事を書きました。こっちのほうが、余計なこと書いてない分、わかりやすいかもしれません。 はてなブックマークに、マイホットエントリーという大変すばらしい機能があって、毎日見ている。 マイホットエントリー機能のご紹介 - はてなブックマーク開発ブログ 自分のマイホットエントリーのURLはこう。 http://b.hatena.ne.jp/koseki/ マイホットエントリーを見ていると、はてなID koseki を含むリファラが各サイトに送信される。 リファラは Google アナリティクスの __utmz に記録される。 Firefox には、全クッキーの値を横断検索する機能がある。 設定 ＞ プライバシー ＞ Cookieを個別に削除 ＞ 検索 自分の環境では、およそ50個*1のクッキーに koseki という文字列が含まれていた。 あんなサイトやこんなサイトを、

gems ディレクトリの */spec/**/*_spec.rb ファイルに対して 'it .* do' を grep する。 cd ~/.rvm/gems/ruby-1.9.3-p327/gems find */spec -type f -name '*_spec.rb' | xargs grep -ho 'it .* do' | sort | uniq | lessみたいな感じ。以下のような出力が得られる。 : it "accepts a URL as the path" do it "accepts a block to change output" do it "accepts a block" do it "accepts a body" do it "accepts a class as argument with a task to invoke" do it "accept

http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html を見ながら。 URLが正規表現(A)にマッチし、かつ 文字列(B)が条件(C)を満たす場合に、 URLを(D)に書き換える。 というのが基本。 RewriteRule URLが(A)の正規表現にマッチしたら(D)で書き換える。 正規表現(A)は、リライトを実行するかどうかの条件(真偽値)であって、置換 url =~ s/(A)/(D)/ ということではない。たとえば、以下のような正規表現でリライトされる。 Google Code Search # 1文字マッチしたらリライト実行。空文字列でなければ実行する。 RewriteRule . index.php [L] Google Code Search # 先頭にマッチしたらリライト実行。常に実行する。 RewriteRule ^ -

rsync -avz --exclude-from=pattern-file --delete SRC/ DEST SRCの末尾に/をつける。たいてい必要。 SRCスラッシュの有無は、mv SRC DEST と mv SRC/* DEST の違いと一緒。スラッシュの後ろに*が省略されているものと考える。 DESTのスラッシュの有無は関係なし。 --dry-run(-n)をつけて試す。 SRC、DESTともローカルのディレクトリを指定して試す。 DESTはまず空ディレクトリで試す。DESTが同期済みだと何が更新されるのか正確にわからないので。 --list-onlyをつけてファイル一覧を得る。 DESTを省略してファイル一覧を得る。 --list-onlyと同じ？ --deleteはDESTのファイルを根こそぎ削除する可能性がある。注意。 --delete-excludedは使わない。--d

タイトル変えました。旧タイトル「JavaScriptでよく使う書き方」。よく使うけど毎回忘れる。 正規表現にマッチするかどうか。 RegExp#testを使う。 /abc/.test("abcdefg") // => true String#searchはマッチした位置を返す。マッチしない場合は-1。先頭にマッチすると0でfalseなので注意。真偽値が欲しい場合はString#searchを使わない。 "abcdefg".search(/xxx/) // => -1 "abcdefg".search(/def/) // => 3 "abcdefg".search(/abc/) == false // => true 正規表現の部分マッチを得る。 部分マッチを得るには、RegExp#execかString#matchを使う。execとmatchの速度は大して変わらない。 正規表現のベンチマー

目次 はじめに Git を使ったことがない方へ 生のデータが見たい方へ Git の全体像 .git の中身 Git オブジェクトデータベース 4種類のオブジェクト リファレンス リファレンスのリファレンス 大きなツリー Git オブジェクトの ID と 中身 ハッシュ関数 SHA1 の簡単な説明 tree と blob オブジェクト tree と blob の参照関係 ルートツリーの ID でツリー全体を識別する commit オブジェクト リファレンスとブランチ ブランチ ブランチ先頭を指すリファレンス HEAD リファレンス detached HEAD 2種類のタグ 一時待避 (stash) インデックス キャッシュとしての役割 マージ Fast-Forward マージ non Fast-Forward マージ rebase reset 2種類のブランチ 各リポジトリが自分のブランチを

テーブルのJOINが苦手でしたが、この例を思いついてからは、すっきりくっきり理解できるようになりました。むしろ頭から離れません……。 ※ INNER、OUTERは飾り。省略できる。 INNER JOIN → JOIN LEFT OUTER JOIN → LEFT JOIN RIGHT OUTER JOIN → RIGHT JOIN ※ ON ...=... をまとめて USING(属性) と書ける。 ※ 何で結合するか言うまでもない時は、NATURALを指定すると勝手にJOINしてくれる。NATURALにJOINして……。 ※ WHEREは結合した結果に作用する。 ※ 現実には上図のように1対1で結合しません。 ※ おまけ。CROSS JOIN。 こんなの使いません。 ブクマ用画像。

Apacheの設定で Order deny,allowとか Satisfy anyとか、なんだか意味わからん人のために。僕はずっとわかってなかった。 基本 Apacheのアクセス制御には、 ホストによる制御 (Order,Allow,Deny) ユーザ認証による制御 (Auth*, Require) の2通りがある。 Satisfyは、2通りあるアクセス制御の両方を満たす必要があるかどうかを決定する。デフォルトはSatisfy all。Satisfy anyなら、どちらか片方満たせばよい。 Order http://httpd.apache.org/docs/2.2/mod/mod_authz_host.html#order Order deny,allowは、全てのホストからのアクセスを許可する。 Order allow,denyは、全てのホストからのアクセスを拒否する。 Order d