Git の仕組み (2) - コミット・ブランチ・タグ - こせきの技術日記
Git の仕組みシリーズの2回目です。目次がここにあります。 前回の記事では、Git オブジェクトとリファレンスが大きなツリー構造になっていることを説明しました。 また、Git オブジェクトがどのように記録されているか、 ファイルツリーの変更がルート tree オブジェクトの ID に反映される仕組みなどを見てきました。 今回は commit オブジェクト、ブランチ、タグ、stash の仕組みについて説明します。 実際のデータが見たいときは、Git Object Browser にアクセスしてみてください。 5. commit オブジェクト 先に説明した通り、Git オブジェクトデータベースには、複数のファイルツリーを保存できます。 個々のファイルツリーは、最上位 (ルート) にある tree オブジェクトの ID で区別することができます。ファイルツリーは、大抵の場合、過去のファイルツリ
Git の仕組み (1) - こせきの技術日記
目次 はじめに 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種類のブランチ 各リポジトリが自分のブランチを
Vagrant を使って Mac からダブルクリックで操作できる仮想環境を作る - こせきの技術日記
この記事を公開する直前に Vagrant Cloud がはてブに上がってるのを見て、今あわてて追記しています。すごい楽しいことになってますねー。 Vagrant Cloud Vagrant 1.5 and Vagrant Cloud - Vagrant ブログ記事をざっと読んだ感じだと、Vagrant 1.5 の新機能は、 VagrantShare - まるで公開されてるサイトみたいに VM の URL をチームメンバーに見せる Box を koseki/centos みたいな短い名前で指定できるように。バージョン管理 rsync と SMB でフォルダ同期 Hyper-V - MS の仮想環境に対応 insecure-private-key の代わりに SSH でパスワードが使えるように プラグイン管理 Funtoo, NetBSD, TinyCore Linux のゲストに対応。ネット
最近変更されたファイルをtailで表示する。 - こせきの技術日記
ファイル名をワイルドカードで指定して、一番最近変更されたファイルをtailで表示する。 ls -t /path/to/prefix-*.log | head -1 | xargs tail -f ls -t /path/to/prefix-*.log | head -1 | xargs lessお好みで tail -f $(ls -t /path/to/prefix-*.log | head -1) less $(ls -t /path/to/prefix-*.log | head -1)ls -t でタイムスタンプ順。 (追記) システム管理に使えるファイル更新監視テク - 技術メモ帳 カレントディレクトリの更新ファイルを2行ずつ監視。 watch -n2 'tail -n2 `ls -t`'
Apacheのアクセス制御をちゃんと理解する。 - こせきの技術日記
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
地雷だらけのrsyncを理解する。 - こせきの技術日記
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
GPLメモ - こせきの技術日記
配布とソースコード GPLの派生物を渡した相手が希望するなら、ソースコードを渡さなければならない。 不特定多数にソースを公開する義務はない。 AさんがBさんにGPLのソースから作ったバイナリを渡すとき、Bさんに要求されたらソースも渡さなければならない。 BさんがAさんから受け取ったバイナリを100人に売ったとき、その100人に要求されたらソースも渡さなければならない。 顧客の100人がバイナリを購入せず、BさんやAさんにソースを要求しても渡す必要はない。 オープンソースで行こう！: 第2回 オープンソースライセンス事情を俯瞰する 「特にGPLのソフトウェアをビジネス用途などで第三者に販売・提供する場合、その第三者からソースコードの開示要求があればそれに応じなければなりません」 ソースを渡した相手に、再配布を許可しなければならない。 渡された相手が「再配布しなければならない」わけではない。
地獄のようによくわかるSQLテーブル結合 - こせきの技術日記
テーブルの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。 こんなの使いません。 ブクマ用画像。
実行中のアプリケーションを外から観察するコマンド。 - こせきの技術日記
strace システムコールをトレース。カーネルと何を話しているか。 strace -p PID でプロセスにアタッチ。実行中のプロセスをトレース。 straceを使ったデバッグ - SourceForge.JP Magazine : オープンソースの話題満載 Linuxカーネルの作り出す世界 − ＠IT自分戦略研究所 - ふつうのLinuxプログラミング 青木峰郎 システムコールとライブラリ関数 − ＠IT自分戦略研究所 システムコール・ライブラリルーチン - UNIX の部屋 ltrace 共有ライブラリの呼び出しをトレース。*.soと何を話しているか。 ltrace -p PID でプロセスにアタッチ。実行中のプロセスをトレース。 ltrace で共有ライブラリの関数呼び出しをトレースする - bkブログ 404 - エラー: 404 - Linux JF ƒ‰ƒCƒuƒ‰ƒŠ‚ÌŠ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
