Git 18

[過去ﾛｸﾞ] Git 18 (1002ﾚｽ)
上下前次 1-新

このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索歴削→次ｽﾚ栞削→次ｽﾚ過去ﾛｸﾞﾒﾆｭｰ

921(1): (ﾜｯﾁｮｲ 09e4-chQ5) 2022/11/05(土)22:30 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) 2022/11/05(土)22:35 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) 2022/11/05(土)22:40 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) 2022/11/05(土)22:46 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) 2022/11/05(土)22:50 ID:zDjINlW+0(16/26) AAS
>>922
masterブランチをdevelopブランチにマージする方法が
git switch masterとgit merge developの連続実行だけではないし、
HEAD@{n}は適当なタイミングでGCされるから、
HEAD@{n}をそんな用途に使う奴はいない

926(2): (ﾜｯﾁｮｲ 09e4-chQ5) 2022/11/05(土)22:52 ID:zDjINlW+0(17/26) AAS
>>924
commit履歴がどこにあるか説明するのに使いたいから、git log --graph --branches --oneline してくれ

927: (ﾜｯﾁｮｲ 09e4-chQ5) 2022/11/05(土)22:54 ID:zDjINlW+0(18/26) AAS
@はcommit履歴じゃなくて、reflogの履歴

928(1): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/05(土)22:57 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) 2022/11/05(土)23:01 ID:zDjINlW+0(19/26) AAS
@{n}はカレントブランチのreflog履歴になるはず
reflog履歴はブランチ毎に存在するので
master@{n}とdevelop@{n}は違うハッシュになってるはず
git reflog masterとgit reflog developで比べてみればわかる

931(1): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/05(土)23:08 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 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) 2022/11/05(土)23:11 ID:zDjINlW+0(21/26) AAS
>>930
￥で表示されるとちょっと見にくいが、慣れれば見やすい

934: (ﾜｯﾁｮｲ 09e4-chQ5) 2022/11/05(土)23:14 ID:zDjINlW+0(22/26) AAS
>>931
逆だ。コミットのつながりはコミットオブジェクトの中にしかない >>932 みたいにね
それを説明してるのが >>902

935(1): (ﾜｯﾁｮｲ 09e4-chQ5) 2022/11/05(土)23:16 ID:zDjINlW+0(23/26) AAS
>>930は最後のdevelopのマージが --no-ff になってないな
最後のも --no-ff にするともっと面白いぞ

936(1): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/05(土)23:18 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) 2022/11/05(土)23:21 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) 2022/11/05(土)23:23 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) 2022/11/05(土)23:26 ID:zDjINlW+0(25/26) AAS
>>937 だとこう表示されるはず
$ git log --graph --branches --oneline --オプション忘れた探せ
* 2fb59f1 (HEAD -> master) Merge branch 'develop'
* 832f464 initial

940: (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/05(土)23:35 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) 2022/11/05(土)23:41 ID:zDjINlW+0(26/26) AAS
>>939がそう表示されるのは、--no-ff マージの手順が何か普通とちがうからかもしれん
>>939みたいに表示させるマージの手順もあるはずだから工夫してみるんだな

942: (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/05(土)23:41 ID:646uiMLL0(38/38) AAS
>>938
なるほど了解した。
データ側に混ぜ込んでて、保持したければ --no-ff で使えってことか。

そもそも同じハッシュなら同じgitオブジェクトにリンクするようになってるのだし、
(つまり見た目が膨らんでるだけで実際の容量は大して食わない）
--no-ff がデフォのほうがよかった気がするが。

まあとにかく了解した。長々とありがとう。

943(2): (ﾜｯﾁｮｲ 527c-zlm6) 2022/11/06(日)00:38 ID:UPUgwCSv0(1) AAS
FFがデフォじゃなと使いにくい気がするのだがｗ

944: (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)09:32 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) 2022/11/06(日)09:32 ID:OfQ8ymDc0(2/24) AAS
あと、Gitのドキュメントは全般的によく出来ているが、branchは「線だ！」と言ってるのは不適切だ。
Gitのドキュメントは密結合状態、つまりGitをよく知ってる人向けに書かれているので、
同様に内部実装を見せる形で書くのが正しく、
つまり、「branchは『線』のように見せてますが、実は『点』です！」と言わないと誤解される。俺がそうだが。
これは解像度が統一されてないから起こった問題だ。
一般のマニュアルは疎結合状態、
つまりそのツールについて内部実装なんて全く知らないし知る由もない人向けに書かれるから、
『見た目』線であれば「線」とずっと言い張り、内部実装を曝露してはいけない。
この場合、あくまでユーザーから見たら常に「線」であり、内部がどうであれ「線」としてしか見えないから誤解を生む余地はない。
Gitの場合は内部も見せた上でドキュメントとして外面仕様も説明することになってて、
それが外面仕様なのか内部実装なのか、
またbranchのように外面仕様と内部実装が異なってて隠蔽しきれてない場合とか、(--no-ffの有無で観測可能)
それは正しく説明しなければならない。
密結合なら、上記の通り、「『線』として見せてますが実は『点』です！」と書くべきだ。
とはいえ全般的にドキュメントはしっかり書かれている。これ自体は素晴らしい。
ただ、そもそも仕様がグダグダ過ぎるし、
或いはユーザーにどこまで見せ、どこからは見せないのか、仕様を管理する感覚がまるでない。
おそらく上層部の連中に仕様管理の経験者がおらず、グダグダになってしまってる。
とはいえ、再度言うが、ドキュメントはよく書いてる方だよ。

946: (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)09:33 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) 2022/11/06(日)10:57 ID:FBkt/oHG0(1/8) AAS
長々と無駄な長文と大量投稿でスレを穢すんじゃねー。
単に既存のバージョン管理ツールと、git の考え方の違いが理解できてないだけじゃねーか。
・git はパッチ管理ツール、作業履歴管理ツールじゃない。
・ソフトウェアはパッチとパッチを当てる順番で構成されている。
1000回唱えろ。この思想が気に要らなければそもそも git 使うな。

948(1): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)10:59 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) 2022/11/06(日)11:04 ID:OfQ8ymDc0(5/24) AAS
>>947
> ・git はパッチ管理ツール、作業履歴管理ツールじゃない。
ああ非常に納得出来る。Gitはmerge特化型だ。
確かにそれを日々の業務(非merge)に使おう、というのがフィットしないんだろうよ。

しかし世の中の一般人のGitの使い方は後者だろ。

950(1): (ﾜｯﾁｮｲ 515f-pSqO) 2022/11/06(日)11:33 ID:sj15aRfA0(1/4) AAS
ということにしたいのですね。

上下前次 1-新書関写板覧索設栞歴

あと 52 ﾚｽあります
ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ

ぬこの手ぬこTOP 0.024s