[過去ﾛｸﾞ] Git 18 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
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みたいに本体を記録してる方が断然強い。
だから基本は「一番大事なもの」で記録するようにしなければいけない、という観点だったのだけど、
まあこれはフォールトトレラントにしろという話で、ちょっと蛇足ではあったね。
あまり関係ないからこの話は終わりで。
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がデータを差分というかたちで持っていると、ブランチを切ってマージする時に差分をいちいち計算しなければなりません。
しかしスナップショットで保存しておけば、差分の計算をしなくて済む分、とても速くブランチを切ったりマージできるようになります。
ちなみに、Git以前のバージョン管理ツールの多くは差分としてデータを保存していて、ブランチを切るのに大変時間がかかっていました。
大規模なプロジェクトになると数十秒かかったりすることもありました。
Gitだとこの作業が一瞬でできます。こういった事情があって、Linuxの作者のリーナス・トーバルズは
当時、大規模開発であったLinuxカーネル開発のバージョン管理システムを自作しました。これがGitのスタートです。
898(3): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/05(土)18:56 ID:646uiMLL0(17/38) AAS
>>886
ああなるほど、ブロックチェーンよろしく親のhashデータも自分のhashに入ってるのか。
しかしそれは、改竄がばれるだけで、リンクを繋ぎ直すことが出来ないわけではないね。
というかね、それは本体ツリーの話で、
余分なcommitはrepoから消せ！とする君らにとっては問題だが、
俺みたいに、スカスカのINDEXでbranchを再構成するのはその場合にも全く問題ないはず。
ところで、
実は今もbranchの実体がどこにあるのか見えてない。
見る限り .git/logs/refs/heads/各branchにしかなさそうなのだけど、ここかね？
これだと毎回reflogを動的に解釈することになるが。
実装としておかしくはないが、普通はこうはしないので、ちょっと不可解だ。
なおオブジェクトツリーにはbranchのデータは無く、branchは各オブジェクトへのリンクの入った配列だと見てる。
だからシャローコピーでしかなく、後からでもいくらでも作れるだろ、という話。
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も計算し直すことになりそれはもう自分ではない
ブランチの実体はコミットオブジェクトのハッシュひとつだけ
それで事足りる
ず〜〜〜と思っているんだがどう考えてもお前のブランチへの理解はオカシイ
内部的な構造の話ではなくてユーザとして使う上でも問題があるような酷い理解に見える
だから >>815 みたいな謎発言がでてくる
DBのINDEXみたいなもの？とかの謎解釈で突き進まれてもついていけない
903(1): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/05(土)20:06 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) 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
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) 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
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) 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
$ git branch
develop
* master
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
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) 2022/11/05(土)21:53 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) 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
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) 2022/11/05(土)22:02 ID:646uiMLL0(28/38) AAS
>>909
ついでに一応、終了時のtest.txt
$ cat test.txt
initial
impl0
impl1
impl2
impl3
impl4
impl5
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} が違うものだという経路情報は、
どこにあるのか分かれば教えてくれ。
上下前次1-新書関写板覧索設栞歴
あと 83 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.031s