[過去ﾛｸﾞ] Git 18 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
859(2): (ｱｳｱｳｳｰ Sacd-EsyA) [age] 2022/11/05(土)14:42 ID:oTMzuhJSa(1) AAS
>>858
それなんて、俺の前の職場
860(1): (ﾜｯﾁｮｲ 6914-pSqO) 2022/11/05(土)14:46 ID:0q4aURph0(7/9) AAS
データの取り出し方なんか知っていても
過去のコミットのミスを簡単に直せないなら
バージョン管理は苦痛になるし
やっぱりツールの使い方だけ知ってバージョン管理をしたことがないんだろうな
バージョン管理が不便だからgitが作られたんだぞ
861: (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/05(土)14:58 ID:646uiMLL0(7/38) AAS
>>859
俺はそれでいいと思うけど。
記録してない方が問題で、記録さえしてあれば、ゴミとマジを簡単に分離出来れば十分だ。
>>860
今のGitの修正は十分苦痛だよ。
修正させたくないから面倒にする、は間違いで、
簡単に修正出来るが、修正したことも履歴に残るようにする、が正しい。
862(1): (ﾜｯﾁｮｲ 6914-pSqO) 2022/11/05(土)15:03 ID:0q4aURph0(8/9) AAS
× 俺はそれでいいと思うけど。
○ 無能はそんなことをしている。
まずさぁ、gitというかバージョン管理の基本を理解してないんだからさ
そこから勉強しなよ
863(1): (ﾜｯﾁｮｲ 6914-pSqO) 2022/11/05(土)15:04 ID:0q4aURph0(9/9) AAS
> 簡単に修正出来るが、修正したことも履歴に残るようにする、が正しい。
お前はテキストエディタで保存するたびに
gitにセーブしろって言ってんのか？ｗ
864(2): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/05(土)16:06 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='';
省12
865: (ﾜｯﾁｮｲ 6914-pSqO) 2022/11/05(土)16:10 ID:5Oe/8sYX0(1/24) AAS
>>864
アホなの？コミットメッセージは毎回入れるものだ
866: (ﾜｯﾁｮｲ 6914-pSqO) 2022/11/05(土)16:11 ID:5Oe/8sYX0(2/24) AAS
>>864
> 全世界でLinuxと同じワークフローが適切なわけではない。
だからgitはいろんなワークフローに対応してるんだろうが
お前のはバージョン管理のワークフローではない
ただのバックアップのワークフローだ
867: (ﾜｯﾁｮｲ 5e8f-gUJl) 2022/11/05(土)16:45 ID:CLSrxuim0(2/2) AAS
まあ1人プロジェクトみたいだし好き勝手やらせればいいさ
868: (ﾜｯﾁｮｲ 6914-pSqO) 2022/11/05(土)16:54 ID:5Oe/8sYX0(3/24) AAS
コミットメッセージが空だったら～とかわけわからんなｗ
869(1): (ﾜｯﾁｮｲ 6914-pSqO) 2022/11/05(土)16:56 ID:5Oe/8sYX0(4/24) AAS
行単位で独立してるデータベースのデータじゃないんだからさぁ
ソースコードは前後の歴史とつながってる
DELETEなんちゃらみたいに一つだけ取り除くことが出来るのは稀
870(1): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/05(土)17:21 ID:646uiMLL0(9/38) AAS
>>869
それは当然UIの話で、当たり前だが内部のリンクは接続し直すんだよ。
そしてそれをユーザーには見せない。
多分ここら辺の階層の話がGitには存在しないんだよ。
だからユーザーがviでリンク書き換えろとかの勢いだろ。
超密結合だし滅茶苦茶だよそれは。
871(1): (ﾜｯﾁｮｲ 6914-pSqO) 2022/11/05(土)17:22 ID:5Oe/8sYX0(5/24) AAS
>>870
都合が悪いからって無視するな
前後のソースコード関連してるから
途中のコミットを取り除くことはできないと言ってる
872: (ﾜｯﾁｮｲ 0d4e-GJ//) 2022/11/05(土)17:28 ID:B2i8Nuif0(1) AAS
つまり、両親がイブに中出ししてお前が生まれたという歴史において、
イブの中出しだけを無かったことにはできないと言うことだね
その後の歴史でお前が存在するのはおかしいし
873(3): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/05(土)17:30 ID:646uiMLL0(10/38) AAS
>>871
何言ってんだ？
中身はただの単方向リンクリストだぞ。
リンク先が複数のこともあるが、それでも問題なく抜ける。
ただそれ以前に、俺は既に言ったとおり「記録されてないほうが問題」とするので、
CREATE INDEXを使うが。これなら理解出来るか？
だったら、このINDEX対象をちょうど全部含むようにリンクリストを新しく作り直せばいいだけ。
省1
874(1): (ﾜｯﾁｮｲ 6914-pSqO) 2022/11/05(土)17:40 ID:5Oe/8sYX0(6/24) AAS
>>873
じゃあ抜き取ってみ
・commit 1「aaa を追加」
aaa
・commit 2「bbb を追加」
aaa
bbb
省5
875(1): (ﾌﾞｰｲﾓ MM96-1bV6) 2022/11/05(土)17:44 ID:W/77BOuWM(2/2) AAS
>>873
残念だけどそこから間違ってる
Gitのコミットのリストは単方向リンクリストではない
なのでリストの途中のコミットを削除したり途中に追加できない
876(2): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/05(土)17:58 ID:646uiMLL0(11/38) AAS
>>874
ああコミットメッセージについては考えてなかったが、
俺ならそのままぐちゃっと貼り付けるけど。
つまり、
・commit 1「aaa を追加」
aaa
・commit 3「bbb を追加」「bbb を ccc に置き換えた」
省3
877(1): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/05(土)18:03 ID:646uiMLL0(12/38) AAS
>>875
親が複数あるだけの単方向リストだよ。
まあこれを単方向リストと呼ぶかは微妙だから、ツリーと言った方が通じたか？
ツリーが複数重なり合った状態になってるだけだよ。
単線の A<-B<-C なら A<-C になる。これは自明だよな。
マージの場合、(BがADのマージ結果ね）
A<-B<-C
省5
878(1): (ﾜｯﾁｮｲ 6914-pSqO) 2022/11/05(土)18:18 ID:5Oe/8sYX0(7/24) AAS
>>876
ようやく理解したか。
だからお前がやってるのはただのバックアップを取ってるだけだっていってんだよ
バージョン管理というのは何をどう変えたかという変化を記録するものだ
スナップショットじゃねーんだよ、あーほ
879: (ﾜｯﾁｮｲ 6914-pSqO) 2022/11/05(土)18:19 ID:5Oe/8sYX0(8/24) AAS
>>876
bbbの話がないのだから、
書き間違えなのか全く区別がつかない
バグコミットメッセージだな
880(1): (ﾜｯﾁｮｲ 6914-pSqO) 2022/11/05(土)18:21 ID:5Oe/8sYX0(9/24) AAS
>>873
> ただそれ以前に、俺は既に言ったとおり「記録されてないほうが問題」とするので、
だからお前のテキストエディタでの変更内容を全部記録するって言ってるんだろ？
ファイルを保存するたびにコミットするんだろお前は？
バージョン管理で記録するのはソースコードの修正履歴であって
お前個人の作業履歴じゃねーんだよ
使い物にならないゴミコミットを作るな
881(1): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/05(土)18:26 ID:646uiMLL0(13/38) AAS
>>878
ああ履歴についての認識が違うんだな。了解した。
履歴は、
俺： スナップショット＝「点」の並び
君： 変更した線の並びで、それはcommitメッセージに現れる。
それだと、commitメッセージが間違ってる場合はどうしようもなくなるだろ。
あくまでソースコードが重要で、どこをどう変えたかはdiff取れば済むだけの話、
省3
882(1): (ﾜｯﾁｮｲ 6914-pSqO) 2022/11/05(土)18:31 ID:5Oe/8sYX0(10/24) AAS
>>881
> 履歴は、
> 俺： スナップショット＝「点」の並び
だから、それはバックアップで言うって最初から言ってるだろ
お前が完全に間違ってるんだよ
> それだと、commitメッセージが間違ってる場合はどうしようもなくなるだろ。
修正しろよ。それが出来るように作られているだろ
省3
883(2): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/05(土)18:32 ID:646uiMLL0(14/38) AAS
>>880
> ファイルを保存するたびにコミットするんだろお前は？
そこまではしないが、1日10回とか平気ですることもあるし、それが問題だとも思わない。
この辺はポリシーだし、好きなようにすればいいと思うがね。
間違いなく言えるのは、俺は美しいソースコードを目指しているのであって、
美しいコミット履歴を目指しているわけではないんだよ。
そしてコミット履歴が過剰なら、落とせばいいだけだろ、という話。
省2
884(1): (ﾜｯﾁｮｲ 6914-pSqO) 2022/11/05(土)18:32 ID:5Oe/8sYX0(11/24) AAS
> Gitもこちらの立場に近く、VCSとしては珍しく(と聞いているが俺はそこまで詳しくないが）
> 差分ではなく本体を記録するだろ。
だから最初からバージョン管理は差分を記録するものであり
gitの優れた点が、発想の転換で
本体を記録することで差分を表現することにした点なんだろ
実装の話とごっちゃにするな
そういうところが技術的に未熟なんだよ
885: (ﾜｯﾁｮｲ 6914-pSqO) 2022/11/05(土)18:33 ID:5Oe/8sYX0(12/24) AAS
>>883
> そこまではしないが、1日10回とか平気ですることもあるし、それが問題だとも思わない。
そりゃお前が素人だから問題であることに気づいてないだけ
誰もやってないからね
> この辺はポリシーだし、好きなようにすればいいと思うがね。
お前が未熟だから反論できずにポリシーってことにしようとしてる
886(1): (ﾜｯﾁｮｲ 09e4-chQ5) 2022/11/05(土)18:33 ID:zDjINlW+0(6/26) AAS
>>877
分散バージョン管理ではですね、リポジトリのコピーがばらばらに複数存在することが前提なので、
あるひとつのリポジトリのコミット履歴が A<-B<-C で、他のリポジトリではこれが A<-C になっているという状況は不味いんですよ
なのでGitではそれができないようにデータ構造が設計されています
887: (ﾜｯﾁｮｲ 6914-pSqO) 2022/11/05(土)18:34 ID:5Oe/8sYX0(13/24) AAS
> 間違いなく言えるのは、俺は美しいソースコードを目指しているのであって、
> 美しいコミット履歴を目指しているわけではないんだよ。
コミット履歴は「使うもの」だって分かってないようだな
一部のコミットだけ抜き取って
他のブランチに組み込む
使うものだ
お前はただ見れればいいと思ってる
省1
888: (ﾜｯﾁｮｲ 6914-pSqO) 2022/11/05(土)18:35 ID:5Oe/8sYX0(14/24) AAS
>>883
> 所詮commitメッセージなんて当てにならないし、diffが取れれば全く問題ない。
お前が作るコミットがクソだから、使いものにならなくなっているだけだなｗ
889(1): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/05(土)18:39 ID:646uiMLL0(15/38) AAS
>>882
まあ君と仕事することは無さそうだから別に問題ないけど、
> 修正しろよ。それが出来るように作られているだろ
コミットメッセージをいくら修正したところでそもそも意味無いんだよ。
管理してるのはメッセージじゃなくてソースコードなんだから。
それで、重要なコメントはソースコード上に書いてるから、diff取れれば十分なんだよ。
コミットメッセージは、あくまでGit上から探し出すラベルでしかなくて、何をやったかはdiffで見るし、それ以外にないよ。
省3
890: (ﾜｯﾁｮｲ 6914-pSqO) 2022/11/05(土)18:40 ID:5Oe/8sYX0(15/24) AAS
> コミットメッセージをいくら修正したところでそもそも意味無いんだよ。
それはお前だけの感想ですねｗ
891: (ﾜｯﾁｮｲ 6914-pSqO) 2022/11/05(土)18:41 ID:5Oe/8sYX0(16/24) AAS
> まあ俺はGitの達人になりたいわけでもないんで、これで問題ないよ。
バージョン管理の素人だって言ってる
お前、他の人と一緒に仕事ができないよｗ
892: (ﾜｯﾁｮｲ 6914-pSqO) 2022/11/05(土)18:41 ID:5Oe/8sYX0(17/24) AAS
> コミットメッセージは、あくまでGit上から探し出すラベルでしかなくて、何をやったかはdiffで見るし、それ以外にないよ。
途中を抜いといて、何をやったかなんてわかるわけ無いだろｗｗｗ
893: (ﾜｯﾁｮｲ 6914-pSqO) 2022/11/05(土)18:43 ID:5Oe/8sYX0(18/24) AAS
>>889
こうやってコミット履歴をちゃんと見れて
なんの変更をしたのかわかるようになるまで頑張れよ
外部ﾘﾝｸ:github.com
お前のコミットは汚すぎて
使い物にならんのだわ
894: (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/05(土)18:44 ID:646uiMLL0(16/38) AAS
>>884
> gitの優れた点が、発想の転換で
> 本体を記録することで差分を表現することにした点なんだろ
これは違う。
というかね、どっちを記録したところで、正常に動いていればどのみち任意の履歴を取り出せるから関係ないんだ。
ただ、ファイルシステム等がぶっ壊れて、断片的にしか取り出せなくなったときに、Gitみたいに本体を記録してる方が断然強い。
だから基本は「一番大事なもの」で記録するようにしなければいけない、という観点だったのだけど、
省2
895: (ﾜｯﾁｮｲ 6914-pSqO) 2022/11/05(土)18:45 ID:5Oe/8sYX0(19/24) AAS
> これは違う。
だーかーら、素人のお前の意見なんか聞いてない
896: (ﾜｯﾁｮｲ 6914-pSqO) 2022/11/05(土)18:50 ID:5Oe/8sYX0(20/24) AAS
> ただ、ファイルシステム等がぶっ壊れて、断片的にしか取り出せなくなったときに、
gitは速度のためにスナップショットにしてると書いています
外部ﾘﾝｸ:git-scm.com
897: (ﾜｯﾁｮｲ 6914-pSqO) 2022/11/05(土)18:53 ID:5Oe/8sYX0(21/24) AAS
外部ﾘﾝｸ:www.techpit.jp
なぜスナップショットとして記録するのか
スナップショットとして記録することで、複数人で開発する時のスピードを上げることができます。
詳しくは後ほど解説しますが、複数人での開発の際、並行して開発できるよう、
Gitではブランチというものを切って、バージョンを枝分かれさせて開発していきます。
このブランチでバージョンを枝分かれさせる際や、ブランチを統合(マージ)する際にスナップショットだと非常に作業が速くできます。
Gitがデータを差分というかたちで持っていると、ブランチを切ってマージする時に差分をいちいち計算しなければなりません。
省5
898(3): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/05(土)18:56 ID:646uiMLL0(17/38) AAS
>>886
ああなるほど、ブロックチェーンよろしく親のhashデータも自分のhashに入ってるのか。
しかしそれは、改竄がばれるだけで、リンクを繋ぎ直すことが出来ないわけではないね。
というかね、それは本体ツリーの話で、
余分なcommitはrepoから消せ！とする君らにとっては問題だが、
俺みたいに、スカスカのINDEXでbranchを再構成するのはその場合にも全く問題ないはず。
ところで、
省6
899: (ﾜｯﾁｮｲ 6914-pSqO) 2022/11/05(土)19:03 ID:5Oe/8sYX0(22/24) AAS
> 後からでもいくらでも作れるだろ、という話。
だから速度重視だって言ってる
900: (ﾜｯﾁｮｲ 6914-pSqO) 2022/11/05(土)19:03 ID:5Oe/8sYX0(23/24) AAS
>>898
君、ほんと知らないなら黙ってたほうがいいよ
恥ずかしいだけだから
901: (ﾜｯﾁｮｲ 6914-pSqO) 2022/11/05(土)19:05 ID:5Oe/8sYX0(24/24) AAS
>>898
> 余分なcommitはrepoから消せ！とする君らにとっては問題だが、
余分なコミットじゃなくて、
コミットとして使えないものにする
バグコミットを消せと言ってるだけ
902(2): (ﾜｯﾁｮｲ 09e4-chQ5) 2022/11/05(土)19:21 ID:zDjINlW+0(7/26) AAS
>>898
まあもう面倒臭くなってきたので全部説明しちゃうが
結果的に親のhashが自分のhashに含まれることになるのだけど、実際には親のhashは自分のコミットオブジェクトに含まれている
その自分のコミットオブジェクトから計算して求めるのが自分のhash
親の祖先に変更があれば自分のコミットオブジェクトの作り直しになってhashも計算し直すことになりそれはもう自分ではない
ブランチの実体はコミットオブジェクトのハッシュひとつだけ
それで事足りる
省4
903(1): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/05(土)20:06 ID:646uiMLL0(18/38) AAS
>>902
前半の内容は知ってるし、そのつもりで898を書いてる。
それはtutorial2に書いてあったから。
そこのhash値も混ぜてるかどうかは関知してなかっただけ。
ちなみにtutorlal2には「ここのhash値とは違うから、各自のhash値をコピペしてね」
と書いてあるが、実際は同じhash値が生成される。
だからどこまで混ぜ込んでるのかよくわからなった。
省13
904: (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/05(土)20:19 ID:646uiMLL0(19/38) AAS
すまん、分かると思うが、 HEAD~1 != @{1}
905(1): (ﾜｯﾁｮｲ 09e4-chQ5) 2022/11/05(土)20:45 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
省6
906(1): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/05(土)20:59 ID:646uiMLL0(20/38) AAS
>>905
reflogがその形式なのは知ってる。
ただ、頭のポイントだけだと、903で言ったとおり、経路情報にならないだろ。
例えば、815の場合、再記するが、
impl5@feature5, merged to develop and master, add tag of "Version1".
impl4@feathre4
impl3@feature3
省17
907: (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/05(土)21:04 ID:646uiMLL0(21/38) AAS
ちなみに、843の記事では、Git内のcontrib内のスクリプトが、
branchをreflogを参考に復活させるらしいので、reflog内の情報で足りてはいるらしい。
確かに目で見た限りそうだが、
でもそれだとreflogをgcするのは割と狂気の沙汰だから、おかしいよなーと思ってて。
908: (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/05(土)21:06 ID:646uiMLL0(22/38) AAS
ごめん、書き方が悪かった。
907は、gc対象となるreflogを本番情報として持つのは狂気の沙汰だなーということ。
復活させるときにそこにしか手がかりがないのは仕方ないとして、
生きてるbranchは普通はツリー情報をstaticに持ってるはずだが、見あたらないんだよ。
909(6): (ﾜｯﾁｮｲ 09e4-chQ5) 2022/11/05(土)21:15 ID:zDjINlW+0(9/26) AAS
>>906
そのリポジトリがどういう構造になっているかわけわからん
git show-branch してみろ
910: (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/05(土)21:26 ID:646uiMLL0(23/38) AAS
>>909
すまぬ、確かに今見てればちょっとおかしい。
もう一度作るから30分ほどお待ちを。
911(1): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/05(土)21:51 ID:646uiMLL0(24/38) AAS
>>909
結果
$ git show-branch
! [develop] impl5
* [master] impl5
--
+* [develop] impl5
省3
912(2): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/05(土)21:52 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
省17
913(1): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/05(土)21:53 ID:646uiMLL0(26/38) AAS
>>909
再現コード
#!/bin/bash -x
#
git init
echo 'initial' > test.txt
git add test.txt
省15
914(2): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/05(土)22:01 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
省23
915(1): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/05(土)22:02 ID:646uiMLL0(28/38) AAS
>>909
ついでに一応、終了時のtest.txt
$ cat test.txt
initial
impl0
impl1
impl2
省3
916(1): (ﾜｯﾁｮｲ 09e4-chQ5) 2022/11/05(土)22:05 ID:zDjINlW+0(10/26) AAS
>>911-915
これ全部FFマージやってるから結果的にdevelopブランチとmasterブランチが同じものになるぞ
917(1): (ﾜｯﾁｮｲ 09e4-chQ5) 2022/11/05(土)22:09 ID:zDjINlW+0(11/26) AAS
mergeを全部merge --no-ffにするとマージした構造がわかるようになるし、最後にdevelopとmasterが別のものになる
どっちのマージにするかは現場の運用しだい
918: (ﾜｯﾁｮｲ 09e4-chQ5) 2022/11/05(土)22:10 ID:zDjINlW+0(12/26) AAS
git log --graph --branches --oneline とかするとわかりやすい
919: (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/05(土)22:11 ID:646uiMLL0(29/38) AAS
>>916
ああ、それがrebaseしないと履歴が無くなるとかいう話か？
実はそれはまだ確認中だが、とりあえず本件についてはこれでいいし、
俺的には多分こうなる。(基本的にmasterはdevelopの後を追うだけ)
けしからんか？
それはさておき、本件、HEAD~1 と @{1} が違うものだという経路情報は、
どこにあるのか分かれば教えてくれ。
920(1): (ﾜｯﾁｮｲ 09e4-chQ5) 2022/11/05(土)22:22 ID:zDjINlW+0(13/26) AAS
HEAD~1と@{1}は全然関係無いよ？
HEAD~1は今のHEADの一番目の親のhash
親が複数いるときにはHEAD^1とかHEAD^2とかで指定する
@{1}はひとつ前の操作によってHEADになったhashだから、どういう操作したかで変わり、リポジトリの構造とは関係無い
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
省21
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
省11
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を指してる。
省5
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
省2
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で比べてみればわかる
930(3): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/05(土)23:04 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
省22
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
省9
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 が格納されている
省10
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マージで中間をすっ飛ばしてきた、
省3
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
| |\
省24
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 --オプション忘れた探せ
省7
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
上下前次1-新書関写板覧索設栞歴
あと 63 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.029s