[過去ﾛｸﾞ] Git 18 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
851(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 6914-pSqO) [sage] 2022/11/05(土) 13:57:20.56 ID:0q4aURph0(2/9) AAS
git add -Aで十分とかさぁ、開発経験なさすぎだろ
それはgitをバックアップとか途中セーブ機能とでも思ってんのか？
1 commit = 一機能の追加とか、一日の最後にやるものとか思ってるんだろ
通常なにかのバグの修正とか
複数の個別の問題の複合なのに
それ全部まとめんな
852(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2022/11/05(土) 13:58:29.56 ID:646uiMLL0(5/38) AAS
>>846
そもそも俺含めて大半のプログラマはGitを理解したいとは思ってなくて、
単に便利だから使ってるだけだと思うがな。
理解せずに使えるのならそれに越したことはない。
(この価値観が相容れないのは理解したからもういいが）
君はGitを履歴追跡ツールとしてしか見てないようだが、
俺はもっと一般的に、Git形式のDBとして見てる。(INSERT履歴が保持されるDB)
そして、俺は>>808と同意見で、
開発が今現在行われていないブランチは閉じられてた方が見やすいと思ってる。
常時存在するのはgit-flowでいうdevelopだけで、masterやreleaseはタグでよく、
hotfixを作るならまずmasterブランチを復活させ、そこからhotfixを発生させたほうがいい。
(なおreleaseブランチは最後にバージョンを打つ奴にはいいが、
俺は先にバージョンを打ってから更新部分を実装するので、俺のワークフローには合わない）
それ以外にも、featureX付加時の変更漏れ/不適切な変更によるバグ挿入が後で発覚することはあるから、
git-flow的にfeatureを作っては消しで行くなら、ブランチの復活はプログラマには疑問のないことだ。
featureX_patch0と新たな変更扱いしてもgitオブジェクトツリー自体は同じだが、
名前が似てるだけの別物扱いになるので、
featureXの開発『線』をメンテナンスする気なら、branchの復活が必要になる。
実は、とりあえず同じ名前で作り直せば自動的にくっつく馬鹿向け仕様か？と試してみたが、
まあGitの文化でこれはなかった。
が、まあ、俺的にはこれであって欲しかったね。
「同じ名前が昔ありましたが、そこにくっつけますか？(Y/N)」「Y」
「いい加減にしてくださいよ、何回目ですか？」「うるせーよ」みたいな。
ただこれ、branch側は --list オプションで表示を簡単に絞れるから、
Gitの思想としてはbranchは「消さずに全部残しておけ」で、
git-flowがGitの思想と合ってないだけだね。ならツール用意しとけと。
853: デフォルトの名無しさん (ﾜｯﾁｮｲ 6914-pSqO) [sage] 2022/11/05(土) 14:02:51.18 ID:0q4aURph0(3/9) AAS
>>852
世の中に理解しないで使えるものなんてない
854(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 6914-pSqO) [sage] 2022/11/05(土) 14:04:13.47 ID:0q4aURph0(4/9) AAS
大体gitの使い方を理解したいと思ってるやつはアホ
理解するのはバージョン管理の仕方だ
こうやってツールの使い方を学ぶことが理解だと思ってるから
gitがなくなったらどうしよう
また新しいことを学ばなきゃいけないってなるんやろ
855: デフォルトの名無しさん (ﾌﾞｰｲﾓ MM96-1bV6) [sage] 2022/11/05(土) 14:19:41.99 ID:W/77BOuWM(1/2) AAS
>>854
git そのものを理解すること諦めたか
でもお前使い方の方も盛大に勘違いしてるよ
856: デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2022/11/05(土) 14:24:19.56 ID:646uiMLL0(6/38) AAS
>>851
> それはgitをバックアップとか途中セーブ機能とでも思ってんのか？
> 1 commit = 一機能の追加とか、一日の最後にやるものとか思ってるんだろ
そうだぞ。
ブッ込んでおけば後で何とでもなるただのバケツでしかない。
バケツの使い方を学べとか、知るかボケだ。
後でバケツから探し出すハメになった時、取り出し方をググって取り出せれば十分だ。
大方、プログラマの大半はこの程度の認識のはずだぞ。
そしてお前が望む、綺麗な管理記録は、これのサブセットでしかないんだよ。
だから例えば俺が780で言ったように、「コミットメッセージが空」を除外すれば簡単に得られる。
今のGitにこの機能がないだけ。（まあ近い機能はあるが）
DBならWHEREに条件を付加すればいいだけの楽勝案件で、Web系ならみんな出来るよ。
sedのワンライナーで済むことすらCで実装するGit界隈だと誰も出来ないのだろうけどさ。
まあGitにSQLインタフェースを付け加えればWeb系の奴等は文句言わなくなるんじゃないかな？
連中にとっては直感的になるから。
857: デフォルトの名無しさん (ﾜｯﾁｮｲ 6914-pSqO) [sage] 2022/11/05(土) 14:34:25.48 ID:0q4aURph0(5/9) AAS
> 大方、プログラマの大半はこの程度の認識のはずだぞ。
お前の周りの無能集団だけだろ
858(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 6914-pSqO) [sage] 2022/11/05(土) 14:35:58.29 ID:0q4aURph0(6/9) AAS
一体どこのプロジェクトに「2022年11月4日の仕事終了時のセーブ」なんてコミットがあるんですかねぇ
859(2): デフォルトの名無しさん (ｱｳｱｳｳｰ Sacd-EsyA) [age] 2022/11/05(土) 14:42:21.04 ID:oTMzuhJSa(1) AAS
>>858
それなんて、俺の前の職場
860(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 6914-pSqO) [sage] 2022/11/05(土) 14:46:20.49 ID:0q4aURph0(7/9) AAS
データの取り出し方なんか知っていても
過去のコミットのミスを簡単に直せないなら
バージョン管理は苦痛になるし
やっぱりツールの使い方だけ知ってバージョン管理をしたことがないんだろうな
バージョン管理が不便だからgitが作られたんだぞ
861: デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2022/11/05(土) 14:58:06.66 ID:646uiMLL0(7/38) AAS
>>859
俺はそれでいいと思うけど。
記録してない方が問題で、記録さえしてあれば、ゴミとマジを簡単に分離出来れば十分だ。
>>860
今のGitの修正は十分苦痛だよ。
修正させたくないから面倒にする、は間違いで、
簡単に修正出来るが、修正したことも履歴に残るようにする、が正しい。
862(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 6914-pSqO) [sage] 2022/11/05(土) 15:03:35.62 ID:0q4aURph0(8/9) AAS
× 俺はそれでいいと思うけど。
○ 無能はそんなことをしている。
まずさぁ、gitというかバージョン管理の基本を理解してないんだからさ
そこから勉強しなよ
863(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 6914-pSqO) [sage] 2022/11/05(土) 15:04:40.67 ID:0q4aURph0(9/9) AAS
> 簡単に修正出来るが、修正したことも履歴に残るようにする、が正しい。
お前はテキストエディタで保存するたびに
gitにセーブしろって言ってんのか？ｗ
864(2): デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2022/11/05(土) 16:06:55.57 ID:646uiMLL0(8/38) AAS
>>863
俺が言ってる「修正」は、Git自体の修正で、
> なのでマージ前のブランチをレビュー対象とする開発では push の際に整理することになる (778)
の場合に、SQL的に、
DELETE FROM my_repo WHERE branch='featureX' AND commit_message='';
あるいは、
CREATE INDEX beautiful_featureX ON my_repo WHERE branch='featureX' AND commit_message='';
で済むのに、何故Gitにつき合ってグダグダやらねばならんのだ？ということ。
それとは別に、ちょこまかcommitしても、俺は構わんと思うけど。
上記のように、それを１コマンドで除去出来れば、実務上何ら問題ない。
粒度が細かすぎてDBが膨れあがるなら、その部分を定期的にバックアップに切り出していけばいいだけ。
bitcoinはこの方式だ。
>>862
多分根本的に違うのは、
俺： 俺のワークフローに合うようにツールをカスタマイズする
863： Gitのワークフローに合わせてgitを使え、それ以外認めない！
なんだよ。
Linusが個人的に開発したんだからGit自体はそれでいいんだが、
全世界でLinuxと同じワークフローが適切なわけではない。
865: デフォルトの名無しさん (ﾜｯﾁｮｲ 6914-pSqO) [sage] 2022/11/05(土) 16:10:37.55 ID:5Oe/8sYX0(1/24) AAS
>>864
アホなの？コミットメッセージは毎回入れるものだ
866: デフォルトの名無しさん (ﾜｯﾁｮｲ 6914-pSqO) [sage] 2022/11/05(土) 16:11:36.07 ID:5Oe/8sYX0(2/24) AAS
>>864
> 全世界でLinuxと同じワークフローが適切なわけではない。
だからgitはいろんなワークフローに対応してるんだろうが
お前のはバージョン管理のワークフローではない
ただのバックアップのワークフローだ
867: デフォルトの名無しさん (ﾜｯﾁｮｲ 5e8f-gUJl) [sage] 2022/11/05(土) 16:45:19.71 ID:CLSrxuim0(2/2) AAS
まあ1人プロジェクトみたいだし好き勝手やらせればいいさ
868: デフォルトの名無しさん (ﾜｯﾁｮｲ 6914-pSqO) [sage] 2022/11/05(土) 16:54:40.83 ID:5Oe/8sYX0(3/24) AAS
コミットメッセージが空だったら～とかわけわからんなｗ
869(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 6914-pSqO) [sage] 2022/11/05(土) 16:56:10.72 ID:5Oe/8sYX0(4/24) AAS
行単位で独立してるデータベースのデータじゃないんだからさぁ
ソースコードは前後の歴史とつながってる
DELETEなんちゃらみたいに一つだけ取り除くことが出来るのは稀
870(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2022/11/05(土) 17:21:12.99 ID:646uiMLL0(9/38) AAS
>>869
それは当然UIの話で、当たり前だが内部のリンクは接続し直すんだよ。
そしてそれをユーザーには見せない。
多分ここら辺の階層の話がGitには存在しないんだよ。
だからユーザーがviでリンク書き換えろとかの勢いだろ。
超密結合だし滅茶苦茶だよそれは。
871(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 6914-pSqO) [sage] 2022/11/05(土) 17:22:28.46 ID:5Oe/8sYX0(5/24) AAS
>>870
都合が悪いからって無視するな
前後のソースコード関連してるから
途中のコミットを取り除くことはできないと言ってる
872: デフォルトの名無しさん (ﾜｯﾁｮｲ 0d4e-GJ//) [] 2022/11/05(土) 17:28:35.59 ID:B2i8Nuif0(1) AAS
つまり、両親がイブに中出ししてお前が生まれたという歴史において、
イブの中出しだけを無かったことにはできないと言うことだね
その後の歴史でお前が存在するのはおかしいし
873(3): デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2022/11/05(土) 17:30:55.67 ID:646uiMLL0(10/38) AAS
>>871
何言ってんだ？
中身はただの単方向リンクリストだぞ。
リンク先が複数のこともあるが、それでも問題なく抜ける。
ただそれ以前に、俺は既に言ったとおり「記録されてないほうが問題」とするので、
CREATE INDEXを使うが。これなら理解出来るか？
だったら、このINDEX対象をちょうど全部含むようにリンクリストを新しく作り直せばいいだけ。
それがDELETEしたものと同じ物になる。これで理解出来るか？
874(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 6914-pSqO) [sage] 2022/11/05(土) 17:40:00.52 ID:5Oe/8sYX0(6/24) AAS
>>873
じゃあ抜き取ってみ
・commit 1「aaa を追加」
aaa
・commit 2「bbb を追加」
aaa
bbb
・commit 3「bbb を ccc に置き換えた」
aaa
ccc
ここからcommit2を抜き取ったときの
commit3の修正内容をよく読んでみろ
875(1): デフォルトの名無しさん (ﾌﾞｰｲﾓ MM96-1bV6) [sage] 2022/11/05(土) 17:44:37.25 ID:W/77BOuWM(2/2) AAS
>>873
残念だけどそこから間違ってる
Gitのコミットのリストは単方向リンクリストではない
なのでリストの途中のコミットを削除したり途中に追加できない
876(2): デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2022/11/05(土) 17:58:44.17 ID:646uiMLL0(11/38) AAS
>>874
ああコミットメッセージについては考えてなかったが、
俺ならそのままぐちゃっと貼り付けるけど。
つまり、
・commit 1「aaa を追加」
aaa
・commit 3「bbb を追加」「bbb を ccc に置き換えた」
aaa
ccc
になる。
877(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2022/11/05(土) 18:03:19.55 ID:646uiMLL0(12/38) AAS
>>875
親が複数あるだけの単方向リストだよ。
まあこれを単方向リストと呼ぶかは微妙だから、ツリーと言った方が通じたか？
ツリーが複数重なり合った状態になってるだけだよ。
単線の A<-B<-C なら A<-C になる。これは自明だよな。
マージの場合、(BがADのマージ結果ね）
A<-B<-C
D<-|
を
A<-C
D<-|
にする。
878(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 6914-pSqO) [sage] 2022/11/05(土) 18:18:30.70 ID:5Oe/8sYX0(7/24) AAS
>>876
ようやく理解したか。
だからお前がやってるのはただのバックアップを取ってるだけだっていってんだよ
バージョン管理というのは何をどう変えたかという変化を記録するものだ
スナップショットじゃねーんだよ、あーほ
879: デフォルトの名無しさん (ﾜｯﾁｮｲ 6914-pSqO) [sage] 2022/11/05(土) 18:19:21.47 ID:5Oe/8sYX0(8/24) AAS
>>876
bbbの話がないのだから、
書き間違えなのか全く区別がつかない
バグコミットメッセージだな
880(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 6914-pSqO) [sage] 2022/11/05(土) 18:21:44.83 ID:5Oe/8sYX0(9/24) AAS
>>873
> ただそれ以前に、俺は既に言ったとおり「記録されてないほうが問題」とするので、
だからお前のテキストエディタでの変更内容を全部記録するって言ってるんだろ？
ファイルを保存するたびにコミットするんだろお前は？
バージョン管理で記録するのはソースコードの修正履歴であって
お前個人の作業履歴じゃねーんだよ
使い物にならないゴミコミットを作るな
881(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2022/11/05(土) 18:26:48.37 ID:646uiMLL0(13/38) AAS
>>878
ああ履歴についての認識が違うんだな。了解した。
履歴は、
俺： スナップショット＝「点」の並び
君： 変更した線の並びで、それはcommitメッセージに現れる。
それだと、commitメッセージが間違ってる場合はどうしようもなくなるだろ。
あくまでソースコードが重要で、どこをどう変えたかはdiff取れば済むだけの話、
commitメッセージなんて目安に過ぎないんだよ。
Gitもこちらの立場に近く、VCSとしては珍しく(と聞いているが俺はそこまで詳しくないが）
差分ではなく本体を記録するだろ。
882(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 6914-pSqO) [sage] 2022/11/05(土) 18:31:31.07 ID:5Oe/8sYX0(10/24) AAS
>>881
> 履歴は、
> 俺： スナップショット＝「点」の並び
だから、それはバックアップで言うって最初から言ってるだろ
お前が完全に間違ってるんだよ
> それだと、commitメッセージが間違ってる場合はどうしようもなくなるだろ。
修正しろよ。それが出来るように作られているだろ
> commitメッセージなんて目安に過ぎないんだよ。
はっｗ バージョン管理の素人が。
コミットメッセージの重要性を知らない時点で終わってるよ
883(2): デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2022/11/05(土) 18:32:44.57 ID:646uiMLL0(14/38) AAS
>>880
> ファイルを保存するたびにコミットするんだろお前は？
そこまではしないが、1日10回とか平気ですることもあるし、それが問題だとも思わない。
この辺はポリシーだし、好きなようにすればいいと思うがね。
間違いなく言えるのは、俺は美しいソースコードを目指しているのであって、
美しいコミット履歴を目指しているわけではないんだよ。
そしてコミット履歴が過剰なら、落とせばいいだけだろ、という話。
無い履歴からは生成することは不可能なのだから、大きすぎる粒度より、小さすぎる粒度の方がいいに決まってる。
所詮commitメッセージなんて当てにならないし、diffが取れれば全く問題ない。
884(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 6914-pSqO) [sage] 2022/11/05(土) 18:32:45.04 ID:5Oe/8sYX0(11/24) AAS
> Gitもこちらの立場に近く、VCSとしては珍しく(と聞いているが俺はそこまで詳しくないが）
> 差分ではなく本体を記録するだろ。
だから最初からバージョン管理は差分を記録するものであり
gitの優れた点が、発想の転換で
本体を記録することで差分を表現することにした点なんだろ
実装の話とごっちゃにするな
そういうところが技術的に未熟なんだよ
885: デフォルトの名無しさん (ﾜｯﾁｮｲ 6914-pSqO) [sage] 2022/11/05(土) 18:33:34.01 ID:5Oe/8sYX0(12/24) AAS
>>883
> そこまではしないが、1日10回とか平気ですることもあるし、それが問題だとも思わない。
そりゃお前が素人だから問題であることに気づいてないだけ
誰もやってないからね
> この辺はポリシーだし、好きなようにすればいいと思うがね。
お前が未熟だから反論できずにポリシーってことにしようとしてる
886(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 09e4-chQ5) [sage] 2022/11/05(土) 18:33:50.55 ID:zDjINlW+0(6/26) AAS
>>877
分散バージョン管理ではですね、リポジトリのコピーがばらばらに複数存在することが前提なので、
あるひとつのリポジトリのコミット履歴が A<-B<-C で、他のリポジトリではこれが A<-C になっているという状況は不味いんですよ
なのでGitではそれができないようにデータ構造が設計されています
887: デフォルトの名無しさん (ﾜｯﾁｮｲ 6914-pSqO) [sage] 2022/11/05(土) 18:34:49.14 ID:5Oe/8sYX0(13/24) AAS
> 間違いなく言えるのは、俺は美しいソースコードを目指しているのであって、
> 美しいコミット履歴を目指しているわけではないんだよ。
コミット履歴は「使うもの」だって分かってないようだな
一部のコミットだけ抜き取って
他のブランチに組み込む
使うものだ
お前はただ見れればいいと思ってる
バージョン管理を理解してない
888: デフォルトの名無しさん (ﾜｯﾁｮｲ 6914-pSqO) [sage] 2022/11/05(土) 18:35:50.16 ID:5Oe/8sYX0(14/24) AAS
>>883
> 所詮commitメッセージなんて当てにならないし、diffが取れれば全く問題ない。
お前が作るコミットがクソだから、使いものにならなくなっているだけだなｗ
889(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2022/11/05(土) 18:39:58.47 ID:646uiMLL0(15/38) AAS
>>882
まあ君と仕事することは無さそうだから別に問題ないけど、
> 修正しろよ。それが出来るように作られているだろ
コミットメッセージをいくら修正したところでそもそも意味無いんだよ。
管理してるのはメッセージじゃなくてソースコードなんだから。
それで、重要なコメントはソースコード上に書いてるから、diff取れれば十分なんだよ。
コミットメッセージは、あくまでGit上から探し出すラベルでしかなくて、何をやったかはdiffで見るし、それ以外にないよ。
> はっｗ バージョン管理の素人が。
> コミットメッセージの重要性を知らない時点で終わってるよ
まあ俺はGitの達人になりたいわけでもないんで、これで問題ないよ。
890: デフォルトの名無しさん (ﾜｯﾁｮｲ 6914-pSqO) [sage] 2022/11/05(土) 18:40:40.33 ID:5Oe/8sYX0(15/24) AAS
> コミットメッセージをいくら修正したところでそもそも意味無いんだよ。
それはお前だけの感想ですねｗ
891: デフォルトの名無しさん (ﾜｯﾁｮｲ 6914-pSqO) [sage] 2022/11/05(土) 18:41:08.69 ID:5Oe/8sYX0(16/24) AAS
> まあ俺はGitの達人になりたいわけでもないんで、これで問題ないよ。
バージョン管理の素人だって言ってる
お前、他の人と一緒に仕事ができないよｗ
892: デフォルトの名無しさん (ﾜｯﾁｮｲ 6914-pSqO) [sage] 2022/11/05(土) 18:41:43.46 ID:5Oe/8sYX0(17/24) AAS
> コミットメッセージは、あくまでGit上から探し出すラベルでしかなくて、何をやったかはdiffで見るし、それ以外にないよ。
途中を抜いといて、何をやったかなんてわかるわけ無いだろｗｗｗ
893: デフォルトの名無しさん (ﾜｯﾁｮｲ 6914-pSqO) [sage] 2022/11/05(土) 18:43:50.28 ID:5Oe/8sYX0(18/24) AAS
>>889
こうやってコミット履歴をちゃんと見れて
なんの変更をしたのかわかるようになるまで頑張れよ
https://github.com/freebsd/freebsd-src/commits
お前のコミットは汚すぎて
使い物にならんのだわ
894: デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2022/11/05(土) 18:44:39.97 ID:646uiMLL0(16/38) AAS
>>884
> gitの優れた点が、発想の転換で
> 本体を記録することで差分を表現することにした点なんだろ
これは違う。
というかね、どっちを記録したところで、正常に動いていればどのみち任意の履歴を取り出せるから関係ないんだ。
ただ、ファイルシステム等がぶっ壊れて、断片的にしか取り出せなくなったときに、Gitみたいに本体を記録してる方が断然強い。
だから基本は「一番大事なもの」で記録するようにしなければいけない、という観点だったのだけど、
まあこれはフォールトトレラントにしろという話で、ちょっと蛇足ではあったね。
あまり関係ないからこの話は終わりで。
895: デフォルトの名無しさん (ﾜｯﾁｮｲ 6914-pSqO) [sage] 2022/11/05(土) 18:45:34.09 ID:5Oe/8sYX0(19/24) AAS
> これは違う。
だーかーら、素人のお前の意見なんか聞いてない
896: デフォルトの名無しさん (ﾜｯﾁｮｲ 6914-pSqO) [sage] 2022/11/05(土) 18:50:58.69 ID:5Oe/8sYX0(20/24) AAS
> ただ、ファイルシステム等がぶっ壊れて、断片的にしか取り出せなくなったときに、
gitは速度のためにスナップショットにしてると書いています
https://git-scm.com/book/ja/v2/%E4%BD%BF%E3%81%84%E5%A7%8B%E3%82%81%E3%82%8B-Git%E3%81%AE%E5%9F%BA%E6%9C%AC
897: デフォルトの名無しさん (ﾜｯﾁｮｲ 6914-pSqO) [sage] 2022/11/05(土) 18:53:08.44 ID:5Oe/8sYX0(21/24) AAS
https://www.techpit.jp/courses/33/curriculums/34/sections/286/parts/965
なぜスナップショットとして記録するのか
スナップショットとして記録することで、複数人で開発する時のスピードを上げることができます。
詳しくは後ほど解説しますが、複数人での開発の際、並行して開発できるよう、
Gitではブランチというものを切って、バージョンを枝分かれさせて開発していきます。
このブランチでバージョンを枝分かれさせる際や、ブランチを統合(マージ)する際にスナップショットだと非常に作業が速くできます。
Gitがデータを差分というかたちで持っていると、ブランチを切ってマージする時に差分をいちいち計算しなければなりません。
しかしスナップショットで保存しておけば、差分の計算をしなくて済む分、とても速くブランチを切ったりマージできるようになります。
ちなみに、Git以前のバージョン管理ツールの多くは差分としてデータを保存していて、ブランチを切るのに大変時間がかかっていました。
大規模なプロジェクトになると数十秒かかったりすることもありました。
Gitだとこの作業が一瞬でできます。こういった事情があって、Linuxの作者のリーナス・トーバルズは
当時、大規模開発であったLinuxカーネル開発のバージョン管理システムを自作しました。これがGitのスタートです。
898(3): デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2022/11/05(土) 18:56:37.48 ID:646uiMLL0(17/38) AAS
>>886
ああなるほど、ブロックチェーンよろしく親のhashデータも自分のhashに入ってるのか。
しかしそれは、改竄がばれるだけで、リンクを繋ぎ直すことが出来ないわけではないね。
というかね、それは本体ツリーの話で、
余分なcommitはrepoから消せ！とする君らにとっては問題だが、
俺みたいに、スカスカのINDEXでbranchを再構成するのはその場合にも全く問題ないはず。
ところで、
実は今もbranchの実体がどこにあるのか見えてない。
見る限り .git/logs/refs/heads/各branchにしかなさそうなのだけど、ここかね？
これだと毎回reflogを動的に解釈することになるが。
実装としておかしくはないが、普通はこうはしないので、ちょっと不可解だ。
なおオブジェクトツリーにはbranchのデータは無く、branchは各オブジェクトへのリンクの入った配列だと見てる。
だからシャローコピーでしかなく、後からでもいくらでも作れるだろ、という話。
899: デフォルトの名無しさん (ﾜｯﾁｮｲ 6914-pSqO) [sage] 2022/11/05(土) 19:03:07.94 ID:5Oe/8sYX0(22/24) AAS
> 後からでもいくらでも作れるだろ、という話。
だから速度重視だって言ってる
900: デフォルトの名無しさん (ﾜｯﾁｮｲ 6914-pSqO) [sage] 2022/11/05(土) 19:03:54.30 ID:5Oe/8sYX0(23/24) AAS
>>898
君、ほんと知らないなら黙ってたほうがいいよ
恥ずかしいだけだから
901: デフォルトの名無しさん (ﾜｯﾁｮｲ 6914-pSqO) [sage] 2022/11/05(土) 19:05:11.02 ID:5Oe/8sYX0(24/24) AAS
>>898
> 余分なcommitはrepoから消せ！とする君らにとっては問題だが、
余分なコミットじゃなくて、
コミットとして使えないものにする
バグコミットを消せと言ってるだけ
902(2): デフォルトの名無しさん (ﾜｯﾁｮｲ 09e4-chQ5) [sage] 2022/11/05(土) 19:21:59.71 ID:zDjINlW+0(7/26) AAS
>>898
まあもう面倒臭くなってきたので全部説明しちゃうが
結果的に親のhashが自分のhashに含まれることになるのだけど、実際には親のhashは自分のコミットオブジェクトに含まれている
その自分のコミットオブジェクトから計算して求めるのが自分のhash
親の祖先に変更があれば自分のコミットオブジェクトの作り直しになってhashも計算し直すことになりそれはもう自分ではない
ブランチの実体はコミットオブジェクトのハッシュひとつだけ
それで事足りる
ず〜〜〜と思っているんだがどう考えてもお前のブランチへの理解はオカシイ
内部的な構造の話ではなくてユーザとして使う上でも問題があるような酷い理解に見える
だから >>815 みたいな謎発言がでてくる
DBのINDEXみたいなもの？とかの謎解釈で突き進まれてもついていけない
903(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2022/11/05(土) 20:06:13.91 ID:646uiMLL0(18/38) AAS
>>902
前半の内容は知ってるし、そのつもりで898を書いてる。
それはtutorial2に書いてあったから。
そこのhash値も混ぜてるかどうかは関知してなかっただけ。
ちなみにtutorlal2には「ここのhash値とは違うから、各自のhash値をコピペしてね」
と書いてあるが、実際は同じhash値が生成される。
だからどこまで混ぜ込んでるのかよくわからなった。
名前と時間も混ぜ込んでるぜ！と書いてあるが、どう見てもそうじゃない。
ただまあ、親ハッシュは混ぜ込んでるのは理解した。
> ブランチの実体はコミットオブジェクトのハッシュひとつだけ
それは俺の最初の理解、「点」なんだよ。815の通り。エントリポイントだけ、というわけだろ。
ただそれだと、オブジェクトツリーは辿れるが、
master @{1}で「master branch上の」一つ前、という経路情報に変換することが出来ない。
つまり、HEAD~! != @{1} とするには、何らかの情報が何処かに必要なんだよ。
そして今のところ、reflogしかないので、そこを動的に辿ってるのか？みたいなことになってる。
だから「reflogを偽造」(843)なんて話になる。
言い換えると、エントリポイントからだと、親は辿れるが、
親が複数現れたとき(マージ）に、どちらから来たのか分からないのと、
fast-forwardマージでオブジェクトは一本道でもbranch上では飛ばしている場合に、その情報がないんだよ。
これはどこに格納されてるんだ？
904: デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2022/11/05(土) 20:19:07.74 ID:646uiMLL0(19/38) AAS
すまん、分かると思うが、 HEAD~1 != @{1}
905(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 09e4-chQ5) [sage] 2022/11/05(土) 20:45:45.41 ID:zDjINlW+0(8/26) AAS
>>903
reflogのhashは、HEADが変わるような操作をしたときに、その操作の結果のHEADのhashを追記していくだけのログだよ
このログがその後のgitの動作に影響を与えることはない
HEAD@{0}が常に最新の操作に対応したhashに更新される
だからたとえばmasterとfirstという二つのブランチを交互にcheckoutすればこんな感じになる
$ git reflog
0956cde (HEAD -> first) HEAD@{0}: checkout: moving from master to first
be7e7d7 (master) HEAD@{1}: checkout: moving from first to master
0956cde (HEAD -> first) HEAD@{2}: checkout: moving from master to first
be7e7d7 (master) HEAD@{3}: checkout: moving from first to master
0956cde (HEAD -> first) HEAD@{4}: checkout: moving from master to first
be7e7d7 (master) HEAD@{5}: checkout: moving from first to master
最後にcheckout firstしたので HEAD -> first になってる
906(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2022/11/05(土) 20:59:53.75 ID:646uiMLL0(20/38) AAS
>>905
reflogがその形式なのは知ってる。
ただ、頭のポイントだけだと、903で言ったとおり、経路情報にならないだろ。
例えば、815の場合、再記するが、
impl5@feature5, merged to develop and master, add tag of "Version1".
impl4@feathre4
impl3@feature3
impl2@feature2, merged to develop, add tag of "Version0".
impl1@feathre1
impl0@feature0
initial@master, develop
これで、master上で
git diff @{1} では、initial commit との差分
git diff HEAD~1 では、 impl4との差分が出るんだよ。
これが、master->impl5のエントリポイント情報だけだと出来ないから、
maseterはinitial->impl5に移動しましたよ、という経路情報が何処かに必要なんだ。
それで、git reflog では、
どこにswitchして、commit して、mergeした、という履歴が全部出るから、
（多分だが各HEADのreflogを全てcatして時系列にソートしてる）
解釈すれば可能ではあるけど、そんな面倒なことするか？普通はstaticにシャローコピーだろ、というのと、
reflog は gc されるので、reflogを頼りにする実装は不適切だし、
俺的にbranchを消したり復活させたりする使い方はヤバそうなんだよ。
だからその辺を確認してる。
それで、後で任意のオブジェクト群でbranchを作れるのなら、この辺心配ないのだけど、そうではなさそうだし。
907: デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2022/11/05(土) 21:04:51.93 ID:646uiMLL0(21/38) AAS
ちなみに、843の記事では、Git内のcontrib内のスクリプトが、
branchをreflogを参考に復活させるらしいので、reflog内の情報で足りてはいるらしい。
確かに目で見た限りそうだが、
でもそれだとreflogをgcするのは割と狂気の沙汰だから、おかしいよなーと思ってて。
908: デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2022/11/05(土) 21:06:47.08 ID:646uiMLL0(22/38) AAS
ごめん、書き方が悪かった。
907は、gc対象となるreflogを本番情報として持つのは狂気の沙汰だなーということ。
復活させるときにそこにしか手がかりがないのは仕方ないとして、
生きてるbranchは普通はツリー情報をstaticに持ってるはずだが、見あたらないんだよ。
909(6): デフォルトの名無しさん (ﾜｯﾁｮｲ 09e4-chQ5) [sage] 2022/11/05(土) 21:15:14.62 ID:zDjINlW+0(9/26) AAS
>>906
そのリポジトリがどういう構造になっているかわけわからん
git show-branch してみろ
910: デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2022/11/05(土) 21:26:43.61 ID:646uiMLL0(23/38) AAS
>>909
すまぬ、確かに今見てればちょっとおかしい。
もう一度作るから30分ほどお待ちを。
911(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2022/11/05(土) 21:51:56.84 ID:646uiMLL0(24/38) AAS
>>909
結果
$ git show-branch
! [develop] impl5
* [master] impl5
--
+* [develop] impl5
$ git branch
develop
* master
912(2): デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2022/11/05(土) 21:52:24.93 ID:646uiMLL0(25/38) AAS
>>909
$ git diff HEAD~1
diff --git a/test.txt b/test.txt
index 3585d98..bbddc42 100644
--- a/test.txt
+++ b/test.txt
@@ -4,3 +4,4 @@ impl1
impl2
impl3
impl4
+impl5
$ git diff @{1}
diff --git a/test.txt b/test.txt
index e79c5e8..bbddc42 100644
--- a/test.txt
+++ b/test.txt
@@ -1 +1,7 @@
initial
+impl0
+impl1
+impl2
+impl3
+impl4
+impl5
913(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2022/11/05(土) 21:53:21.88 ID:646uiMLL0(26/38) AAS
>>909
再現コード
#!/bin/bash -x
#
git init
echo 'initial' > test.txt
git add test.txt
git commit -m 'initial'
git branch develop
for (( i=0 ; i<6 ; i++ ));
do
git branch feature$i
git switch feature$i
echo "impl"$i >> test.txt
git add test.txt
git commit -m "impl"$i
git switch develop
git merge feature$i
git branch -d feature$i
done
git switch master
git merge develop
914(2): デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2022/11/05(土) 22:01:15.70 ID:646uiMLL0(27/38) AAS
>>909
ちなreflog
$ git reflog
1a804d9 (HEAD -> master, develop) HEAD@{0}: merge develop: Fast-forward
b0325fc HEAD@{1}: checkout: moving from develop to master
1a804d9 (HEAD -> master, develop) HEAD@{2}: merge feature5: Fast-forward
ba4e962 HEAD@{3}: checkout: moving from feature5 to develop
1a804d9 (HEAD -> master, develop) HEAD@{4}: commit: impl5
ba4e962 HEAD@{5}: checkout: moving from develop to feature5
ba4e962 HEAD@{6}: merge feature4: Fast-forward
a32e11d HEAD@{7}: checkout: moving from feature4 to develop
ba4e962 HEAD@{8}: commit: impl4
a32e11d HEAD@{9}: checkout: moving from develop to feature4
a32e11d HEAD@{10}: merge feature3: Fast-forward
8d9924f HEAD@{11}: checkout: moving from feature3 to develop
a32e11d HEAD@{12}: commit: impl3
8d9924f HEAD@{13}: checkout: moving from develop to feature3
8d9924f HEAD@{14}: merge feature2: Fast-forward
0f78740 HEAD@{15}: checkout: moving from feature2 to develop
8d9924f HEAD@{16}: commit: impl2
0f78740 HEAD@{17}: checkout: moving from develop to feature2
0f78740 HEAD@{18}: merge feature1: Fast-forward
47792a3 HEAD@{19}: checkout: moving from feature1 to develop
0f78740 HEAD@{20}: commit: impl1
47792a3 HEAD@{21}: checkout: moving from develop to feature1
47792a3 HEAD@{22}: merge feature0: Fast-forward
b0325fc HEAD@{23}: checkout: moving from feature0 to develop
47792a3 HEAD@{24}: commit: impl0
b0325fc HEAD@{25}: checkout: moving from master to feature0
b0325fc HEAD@{26}: commit (initial): initial
915(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2022/11/05(土) 22:02:09.13 ID:646uiMLL0(28/38) AAS
>>909
ついでに一応、終了時のtest.txt
$ cat test.txt
initial
impl0
impl1
impl2
impl3
impl4
impl5
916(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 09e4-chQ5) [sage] 2022/11/05(土) 22:05:21.84 ID:zDjINlW+0(10/26) AAS
>>911-915
これ全部FFマージやってるから結果的にdevelopブランチとmasterブランチが同じものになるぞ
917(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 09e4-chQ5) [sage] 2022/11/05(土) 22:09:56.21 ID:zDjINlW+0(11/26) AAS
mergeを全部merge --no-ffにするとマージした構造がわかるようになるし、最後にdevelopとmasterが別のものになる
どっちのマージにするかは現場の運用しだい
918: デフォルトの名無しさん (ﾜｯﾁｮｲ 09e4-chQ5) [sage] 2022/11/05(土) 22:10:47.10 ID:zDjINlW+0(12/26) AAS
git log --graph --branches --oneline とかするとわかりやすい
919: デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2022/11/05(土) 22:11:46.51 ID:646uiMLL0(29/38) AAS
>>916
ああ、それがrebaseしないと履歴が無くなるとかいう話か？
実はそれはまだ確認中だが、とりあえず本件についてはこれでいいし、
俺的には多分こうなる。(基本的にmasterはdevelopの後を追うだけ)
けしからんか？
それはさておき、本件、HEAD~1 と @{1} が違うものだという経路情報は、
どこにあるのか分かれば教えてくれ。
920(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 09e4-chQ5) [sage] 2022/11/05(土) 22:22:33.37 ID:zDjINlW+0(13/26) AAS
HEAD~1と@{1}は全然関係無いよ？
HEAD~1は今のHEADの一番目の親のhash
親が複数いるときにはHEAD^1とかHEAD^2とかで指定する
@{1}はひとつ前の操作によってHEADになったhashだから、どういう操作したかで変わり、リポジトリの構造とは関係無い
921(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 09e4-chQ5) [sage] 2022/11/05(土) 22:30:34.81 ID:zDjINlW+0(14/26) AAS
>>914 で説明すると、
@{0}は最後のコミットで、FFマージした結果masterとdevelopがこのhash=1a804d9になった
@{1}はgit commit -m 'initial'の結果できた最初のコミット(最後のマージ操作の前のmaster)で、最後にこれにdevelopをマージするためcheckoutしたらこれになってる
922(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2022/11/05(土) 22:35:17.82 ID:646uiMLL0(30/38) AAS
>>920
> @{1}はひとつ前の操作によってHEADになったhashだから、どういう操作したかで変わり、リポジトリの構造とは関係無い
だから、それは「そのbranchの」一つ前の操作なんだよ。
結果、diffは、masterブランチでは>>912で、HEAD~1 != @{1} だが、
developブランチでは、以下になって、 HEAD~1 == @{1} なんだよ。
$ git diff HEAD~1
diff --git a/test.txt b/test.txt
index 3585d98..bbddc42 100644
--- a/test.txt
+++ b/test.txt
@@ -4,3 +4,4 @@ impl1
impl2
impl3
impl4
+impl5
$ git diff @{1}
diff --git a/test.txt b/test.txt
index 3585d98..bbddc42 100644
--- a/test.txt
+++ b/test.txt
@@ -4,3 +4,4 @@ impl1
impl2
impl3
impl4
+impl5
だからmasterブランチをdevelopにmergeしかしない運用をした場合、
masterブランチは @{n} でn回前のリリースが検索出来、存在価値が出てくる、という見立てだが、間違ってるか？
(@はcommit履歴だと思ってるが、まさか操作履歴か？なら確かに意味無いし、先頭情報しか要らないし、reflogしかなくても納得だが)
923(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 09e4-chQ5) [sage] 2022/11/05(土) 22:40:04.85 ID:zDjINlW+0(15/26) AAS
最終的にお前のリポジトリは git merge develop でこうなっているはずだ
$ git log --graph --branches --oneline
* 1a804d9 impl5 (HEAD -> master, develop)
* xxxxxxx impl4
* xxxxxxx impl3
* xxxxxxx impl2
* xxxxxxx impl1
* xxxxxxx impl0
* b0325fc initial
最後のひとつ前の git switch master をやったときにはこうなっていたはず
* 1a804d9 impl5 (develop)
* xxxxxxx impl4
* xxxxxxx impl3
* xxxxxxx impl2
* xxxxxxx impl1
* xxxxxxx impl0
* b0325fc initial (HEAD -> master)
だから HEAD@{0} = 1a804d9 で、HEAD@{1} = b0325fc
924(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2022/11/05(土) 22:46:20.49 ID:646uiMLL0(31/38) AAS
>>921
@はやっぱcommit履歴だよな？
エントリポインタだけだと、commit履歴に出来ないんだよ。
今回はfast-forwardマージしてるから、
init<-0<-1<-2<-3<-4<-5 = master, develop
で、単にエントリポイントだけなら master も develop も同じ 5 で区別がない。
当たり前だが両方とも HEAD~1 は4を指してる。
ただ、@{1}は、commit履歴だから、masterでは init を指し、developでは4を指す。
この、commit履歴情報はどこに記録されてるの？というのが俺の質問。
>>923
そこは理解出来てるはず。上記の通り。
問題はcommit履歴がどこにあるか。
925: デフォルトの名無しさん (ﾜｯﾁｮｲ 09e4-chQ5) [sage] 2022/11/05(土) 22:50:12.27 ID:zDjINlW+0(16/26) AAS
>>922
masterブランチをdevelopブランチにマージする方法が
git switch masterとgit merge developの連続実行だけではないし、
HEAD@{n}は適当なタイミングでGCされるから、
HEAD@{n}をそんな用途に使う奴はいない
926(2): デフォルトの名無しさん (ﾜｯﾁｮｲ 09e4-chQ5) [sage] 2022/11/05(土) 22:52:10.49 ID:zDjINlW+0(17/26) AAS
>>924
commit履歴がどこにあるか説明するのに使いたいから、git log --graph --branches --oneline してくれ
927: デフォルトの名無しさん (ﾜｯﾁｮｲ 09e4-chQ5) [sage] 2022/11/05(土) 22:54:11.54 ID:zDjINlW+0(18/26) AAS
@はcommit履歴じゃなくて、reflogの履歴
928(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2022/11/05(土) 22:57:39.34 ID:646uiMLL0(32/38) AAS
>>926
$ git log --graph --branches --oneline
* 1a804d9 (HEAD -> master, develop) impl5
* ba4e962 impl4
* a32e11d impl3
* 8d9924f impl2
* 0f78740 impl1
* 47792a3 impl0
* b0325fc initial
929(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 09e4-chQ5) [sage] 2022/11/05(土) 23:01:41.48 ID:zDjINlW+0(19/26) AAS
@{n}はカレントブランチのreflog履歴になるはず
reflog履歴はブランチ毎に存在するので
master@{n}とdevelop@{n}は違うハッシュになってるはず
git reflog masterとgit reflog developで比べてみればわかる
930(3): デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2022/11/05(土) 23:04:26.02 ID:646uiMLL0(33/38) AAS
>>917,926
ちな --no-ff 版、
今出すと余計に混乱するかもだが。
$ git log --graph --branches --oneline
* a5aaf72 (HEAD -> master, develop) Merge branch 'feature5' into develop
|\
| * e03bcd0 impl5
|/
* 324df68 Merge branch 'feature4' into develop
|\
| * c2634c4 impl4
|/
* 68ed20a Merge branch 'feature3' into develop
|\
| * 5e12b99 impl3
|/
* 608e5d7 Merge branch 'feature2' into develop
|\
| * 4660e46 impl2
|/
* 3924eae Merge branch 'feature1' into develop
|\
| * 138d83f impl1
|/
* 7db4424 Merge branch 'feature0' into develop
|\
| * 8877414 impl0
|/
* ec041f9 initial
931(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2022/11/05(土) 23:08:22.79 ID:646uiMLL0(34/38) AAS
>>929
$ git reflog master
1a804d9 (HEAD -> master, develop) master@{0}: merge develop: Fast-forward
b0325fc master@{1}: commit (initial): initial
$ git reflog develop
1a804d9 (HEAD -> master, develop) develop@{0}: merge feature5: Fast-forward
ba4e962 develop@{1}: merge feature4: Fast-forward
a32e11d develop@{2}: merge feature3: Fast-forward
8d9924f develop@{3}: merge feature2: Fast-forward
0f78740 develop@{4}: merge feature1: Fast-forward
47792a3 develop@{5}: merge feature0: Fast-forward
b0325fc develop@{6}: branch: Created from master
ってことは、commit履歴はreflogにしか無いって事か？
ならbrahchを消すとreflogも消されてcommit履歴が消えるが、マジ？
これだとbranchの復活は本質的に無理なことになってしまう。
(他branchに断片的には残ってるんだけどさ）
932(2): デフォルトの名無しさん (ﾜｯﾁｮｲ 09e4-chQ5) [] 2022/11/05(土) 23:09:25.37 ID:zDjINlW+0(20/26) AAS
>>928
impl5のコミットオブジェクトの hash = 1a804d9
impl5のコミットオブジェクトの中には親のコミットオブジェクトimpl4の hash = ba4e962 が格納されている
impl4のコミットオブジェクトの hash = ba4e962
impl4のコミットオブジェクトの中には親のコミットオブジェクトimpl3の hash = a32e11d が格納されている
impl3のコミットオブジェクトの hash = a32e11d
impl3のコミットオブジェクトの中には親のコミットオブジェクトimpl2の hash = 8d9924f が格納されている
impl2のコミットオブジェクトの hash = 8d9924f
impl2のコミットオブジェクトの中には親のコミットオブジェクトimpl1の hash = 0f78740 が格納されている
impl1のコミットオブジェクトの hash = 0f78740
impl1のコミットオブジェクトの中には親のコミットオブジェクトimpl0の hash = 47792a3 が格納されている
impl0のコミットオブジェクトの hash = 47792a3
impl0のコミットオブジェクトの中には親のコミットオブジェクトinitialの hash = b0325fc が格納されている
initialのコミットオブジェクトの hash = b0325fc
initialのコミットオブジェクトはルートなので親のコミットオブジェクトが存在しない
つまり impl5のコミットオブジェクトの hash = 1a804d9 からたどっていけば、コミット履歴が全部わかる
親が複数存在する場合には複数の親のhashを格納する
933: デフォルトの名無しさん (ﾜｯﾁｮｲ 09e4-chQ5) [sage] 2022/11/05(土) 23:11:25.45 ID:zDjINlW+0(21/26) AAS
>>930
￥で表示されるとちょっと見にくいが、慣れれば見やすい
934: デフォルトの名無しさん (ﾜｯﾁｮｲ 09e4-chQ5) [sage] 2022/11/05(土) 23:14:09.84 ID:zDjINlW+0(22/26) AAS
>>931
逆だ。コミットのつながりはコミットオブジェクトの中にしかない >>932 みたいにね
それを説明してるのが >>902
935(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 09e4-chQ5) [sage] 2022/11/05(土) 23:16:52.31 ID:zDjINlW+0(23/26) AAS
>>930は最後のdevelopのマージが --no-ff になってないな
最後のも --no-ff にするともっと面白いぞ
936(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2022/11/05(土) 23:18:09.46 ID:646uiMLL0(35/38) AAS
>>932
ごめん、それは分かってる。
それはグローバル履歴＝gitオブジェクトを辿った履歴、だろ。
問題は、masterのcommitには b0325fc と 1a804d9 しかない、という情報が、
今のところ master の reflogにしか見あたらないんだよ。
だから、各branchを消したら、それ以前の gitオブジェクト は全部辿れるが、commit履歴は消失してしまう。
今のmasterみたいに、fast-forwardマージで中間をすっ飛ばしてきた、
という情報が無くなってしまうんだよ。
だから、branchを消す前の状態に完全には戻せない、という話。
だから、常識的に考えればもうちょっとましな何処かに保持してるはずなんだけど、無いんだ。
937(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2022/11/05(土) 23:21:56.96 ID:646uiMLL0(36/38) AAS
>>935
ほい
$ git log --graph --branches --oneline
* 2fb59f1 (HEAD -> master) Merge branch 'develop'
|\
| * 25e1b95 (develop) Merge branch 'feature5' into develop
| |\
| | * 4b27393 impl5
| |/
| * 9bfb8cc Merge branch 'feature4' into develop
| |\
| | * c2a5b7d impl4
| |/
| * 02d2308 Merge branch 'feature3' into develop
| |\
| | * f6d1cf7 impl3
| |/
| * 81e18bb Merge branch 'feature2' into develop
| |\
| | * 01c3871 impl2
| |/
| * 5b57f48 Merge branch 'feature1' into develop
| |\
| | * 0fe34d2 impl1
| |/
| * 6272da6 Merge branch 'feature0' into develop
| |\
|/ /
| * fe1b132 impl0
|/
* 832f464 initial
938(2): デフォルトの名無しさん (ﾜｯﾁｮｲ 09e4-chQ5) [sage] 2022/11/05(土) 23:23:27.84 ID:zDjINlW+0(24/26) AAS
>>936
FFマージしたらその情報は消滅するな
--no-ff で全部マージすれば複数親のハッシュをもってるコミットオブジェクトの1番目だけたどればいける
^1 だけみていくね
git log にはそれをやるオプションがあるはず
>>930をそのオプションで表示すればこんな風に表示されるはず
$ git log --graph --branches --oneline --オプション忘れた探せ
* a5aaf72 (HEAD -> master, develop) Merge branch 'feature5' into develop
* 324df68 Merge branch 'feature4' into develop
* 68ed20a Merge branch 'feature3' into develop
* 608e5d7 Merge branch 'feature2' into develop
* 3924eae Merge branch 'feature1' into develop
* 7db4424 Merge branch 'feature0' into develop
* ec041f9 initial
939(2): デフォルトの名無しさん (ﾜｯﾁｮｲ 09e4-chQ5) [sage] 2022/11/05(土) 23:26:10.78 ID:zDjINlW+0(25/26) AAS
>>937 だとこう表示されるはず
$ git log --graph --branches --oneline --オプション忘れた探せ
* 2fb59f1 (HEAD -> master) Merge branch 'develop'
* 832f464 initial
940: デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2022/11/05(土) 23:35:28.93 ID:646uiMLL0(37/38) AAS
>>938
$ git log --graph --branches --oneline --first-parent
* a5aaf72 (HEAD -> master, develop) Merge branch 'feature5' into develop
* 324df68 Merge branch 'feature4' into develop
* 68ed20a Merge branch 'feature3' into develop
* 608e5d7 Merge branch 'feature2' into develop
* 3924eae Merge branch 'feature1' into develop
* 7db4424 Merge branch 'feature0' into develop
* ec041f9 initial
>>939
$ git log --graph --branches --oneline --first-parent
* 2fb59f1 (HEAD -> master) Merge branch 'develop'
| * 25e1b95 (develop) Merge branch 'feature5' into develop
| * 9bfb8cc Merge branch 'feature4' into develop
| * 02d2308 Merge branch 'feature3' into develop
| * 81e18bb Merge branch 'feature2' into develop
| * 5b57f48 Merge branch 'feature1' into develop
| * 6272da6 Merge branch 'feature0' into develop
|/
* 832f464 initial
941: デフォルトの名無しさん (ﾜｯﾁｮｲ 09e4-chQ5) [sage] 2022/11/05(土) 23:41:19.40 ID:zDjINlW+0(26/26) AAS
>>939がそう表示されるのは、--no-ff マージの手順が何か普通とちがうからかもしれん
>>939みたいに表示させるマージの手順もあるはずだから工夫してみるんだな
942: デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2022/11/05(土) 23:41:56.11 ID:646uiMLL0(38/38) AAS
>>938
なるほど了解した。
データ側に混ぜ込んでて、保持したければ --no-ff で使えってことか。
そもそも同じハッシュなら同じgitオブジェクトにリンクするようになってるのだし、
(つまり見た目が膨らんでるだけで実際の容量は大して食わない）
--no-ff がデフォのほうがよかった気がするが。
まあとにかく了解した。長々とありがとう。
943(2): デフォルトの名無しさん (ﾜｯﾁｮｲ 527c-zlm6) [sage] 2022/11/06(日) 00:38:34.83 ID:UPUgwCSv0(1) AAS
FFがデフォじゃなと使いにくい気がするのだがｗ
944: デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2022/11/06(日) 09:32:37.27 ID:OfQ8ymDc0(1/24) AAS
>>943
ffがデフォのメリットって何だ？特にないと思うが。見た目すっきり、か？
ただまあ、デフォだし、サル先生他も特に何も言ってないので、ffでの運用が多数派なのだろう。
--no-ffはcommitオブジェクトが別に作られるだけで、
スナップショットに比べたらゴミなので全体としては大して増えない。
commit履歴はgitオブジェクトツリー内に混ぜ込まれ、完全に保持される。
ffの場合は、commit履歴情報はreflogにしか無いので、branchを削除したら基本的に失われる。
そしてreflogもgc対象なので、Linusはcommit履歴は基本的に保持する必要がないとの立場なのだろう。
また、branchを削除しろといいつつffなのは、その人達もcommit履歴は要らない、と考えていることになる。
ただこれは奇妙な実装だ。
カーナビを考えれば分かるが、当たり前だが地図情報とルート情報は別なのだ。混ぜ込むのはあり得ない。
commit履歴が要らないってのは、経路(線)は不問で、目的地(点)に着いてるかどうかだけだ、と言っているわけ。
それはバージョン管理の達人()にとっては、違うんだろ。バージョン管理は「線」であると！
ただ、Linusも「点」の立場だね。まあプログラマ的にはこれで正しいんだよ。
コンピューターは今現在のソースコードしか見てなくて、どの経路を辿ったかなんて関係ない。
だからどういう紆余曲折(「線」)があったかではなく、結局は前回の「点」と今回の「点」のdiffだけが価値を持つ。
そしてLinusの個人的ツールであるGitも、この流れなわけだ。
とはいえ俺はルート情報はまた別に重要だと思うから、保持したい。
混ぜ込まれてる場合は後からbranchを追加することが絶対に出来ない。
まあ開発ツールとしては別経路から同じ点に到達しました！なんてのは現実的にあり得ないから、
偽造を防ぐ為にもこれでいいのかもしれんが、一般的に考えればこの実装は奇妙だ。
ちなみに一般文書、例えばEULA(EndUserLicenseAgreement)とかの隙を潰していくタイプの法務文書等は、
別経路だが最終到達時点は同じ、ということが普通にあり得るはず。
だからやっぱりGitはソースコード向けにしか出来てない、ということは認識しておくべきだろう。
945: デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2022/11/06(日) 09:32:57.06 ID:OfQ8ymDc0(2/24) AAS
あと、Gitのドキュメントは全般的によく出来ているが、branchは「線だ！」と言ってるのは不適切だ。
Gitのドキュメントは密結合状態、つまりGitをよく知ってる人向けに書かれているので、
同様に内部実装を見せる形で書くのが正しく、
つまり、「branchは『線』のように見せてますが、実は『点』です！」と言わないと誤解される。俺がそうだが。
これは解像度が統一されてないから起こった問題だ。
一般のマニュアルは疎結合状態、
つまりそのツールについて内部実装なんて全く知らないし知る由もない人向けに書かれるから、
『見た目』線であれば「線」とずっと言い張り、内部実装を曝露してはいけない。
この場合、あくまでユーザーから見たら常に「線」であり、内部がどうであれ「線」としてしか見えないから誤解を生む余地はない。
Gitの場合は内部も見せた上でドキュメントとして外面仕様も説明することになってて、
それが外面仕様なのか内部実装なのか、
またbranchのように外面仕様と内部実装が異なってて隠蔽しきれてない場合とか、(--no-ffの有無で観測可能)
それは正しく説明しなければならない。
密結合なら、上記の通り、「『線』として見せてますが実は『点』です！」と書くべきだ。
とはいえ全般的にドキュメントはしっかり書かれている。これ自体は素晴らしい。
ただ、そもそも仕様がグダグダ過ぎるし、
或いはユーザーにどこまで見せ、どこからは見せないのか、仕様を管理する感覚がまるでない。
おそらく上層部の連中に仕様管理の経験者がおらず、グダグダになってしまってる。
とはいえ、再度言うが、ドキュメントはよく書いてる方だよ。
946: デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2022/11/06(日) 09:33:22.07 ID:OfQ8ymDc0(3/24) AAS
ただこれだと、branchを「線」として扱おうとしたら動作が不安定になるわけで、
おそらくfilter-branchが不安定なのはこの辺に起因してる。
そしてドキュメントの何処か(多分showかlog)に、
「これには実はpitfallがあって、マージに遭遇した場合に分岐するから云々」とかいう
(当時の俺にとって)謎の記述が挿入されてたのも納得がいく。
commit履歴を保持してないから確定的動作が出来ないんだよ。
これははっきり言って仕様の欠陥で、commit履歴も完全に保持する仕様だったら自然と回避出来てた。
現仕様では、filter-branchの実装をいくら頑張ったところでどうにもならない。
代わりのfilter-repoも、動作は同様に糞だろうよ。安定して使えるものではないはず。
ここら辺はちょっと惜しいね。Gitが素晴らしいのは、「伽藍とバザール」での
> 9. 賢いデータ構造と間抜けなコードのほうが、その逆よりずっとまし。
を体現してるからであって、つまり根っこがしっかりしてるから上部は雑草でも問題なかったんだが、
この点は根っこが駄目だから、上部(filter-branch)が機能しない。
ここら辺はちゃんと仕様の大切さを理解してる奴が仕切らないと駄目なのだが、
おそらくGitの連中も、仕様を捏ねてる連中は手を動かしてないと見なし、嫌ってるのだろう。
だから仕様を捏ねることすらしてない。
ただ、それは結局は遠回りでしかない。
今のGitだと、filter-branchも、filter-repoも、その次に出てくる何かも、まともに動作するはずがない。
駄目な仕様だと実装をいくら頑張ってもどうにもならない、と知ってる奴が、ちゃんと仕切らないといけないんだけどね。
ただこれは、それを知らない奴にとってはムカつく奴でしかなく、そいつらを排除した結果、Gitは暴走中、というわけだ。
Linusがcommit履歴も大切に考える奴だったら違ってたが、惜しいね。
947(1): デフォルトの名無しさん (ﾜｯﾁｮｲ debb-qVfh) [sage] 2022/11/06(日) 10:57:26.83 ID:FBkt/oHG0(1/8) AAS
長々と無駄な長文と大量投稿でスレを穢すんじゃねー。
単に既存のバージョン管理ツールと、git の考え方の違いが理解できてないだけじゃねーか。
・git はパッチ管理ツール、作業履歴管理ツールじゃない。
・ソフトウェアはパッチとパッチを当てる順番で構成されている。
1000回唱えろ。この思想が気に要らなければそもそも git 使うな。
948(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2022/11/06(日) 10:59:15.02 ID:OfQ8ymDc0(4/24) AAS
>>943
と思ったが、ffじゃないとhashが違うからウザいな。別物扱いだから、一々確認いるし。
オブジェクトツリーはffの方がいい。
ただこれだとcommit履歴が無く、俺的にはまずいので、別に保存したい。
ソースと混ざるとウザイので、可能なら分離したい。
ドキュメントによるとマルチルートも出来るらしいが、これはどうやってやるんだ？
> Each project must have at least one root. A project can also have multiple roots, though that isn’t common (or necessarily a good idea).
949(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2022/11/06(日) 11:04:28.51 ID:OfQ8ymDc0(5/24) AAS
>>947
> ・git はパッチ管理ツール、作業履歴管理ツールじゃない。
ああ非常に納得出来る。Gitはmerge特化型だ。
確かにそれを日々の業務(非merge)に使おう、というのがフィットしないんだろうよ。
しかし世の中の一般人のGitの使い方は後者だろ。
950(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 515f-pSqO) [sage] 2022/11/06(日) 11:33:11.11 ID:sj15aRfA0(1/4) AAS
ということにしたいのですね。
上下前次1-新書関写板覧索設栞歴
あと 52 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.039s