コミットはスナップショットであり差分ではない
Git は紛らわしいという評判です。用語や言い回しが意味するものと、そこから想像する挙動が違ってユーザーが混乱すると言われます。これは、git cherry-pick や git rebase のような「履歴を書き換える」コマンドに最も顕著です。私の経験では、この混乱の根本的な原因は、コミットは 差分 であり順番を入れ替えることができるという解釈にあります。しかし、コミットはスナップショットであって、差分ではありません! Git がリポジトリデータをどのように保存しているかを見てみると、Git を理解しやすくなります。このモデルを調べた後に、この新しい視点が git cherry-pick や git rebase のようなコマンドを理解するのにどのように役立つのかを探っていきます。 本当に深く 掘り下げたいのであれば、Pro Git という書籍の Git Internals の章を読むと
Gitはどうやってテキストファイルとバイナリファイルを自動識別しているのか？ - Qiita
tl;dr 先頭 8000 バイト以内に NUL が有ったらバイナリファイル。 Gitの実装 Gitの内蔵diffは FIRST_FEW_BYTES だけ検索するようになっている。 https://github.com/git/git/blob/6e0cc6776106079ed4efa0cc9abace4107657abf/xdiff-interface.c#L187 #define FIRST_FEW_BYTES 8000 int buffer_is_binary(const char *ptr, unsigned long size) { if (FIRST_FEW_BYTES < size) size = FIRST_FEW_BYTES; return !!memchr(ptr, 0, size); }
Linuxの開発者であるLinus Torvalds氏がGitHub上でプルリクエストを受け付けない理由 | スラド Linux
ストーリー by hylom 2016年11月29日 21時01分 少なくともGitHubのみに依存しないのは正しいと思う 部門より Redditで「This is why Linus doesn't accept PRs from GitHub」（LinusがGitHubからのプルリクエストを受け付けない理由がこれだ）という画像が話題になっている。 ここで言われている「Linus」は、もちろんLinuxの開発者であるLinus Torvalds氏。この画像は、GitHub上のLinuxのリポジトリに対する「Delete duplicate word "long long" in Introduction」（イントロダクション中でダブっている「long long」という単語を削除）いうプルリクエスト。これに対し、ほかの開発者からが「long long」は単語がダブってるわけではなくそういう
git-reviewer 書いた - その手の平は尻もつかめるさ
code review の reviewer 選出をする時，pull request の内容をざっと眺めてから「この部分だから XX さんかな」とか「あそこのコードは YY さんが詳しいだろう」とか，そういう感じで選ぶことが多くて，つまりは勘と経験で選びがちになってしまう．これについては常々いくばくかの危うさを感じていた． そもそも，「reviewer として誰が最適か」という知識はプロジェクトに長く関わっている人でなければ知りにくいものであり，いわば属人的な知識のひとつだと思っている．プロジェクトからそういった長老的な人がいなくなってしまったら，最適な code review を実施できなくなってしまう可能性がある． 従って，やはり技術で解決ということになる． Facebook が作っている mention-bot という GitHub の bot として動作するやつがあって，これは p
プルリクエストをより使いこなす | POSTD
Gitを使用している人であれば、プルリクエストには馴染みがあるでしょう。これは、分散バージョン管理システムが世に出始めてから、何らかの形で使われています。BitbucketやGitHubのように凝ったWebユーザインターフェイスが構築される前は、プルリクエストは単純に電子メールベースで行われており、Aliceのリポジトリから変更をプルするように依頼していました。プルリクエストを受けた側がこの変更を妥当だと判断すれば、いくつかのコマンドを実行しmasterブランチに変更をプルするという流れです。 $ git remote add alice git://bitbucket.org/alice/bleak.git $ git checkout master $ git pull alice master もちろん、手あたり次第Aliceの変更をmasterにプルすることは、 得策 ではありませ
icdiff: side-by-side highlighted command line diffs
Your terminal can display color, but most diff tools don't make good use of it. By highlighting changes, icdiff can show you the differences between similar files without getting in the way. This is especially helpful for identifying and understanding small changes within existing lines. Instead of trying to be a diff replacement for all circumstances, the goal of icdiff is to be a tool you can re
git difftool --dir-diff が便利すぎて泣きそうです
Git の 1.7.11 から git difftool コマンドに --dir-diff というオプションが追加されたのですが、これがライフ チェンジングだと思ったので紹介します。 --dir-diff 登場以前の git difftool は「ファイルごとに順番に差分を表示していく」ことしかできず、使い勝手はいまいちでした。それが、--dir-diff オプションの登場で状況が一変したわけです。 こんな感じの使い心地だよ ある Git レポジトリーで dir1/a.txt と dir2/c.txt を編集したとしましょう。 この状態で git difftool --dir-diff または git difftool -d を実行してみると・・・。 はい、差分のあるファイルが一覧で表示されました。 (difftool に WinMerge を設定して、メニューから [ツリー表示] を有効
テキストでないファイルのdiff（差分）をとる方法 - ザリガニが見ていた...。
AppleScriptはスクリプト言語なんだけど、ファイルに保存するときはAppleScript形式にコンパイル（変換）される。その結果、AppleScriptエディタでは人間が理解できるコードに見えるのに、普通のテキストエディタで開くとこんな状態。 その実態は、AppleScript独自のバイナリファイルなのだ。バイナリファイルの痛いところは、diffを実行してもそのままでは差分がとれないこと。どうしても差分をとりたいと思うのなら、いったんAppleScriptファイルを開いて、テキストファイルとして保存したファイルに対してdiffを実行するしかない。 しかし、それでは手間がかかりすぎる。手軽にdiffできないと、いずれ使わなくなる。そんな訳で「AppleScriptはバイナリファイルなのだから、しょうがない」と以前から諦めていたところがあった。（Gitのあの素晴らしい仕組みを知るまでは
どこでも使える 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
リーダブルコードの解説 - 2012-06-11 - ククログ
注: 記事中の「解説」の部分のライセンスは「Creative Commons 表示 - 非営利 - 継承」です。「解説」は「クリアコード」（「ClearCode Inc.」）によって変更されています。変更前の原著作者は「オライリー・ジャパン」です。「Creative Commons 表示 - 非営利 - 継承」なので再配布や変更や翻訳などはライセンスに従って自由に行えますが、営利目的で利用することはできません。 https://amazon.co.jp/dp/B0064CZ1XEの翻訳である「リーダブルコード」が今月（2012年6月23日）発売されます。すでに予約できるようです。 https://amazon.co.jp/dp/4873115655 本書の内容は原書の紹介記事を参照してください。 日本語版の訳者は角さんです。これまでの訳書と同様にとても読みやすく訳されています。翻訳なので読
クリアなコードの作り方: 意図が伝わるコミットのしかた - 2012-03-13 - ククログ
コミットメッセージの書き方ではコミットをわかりやすくするためには以下の2つの条件を満たす必要があると書きました。 コミットの内容が分かりやすく説明されていること コミットの内容が小さくまとまっていること このうち「コミットの内容が分かりやすく説明されていること」についてはすでに説明済みです。今回は「コミットの内容が小さくまとまっていること」について説明します。 めざすところ 単純にコミットの内容を小さくするだけではわかりやすくなりません。それでは、どのような基準で小さくすればよいのでしょうか。 よく言われることは1つのコミットには1つの小さな論理的にまとまった変更だけにする、というものです。たしかにこれは重要です。しかし、これだけを基準とすると、人によっては大きめなコミットになってしまいます。人それぞれで論理的なまとまりの大きさが異なるからです。 1つのコミットでどうすればよいかを考えるの
Vim で Git diff の出力からカーソル下にある変更箇所へ移動する | Webシステム開発／教育ソリューションのタイムインターメディア
問題 パッチのレビューなどでGitの diff の出力を読む機会はそれなりにあると思います。 その際、 diff で列挙されている内容だけでなく前後のコードも確認するために変更のあったファイルを開くことも多々あるでしょう。 Vimにはこの状況にぴったりのコマンドgfがあります。 gf はカーソル下にあるテキストからファイル名らしき文字列を探してそれを開くというコマンドです。 diff の出力には変更のあったファイルのパスが含まれていますから、 そこへカーソルを移動して gf を使えば良いというわけです。 gf はとても便利なコマンドではあるものの、 上記の操作を何度か行っていると不満が募ってきます。 というのも、以下のような手間があるからです: gf を実行するためにパスの書かれている位置までカーソルを移動しなければならない。gf でファイルを開いた後、レビューしたい場所までカーソルを移動
致命的すぎるバグがgithubで話題
github上で公開されているグラフィックドライバのbumblebeeで見つかったバグ修正のコミットが話題になっています。インストールスクリプト内にあってはならないスペースがあり、インストールを実行すると /usr を根こそぎ削除するという悲惨なバグです。（しかもインストールはrootでしか行えない) このバグ修正のコミットはさながら掲示板の様に盛り上がっており、いろいろなネタ画像も貼られています。 「普段はbumblebeeをインストールしないけど、 インストールしたら /usr フォルダを削除しやがったぜ」 「我らの命を奪うことはできても、我々の/usr は決して奪えない」 「僕たちは宇宙を守るために君たちの /usr のエントロピーが必要なんだ」 githubが開発者向けのツールであると同時にコミュニティとして発展している事を伺わせる一コマです。とはいえbumblebeeをインストー
gitでインデント量以外の変更点を表示する | Webシステム開発／教育ソリューションのタイムインターメディア
問題 バグフィックスなりリファクタリングなり何かをするため、 コード中の複数のブロックのインデントを変更するということは少なくありません。 例えば以下のようなコードがあるとしましょう: private void UpdateData() { var db = GetDatabaseConnection(); data1.UpdateSomething(); data2.UpdateSomething(); data3.UpdateSomething(); data1.Save(db); data2.Save(db); data3.Save(db); } このコードは一連のデータを更新してデータベースに保存しています。 しかしこの手の更新はデータの一貫性を保証するためにトランザクション内で実行されなければなりません。 という訳でこのコードは以下のように修正されるべきです: private v
普通の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の
Vimのgfコマンドをgit diff特有の出力でも上手く扱うようにする | Webシステム開発／教育ソリューションのタイムインターメディア
問題 八百万あるVimのコマンドで特に有用なもののひとつとしてgfがあります。 このコマンドはカーソル下にあるファイル名らしき文字列を探し、 該当するファイルがあればそれを開くというものです。 gf はカーソル下にあるファイル名らしき文字列をそのまま使うだけでなく、 特定のディレクトリ下にあるかどうか検索(例えばC言語でなら /usr/include や ./include を検索)したり、 特定の拡張子を付加して検索(例えばJavaなら SomeClass のファイル名は SomeClass.java なので、 .java を付加して検索)することができ、 そこそこ賢く動いてくれます。 さて、日常的に git を使っている身としては 日常的に git diff の出力を眺める機会も多いです。 「git diff の出力を眺めて変更のあったファイルを開く」ということも頻繁に行います。 これ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - lambdalisue/vim-unified-diff: A plugin for using unified diff in vimdiff
git-flowは死んだ