コミットはスナップショットであり差分ではない
Git は紛らわしいという評判です。用語や言い回しが意味するものと、そこから想像する挙動が違ってユーザーが混乱すると言われます。これは、git cherry-pick や git rebase のような「履歴を書き換える」コマンドに最も顕著です。私の経験では、この混乱の根本的な原因は、コミットは 差分 であり順番を入れ替えることができるという解釈にあります。しかし、コミットはスナップショットであって、差分ではありません! Git がリポジトリデータをどのように保存しているかを見てみると、Git を理解しやすくなります。このモデルを調べた後に、この新しい視点が git cherry-pick や git rebase のようなコマンドを理解するのにどのように役立つのかを探っていきます。 本当に深く 掘り下げたいのであれば、Pro Git という書籍の Git Internals の章を読むと
人生を豊かにする文字列diff入門 | フューチャー技術ブログ
春の入門祭りの8日目です。 文字列の新旧の違いを表現する時によくdiffをとるとか言いますよね。そこで実行されるのが差分アルゴリズムです。差分のアルゴリズムって結構知れば知るほど難しいやつです。「より良い差分」という基準が、状況によって変わるからです。ヒューリスティックなやつです。例えば、HTMLの説明の文章を書いていたとします。タイトルをテーブルに書き換えてみたとします。 どちらも間違ってはおらず、この差分を元にパッチを当てたりも可能です。ただ、読んだ時の読みやすさが違います。 これはもちろん前者と答える人の方が多いでしょう。だって、タグという意味の塊が維持されていますからね。 これは究極的にはわかりやすいdiffというのは「意味」を理解しないと作れないということを意味します。これがdiffは簡単なようで難しいと書いた理由です。もちろん、ほどほどの工数で、ほどほどの見た目のdiffも作成
バイナリファイルの差分を作るzdeltaが便利 - kanblr
去年のネタになってしまうんですが、ある程度でかく、かつ都度更新され続けるファイルの転送量を削減したいなーということになって、ちょっとずつ更新されてるなら実は差分は小さいんじゃね?ということで、バイナリのdiffをとって転送先でpatchをあてる、みたいなことが出来ないかなーと調べてました。 バイナリ差分生成系で一番ポピュラーなのはxdeltaのようで実際yumやaptで簡単に入れられるし、プロジェクトとしても更新が続いててドキュメントも揃っててなかなか良さげ。一方で bsdiffとxdeltaを比較してみた という記事で紹介されている bsdiff というのもあって、Google Chromeのアップデートとかでも使われたりしている模様(chromeの差分アップデートでは更に逆アセンブルした結果を差分アップデートしたりとか変態的なことやってるようですが)。 比較してみると、確かに bsdi
どこでも使える git diff と git apply - Qiita
Git Advent Calendar / Jun. 28日目の記事です。27日目はつるはしで過去を発掘するでした。 Git リポジトリの外で git diff / git apply あまり知られていないことですが、 git diff と git apply は Git リポジトリの外でも使えます。普通の diff ではできない、バイナリファイルを含む2つのディレクトリの差分を取りたいときなどに重宝します。ちょっと試してみましょう。 $ mkdir dir1 dir2 $ echo foo > dir1/text $ echo FOO > dir2/text $ dd if=/dev/random of=dir1/binary bs=128 count=1 $ dd if=/dev/random of=dir2/binary bs=128 count=1
普通のpatchコマンドで取り込めるdiffファイルをgitで作成する - kanonji’s diary
まとめ $ git diff --no-prefix HEAD~ > thisis.patch $ patch --dry-run -p0 < thisis.patch $ patch -p0 < thisis.patch git diffに--no-prefixをつける事で、普通のpatchで当てられるパッチファイルを出力できます。この例ではHEADの1個前*1からHEAD*2までのパッチです。 普通のpatchコマンドのほうの知識があまり無くて-p0がいまいちよく分からないんですが、git diff --no-prefixで作成したパッチファイルを当てるには必要みたいです。--dry-runは、実際には当てないけど当てた場合の結果を出力します。なので、まずは--dry-runで確認して、問題が無ければ実際にパッチを当てます。 エントリー書いた後に教えてもらった補足 patch -p1の
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
git-flowは死んだ
