コミットはスナップショットであり差分ではない

Git は紛らわしいという評判です。用語や言い回しが意味するものと、そこから想像する挙動が違ってユーザーが混乱すると言われます。これは、git cherry-pick や git rebase のような「履歴を書き換える」コマンドに最も顕著です。私の経験では、この混乱の根本的な原因は、コミットは 差分 であり順番を入れ替えることができるという解釈にあります。しかし、コミットはスナップショットであって、差分ではありません! Git がリポジトリデータをどのように保存しているかを見てみると、Git を理解しやすくなります。このモデルを調べた後に、この新しい視点が git cherry-pick や git rebase のようなコマンドを理解するのにどのように役立つのかを探っていきます。 本当に深く 掘り下げたいのであれば、Pro Git という書籍の Git Internals の章を読むと

[shinp]

スナップショットゆうてもコミット一つのデータが全データのスナップショットを持ってない以上結局ユーザーからはコミットは差分として振る舞われるので内部的な違いは大して意味なくない？　言葉遊びじゃねーの。

[aobon700]

ぜんぜんわからない。俺たちは雰囲気でgitを使っている。

[jgoamakf]

コマンドの名前がCVS/Subversionを引きずってるのと、ユーザーのメンタルモデルと内部表現に差があるのが分かりにくさの原因なのではと考えているが……

[programmablekinoko]

もともとLinusがLinux開発で開発者ごとのpatchの大量の送付と適用にキレて作ったので、そのコミット時点のファイルをすべて保持する方式 / 差分と誤解するのはgithubとかの集中型のリポジトリサービスが主流になったからだよ

[a-kuma3]

個人的に紛らわしいのはふたつで、checkout の命名と、branch がポインタと理解できるか、ってとこだと思ってる。過去のある一点からブランチを切りたい、って思ったときに「ポインタ」は理解できるはず

[june29]

ぼくの頭の中ではパッチに近いものとして理解を組み立てているように思う。スナップショットというのは今のところピンときていない。

[kobito19]

"これは、git cherry-pick や git rebase のような「履歴を書き換える」コマンドに最も顕著です。"いやcherry-pickは歴史は書き換えんやろ？

[Kesin]

この記事はPartial Clone, Shallow Cloneの話につながる三部作の一部目の日本語訳らしい

[devorgachem]

コミットが全データを持ってないのトップコメ、なんのデータを持ってないとの主張だろう。コミットの実体には、ファイルとディレクトリの一意なIDが書かれてるわけで一意なスナップショットを復元できるはずだが

[yorkfield]

トップコメントの"コミット一つのデータが全データのスナップショットを持ってない"って、どこからそんな解釈が出るんだ……。「コミット一つのデータ」で想像してる物がたぶん違うんだろうな。

[naga_sawa]

内側の実現方式がハッシュで繋いだスナップショットなんだけれどもユーザはdiffとか使っていくので差分累積に見えてしまうという/同じネタを昔やった記憶→ https://b.hatena.ne.jp/entry/s/qiita.com/kaityo256/items/81e7951a1ca2706955a4

[tmatsuu]

cherry-pickでハッシュ値が変わったり、--depth=1で最新を取得できたりするのはなぜか、などの出発点があるのかなとか思ったけども。

[rikuba]

「このアルゴリズムは A * D 回差分計算します。ここで A は追加されたファイルの数で、 D は削除されたファイルの数です。」

[momontyo]

リネーム追跡はやっぱ推測でしかないのね。 複数ファイルの追加削除を同時にした時に、どうしてもリネーム扱いにされて嫌な思いしたこと思いだす。

[tx198]

コミットに全スナップショットが入ってるだろ。 入ってないなんて、どうしてそう思ったのか聞きたいです。 コミットハッシュに全てがあると思うけど。わからん。

[ngmy]

差分と捉えるかスナップショットと捉えるかで使っていて混乱することなんてある？モデルから使い方を推測して使うとそうなるのか？（ドキュメントを読め）

[n314]

効率の良い何かすごいことをしてるかと思いきや、変更のあるファイル丸ごとgzipで圧縮して毎回全部保存してるんだよね。

[masa_iwasaki]

svnから移行してきた勢にとってはこれがsvnとgitの一番の違いだったので当たり前のことかもしれないけどgitから入った人だと知らないで使っているかもしれない。

[pokuwagata]

意外と理解されてない

[tumo300-500]

`リネームの検出の計算が長くなるのを避けるため、 A + D の値が内部的な制限値よりも大きい場合は、Git は編集リネームの検出をスキップします` へぇへぇ

[yarumato]

“Gitは用語と想像する挙動が違って混乱すると言われます。この混乱の根本的な原因は「コミットは 差分 であり順番を入れ替えることができる」という解釈。コミットは差分ではありません。ならcherry-pickやrebaseは”

[te2u]

コミットはスナップショットで、rebaseなどでは内部で差分を計算して適用したものをスナップショットしている。git内部でいつでも差分を計算できることが重要で、rebaseでコミットの入れ替えができるのはこのおかげか。

[umai_bow]

システム的には差分しか保存しない（容量節約のために）けど、モデル的には完全なスナップショットとして扱われるよ！！文句のあるブコメが上位に来るのが驚き。ちゃんと理解するとgitが使いやすくなるよ

[kazatsuyu]

ファイルごとの差分は作らないけどファイルシステム全体で見れば差分よね

[youhey]

とはいえそのスナップショットの差分を保存すると考えると、けっきょく差分と考えたほうがシックリくるような気も

[Insite]

インターフェイスは差分とスナップショットを返し、データ構造は木構造の更新履歴が保存可能なグラフ構造と差分記録であるというだけ。時間空間コストが劣らなければユーザには関係ない話。

[iga_k]

ずっと差分だと思って暮らしていたのでgit何もわからない・・・になった

[tossy_yukky]

知らないこと多かった

[tettekete37564]

“コミットは 差分 であり順番を入れ替えることができるという解釈” < ？差分だから順番を入れ替えることが出来ない、じゃないの

[ku__ra__ge]

さらに混乱する話として、論理的にはスナップショットだが実際に保存されているデータは差分(の場合もある)。圧縮して1GBになるファイルを2回コミットしたレポジトリが2GBになるとは限らない。

[ducky19999]

1つ1つのファイルはスナップショット

[versatile]

そろそろ新しいのが出るかもしれんね

[everybodyelse]

マージした後に過去のコミットにチェックアウトしても、マージされた状態で戻るわけじゃないので、スナップショットであることは普通に分かりそうなもんだけどな。

[take4mats]

ああなるほど、 rebase と cherry-pick 完全に理解した “rebase コマンドは単純に <target> に移動し、見つけたコミットたちに対して git cherry-pick コマンドを最も古いコミットから順に実行し始めます。”

[sha51]

そういえば昔読んだgitの本を見つけてたまたま最近読み返したら丁度同じ事書いてたな。今だったら理解出来る

[taguch1]

全部ポインタとして見てる。

[LiosK]

これ読んでもまだコミットが差分だと思ってる人がいるっぽくて驚く。HEAD^とか別ブランチとかとの差分をgit diffで見慣れてれば、直前コミットとの差分だけが何か特別なものっていう観念は薄れそうな。

[diveintounlimit]

だいぶ前に見たようなと思ったら https://github.blog/2020-12-17-commits-are-snapshots-not-diffs/ の日本語訳か。 https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shallow-clone/ の記事も面白いので読むと良いと思うよ。