[過去ﾛｸﾞ] Git 18 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
1: (ﾜｯﾁｮｲ 9ce4-E6ke) 2022/04/23(土)03:25 ID:HOOXt/T30(1) AAS
ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。
Git - Fast Version Control System
外部ﾘﾝｸ:git-scm.com
◆関連サイト
Pro Git - Table of Contents
外部ﾘﾝｸ:git-scm.com
Git入門
外部ﾘﾝｸ:www8.atwiki.jp
◆前スレ
Git 16©2ch.net
省3
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 に置き換えた」
aaa
ccc
になる。
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
D<-|
を
A<-C
省2
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取れば済むだけの話、
commitメッセージなんて目安に過ぎないんだよ。
Gitもこちらの立場に近く、VCSとしては珍しく(と聞いているが俺はそこまで詳しくないが）
差分ではなく本体を記録するだろ。
882(1): (ﾜｯﾁｮｲ 6914-pSqO) 2022/11/05(土)18:31 ID:5Oe/8sYX0(10/24) AAS
>>881
> 履歴は、
> 俺： スナップショット＝「点」の並び
だから、それはバックアップで言うって最初から言ってるだろ
お前が完全に間違ってるんだよ
> それだと、commitメッセージが間違ってる場合はどうしようもなくなるだろ。
修正しろよ。それが出来るように作られているだろ
> commitメッセージなんて目安に過ぎないんだよ。
はっｗ バージョン管理の素人が。
コミットメッセージの重要性を知らない時点で終わってるよ
883(2): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/05(土)18:32 ID:646uiMLL0(14/38) AAS
>>880
> ファイルを保存するたびにコミットするんだろお前は？
そこまではしないが、1日10回とか平気ですることもあるし、それが問題だとも思わない。
この辺はポリシーだし、好きなようにすればいいと思うがね。
間違いなく言えるのは、俺は美しいソースコードを目指しているのであって、
美しいコミット履歴を目指しているわけではないんだよ。
そしてコミット履歴が過剰なら、落とせばいいだけだろ、という話。
無い履歴からは生成することは不可能なのだから、大きすぎる粒度より、小さすぎる粒度の方がいいに決まってる。
所詮commitメッセージなんて当てにならないし、diffが取れれば全く問題ない。
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
> 間違いなく言えるのは、俺は美しいソースコードを目指しているのであって、
> 美しいコミット履歴を目指しているわけではないんだよ。
コミット履歴は「使うもの」だって分かってないようだな
一部のコミットだけ抜き取って
他のブランチに組み込む
使うものだ
お前はただ見れればいいと思ってる
バージョン管理を理解してない
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で見るし、それ以外にないよ。
> はっｗ バージョン管理の素人が。
> コミットメッセージの重要性を知らない時点で終わってるよ
まあ俺はGitの達人になりたいわけでもないんで、これで問題ないよ。
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以前のバージョン管理ツールの多くは差分としてデータを保存していて、ブランチを切るのに大変時間がかかっていました。
大規模なプロジェクトになると数十秒かかったりすることもありました。
省2
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を動的に解釈することになるが。
省3
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 みたいな謎発言がでてくる
省1
903(1): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/05(土)20:06 ID:646uiMLL0(18/38) AAS
>>902
前半の内容は知ってるし、そのつもりで898を書いてる。
それはtutorial2に書いてあったから。
そこのhash値も混ぜてるかどうかは関知してなかっただけ。
ちなみにtutorlal2には「ここのhash値とは違うから、各自のhash値をコピペしてね」
と書いてあるが、実際は同じhash値が生成される。
だからどこまで混ぜ込んでるのかよくわからなった。
名前と時間も混ぜ込んでるぜ！と書いてあるが、どう見てもそうじゃない。
ただまあ、親ハッシュは混ぜ込んでるのは理解した。
> ブランチの実体はコミットオブジェクトのハッシュひとつだけ
省10
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
省3
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
省14
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
省14
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++ ));
省12
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
省20
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} が違うものだという経路情報は、
どこにあるのか分かれば教えてくれ。
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
index 3585d98..bbddc42 100644
--- a/test.txt
+++ b/test.txt
省18
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 をやったときにはこうなっていたはず
省8
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
省2
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で比べてみればわかる
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
|/
* 324df68 Merge branch 'feature4' into develop
|\
省19
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
省6
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
省7
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
省21
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
省4
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
省10
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履歴は要らない、と考えていることになる。
ただこれは奇妙な実装だ。
省14
945: (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)09:32 ID:OfQ8ymDc0(2/24) AAS
あと、Gitのドキュメントは全般的によく出来ているが、branchは「線だ！」と言ってるのは不適切だ。
Gitのドキュメントは密結合状態、つまりGitをよく知ってる人向けに書かれているので、
同様に内部実装を見せる形で書くのが正しく、
つまり、「branchは『線』のように見せてますが、実は『点』です！」と言わないと誤解される。俺がそうだが。
これは解像度が統一されてないから起こった問題だ。
一般のマニュアルは疎結合状態、
つまりそのツールについて内部実装なんて全く知らないし知る由もない人向けに書かれるから、
『見た目』線であれば「線」とずっと言い張り、内部実装を曝露してはいけない。
この場合、あくまでユーザーから見たら常に「線」であり、内部がどうであれ「線」としてしか見えないから誤解を生む余地はない。
Gitの場合は内部も見せた上でドキュメントとして外面仕様も説明することになってて、
省9
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が素晴らしいのは、「伽藍とバザール」での
省11
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
ということにしたいのですね。
951: (ﾜｯﾁｮｲ debb-qVfh) 2022/11/06(日)11:46 ID:FBkt/oHG0(2/8) AAS
>>949
お前の狭い世間なんて知るか
お前は話題の電動ドリル買ってきて釘打つのに不便ガンガンってやりながら文句言ってるのと同じレベル
そもそもマニュアルもちゃんと読めてないだろ。root と route を間違える英語レベル
背伸びして git 学ぶ前に高校に進学して英語学んだ方が近道だぞ
952(1): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)11:51 ID:OfQ8ymDc0(6/24) AAS
>>950
いや事実だよ。
Linusは確かにmergeしかしないんだろうけど。
だけどその、mergeするパッチを書く奴は、それを一発で書けたわけがないんだ。
何日もかけて、何回も直して、そこに到達してる。
この過程のサポートがGitにはない。
別branchで作業してもmerge時にhash値が組み込まれるから、
確かに俺がやろうとしてる「日々の進捗」をcommitされると除去出来ずウザイんだろうさ。
しかしパッチのコードは必ずGit-repoをクローンしてから出発するのだから、
Gitにこのサポートが無く、パッチを当てる人はいきなり完成したパッチを書け！勿論でバッグ済みだぞ！みたいな構造なのがおかしい。
省9
953(1): (ﾜｯﾁｮｲ debb-qVfh) 2022/11/06(日)12:07 ID:FBkt/oHG0(3/8) AAS
>>952
アホか。共同開発が全く理解できてねーじゃねーか。
お前の試行錯誤の記録を push しようとしてんじゃねーよ。
手元で試行錯誤して実装できたら、それを元に綺麗なパッチに書き直す作業するんだよ。
そして完成した綺麗なパッチ群のみを共有リポジトリに公開するんだよ。
954(1): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)12:19 ID:OfQ8ymDc0(7/24) AAS
>>948
一応見つけた。 git worktree らしい。
複数のbranchを同時に開く機能で、DBで言うATTACHっぽい。
955(1): (ﾜｯﾁｮｲ b114-pSqO) 2022/11/06(日)12:20 ID:JyiC8cnE0(1/6) AAS
試行錯誤はすべて記録に残すべき
→じゃあテキストエディタで保存するたびに記録するべきっていうのか？
こういう話なので無視すんなよ？ｗ
956: (ﾜｯﾁｮｲ b114-pSqO) 2022/11/06(日)12:21 ID:JyiC8cnE0(2/6) AAS
バージョン管理はソースコードの変更履歴を残すのであって
作業履歴を残すものじゃないっていうのが分かってなさすぎ
957(2): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)12:30 ID:OfQ8ymDc0(8/24) AAS
>>953
それはいいんだけどさ、その肝心のパッチを書く人へのサポートがまるでないだろ。
出発点がgit clone で、その上で作業して、終われば pull request する前提なのにさ。
そしてOSSではなく一般企業等で使ってる奴は、
当たり前だが日々の作業のバックアップや巻き戻し出来るシステムが必要で、そう使ってる。
だから、Gitが難しすぎるというのは、目的外使用だから意味が分かりにくい、というのはあるね。
Indexもマージの時にはあった方が便利なんだろうしさ。(ただのcommitには邪魔でしかない）
しかし確かに、Linusに言わせれば、全く問題ないんだろうさ。彼はmergeしかしないしね。
そして他のVCSよりまし、という理由でGitを使う奴は、混乱するんだろうさ。VCSと聞いてきたのだからね。
確かにパッチ管理システムだよGitは。ソースコード生成時のサポートシステムではない。
958(1): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)12:32 ID:OfQ8ymDc0(9/24) AAS
>>955
> こういう話なので無視すんなよ？ｗ
無視する/しない以前に、何が言いたいのか分からないから反応しようがないんだよ。
959: (ﾜｯﾁｮｲ 515f-pSqO) 2022/11/06(日)12:42 ID:sj15aRfA0(2/4) AAS
>>957
> それはいいんだけどさ、その肝心のパッチを書く人へのサポートがまるでないだろ。
rebase あるよ。
元のローカルブランチを消さないでおけば記録もぜんぶ残るし。よかったね。
960(1): (ﾜｯﾁｮｲ debb-qVfh) 2022/11/06(日)12:43 ID:FBkt/oHG0(4/8) AAS
>>957
git ほどパッチを書くのに向いてるツールは他にないぞ。
index 無しでどうやってパッチの分割とかするんだよ？
961(2): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)12:53 ID:OfQ8ymDc0(10/24) AAS
>>960
最初から一つずつ書けば分割の必要ないし、
Index無くてもdiffの出力を絞ってpatchに食わせれば普通に分割出来るだろ。
962: (ﾜｯﾁｮｲ b114-pSqO) 2022/11/06(日)13:02 ID:JyiC8cnE0(3/6) AAS
>>958
書いてあるとおりじゃん。
試行錯誤の履歴を全部取れというなら、テキストエディタで保存するごとに
gitでコミットしなければならないはずだ
お前の主張はそういうことなんだから、それをちゃんとやれってこと
963(1): (ﾜｯﾁｮｲ b114-pSqO) 2022/11/06(日)13:04 ID:JyiC8cnE0(4/6) AAS
>>961
コミットがメチャクチャなのに、どうやってdiffとってパッチできると思ってるの？
そのdiffには関係がない修正が大量に入ってるだろ
964(1): (ﾜｯﾁｮｲ debb-qVfh) 2022/11/06(日)13:37 ID:FBkt/oHG0(5/8) AAS
>>961
なんも分かってないことを露呈しているな。
A,B,C,D,Eとコミットした後に Cはc1,c2,c3に分割すべきで、BとEは一つにすべきで、Aは不要だったと気づいたらどうすんの？
こういうのがお手軽にできて綺麗なパッチ群に整理できるのがパッチ管理ツールである git の利点なんだ。
そういうのやったことないだろ？
965(1): (ﾜｯﾁｮｲ 09e4-chQ5) 2022/11/06(日)13:39 ID:az1H5JFk0(1/7) AAS
>>954
脊髄反射で理解したつもりになって書いてるだろ正解率が著しく低い
git worktreeは一つのリポジトリに追加のワークツリーを用意して、異なるブランチをそれぞれ別のワークツリーにcheckoutできるようにする機能
DBのATTACHとは全然違う
マルチルートは普通に作ったリポジトリをfetchやpushで合成してmerge --allow-unrelated-historiesすればできる
でもこれはかなり特殊な用途に使うもので普段使いするようなものではない
966: (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)13:46 ID:OfQ8ymDc0(11/24) AAS
>>965
実は今し方ドキュメント読んで、これは違うと書こうとしたところだった。
wor,ktreeはstashの代わりで、同時作業用ではないね。
> マルチルートは普通に作ったリポジトリをfetchやpushで合成して
ああこれは俺の要求とは違うね。
まあ、もう地味に.git/.xxx/に転がそうと思案中。
967(1): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)13:57 ID:OfQ8ymDc0(12/24) AAS
>>963,964
お前らunixコマンドの使い方知らないだろ。
patch/merge/diff3はgit以前からあるコマンドで、多分初期Gitはそのまま使ってたと思うが。
具体的な使い方は以下。
今、元 fileA に対して、変更後 fileC になってるが、実は中間の fileB が欲しかったとする。このとき、
cp fileA fileB
diff fileA fileC | less -N; // ここで該当行を確認する。例えば10-20行目なら、
diff fileA fileC | sed -n '10,20 p' | patch fileB
これでfileBが得られるんだよ。これ以上色々複雑な時用に diff3 とか merge もある。
だからパッチの分割はすぐ出来るんだよ。
968(1): (ﾜｯﾁｮｲ 09e4-chQ5) 2022/11/06(日)14:05 ID:az1H5JFk0(2/7) AAS
>>967
そういう作業を必要で無くすためにgitが生まれた
patchの提出をgitの分散リポジトリ上で可能とするためにね
963とか964が行ってるpatchというのは、いわゆるpatchファイルのことではなく、ブランチ上に存在する差分の事
そのpatchを整理するのに index や rebase がある
969(1): (ﾜｯﾁｮｲ debb-qVfh) 2022/11/06(日)14:19 ID:FBkt/oHG0(6/8) AAS
もしかして、もしかすると、git では「パッチ＝コミット」っていうことすら理解できてないのだろうか。
まさかそんな人はいないよね。単に言動が変な人なだけだよね。
970(1): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)14:25 ID:OfQ8ymDc0(13/24) AAS
>>968
知ってるよ。
ただまあ、確かにパッチ管理ツールだ。
プログラマはこれをソースコード管理ツールとして使おうとするから問題なのだろう。
バックアップが取れて、履歴が戻れれば何でもいいんだが、mergeも出来るから便利だからね。
なお俺は
> ブランチ上に存在する差分の事
も所詮はdiffだ、という立場だよ。だから元のunixコマンドで何とでもなるし、
それをシェルスクリプトで集大成したのが初期Gitだろ。
971(1): (ﾜｯﾁｮｲ debb-qVfh) 2022/11/06(日)14:31 ID:FBkt/oHG0(7/8) AAS
>>970
ちがうぞ。最初からパッチ管理ツールとして設計されるぞ。
そしてパッチ管理ツールなんだから、パッチの出力機能さえあれば良いんだぞ。
それ以外の差分が欲しかったら別の外部ツール使えば良いんだぞ。それこそ基本だろ
972(1): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)14:33 ID:OfQ8ymDc0(14/24) AAS
>>969
各commmit「点」でdiff取ったときに落ちる情報って何？
ああcommitメッセージか？そんなのは知らんし要らんよ、って立場。
つか、commitメッセージガーなんて言い訳にならないから、
どのみちソースコードを確認するしかないんだよ。
commitメッセージはその手がかりとラベルに過ぎない。これが俺、というか多分普通のプログラマの立場。
お前らはcommitメッセージが間違ってたら、そいつに責任を負わせられるんだろうさ。
ソースコード読めないからね。
ソースコード読める奴ならこんな言い訳効かないんだよ、何でお前が上にいるんだ！監督する為だろ！になる。
さすがに素通しはヤバい。
省1
973: (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)14:36 ID:OfQ8ymDc0(15/24) AAS
>>971
ああそれが diff のデフォルト出力をさせない理由だな。
651から一周回ったが、なるほど色々状況は理解出来たよ。賛同はしないが。
974(2): (ﾜｯﾁｮｲ debb-qVfh) 2022/11/06(日)14:45 ID:FBkt/oHG0(8/8) AAS
>>972
だからお前の考えてるような作業履歴管理ツールじゃないんだから、あきらめて他所へ行け。
gitはパッチ管理ツール。そしてパッチは何時、誰が、何のために作成したかが重要情報なんだよ。それを管理してるんだよ。
ソースコードの保管するツールじゃねーぞ。
975: (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)14:49 ID:OfQ8ymDc0(16/24) AAS
>>974
そこは違うんだな。
みんな結局自分でやるのも作るのも面倒だから、既に動いてるツールを使ってるだけだよ。
Gitの機能のサブセットで十分にカバー出来るのなら、Git使えばいいだけ。
976: (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)14:56 ID:OfQ8ymDc0(17/24) AAS
>>974
だからな、前言ったように、ブッ込んでおけば後で取り出せるバケツでしかないんだよ。
そのバケツにゴテゴテ付いてるから難しそうだが、要らない機能は使わなければいいだけ。
ただ、履歴保持の範囲を知らずに使って、実は記録されていませんでは困るから、使う前に調べてる。
977(2): (ﾜｯﾁｮｲ 515f-nsye) 2022/11/06(日)15:45 ID:o7v4FvnP0(1) AAS
外部ﾘﾝｸ:www.praha-inc.com
そもそもコミットメッセージは何のためにあるのでしょうか？
コミットログのうちコードの変更履歴には「コードをどのように変更したか」という情報が含まれていますが、「コードを何故変更したのか」という情報はコミットメッセージを読まないと分かりません。機能追加、バグ修正、パフォーマンスのためなど、変更した理由は様々なものが考えられます。
もちろんコードを変更した本人に聞けば変更した意図はわかると思いますが、変更した本人にいつでも聞ける状況であるとは限りません。
「何故コードを変更したのか」という情報が欲しい時のためにコミットメッセージが存在します。
省3
978: (ﾜｯﾁｮｲ 09e4-chQ5) 2022/11/06(日)15:52 ID:az1H5JFk0(3/7) AAS
まあこいつは分散バージョン管理の難しさを理解できていない
一人でしかプログラム組んだことがないのだろう
gitのややこしいと感じる仕様のほとんどは分散リポジトリ管理に起因していて、分散リポジトリ管理の問題をできるだけ明示的にシンプルに解決しようという意図で設計されている
979: (ﾜｯﾁｮｲ b114-pSqO) 2022/11/06(日)15:55 ID:JyiC8cnE0(5/6) AAS
ほんとなぁ、POSIX原理主義だからユニケージだかUSP研究所だかしらんが
例のあいつも、バージョン管理のツールを、バックアップツールとしてしか考えてねぇ
だからとりあえずファイルを入れておけば差分はdiffで見れるだろとか
訳のわからんことを言い出す
ある時点とある時点の差を見たいんじゃねーんだよ
ある修正にどのような差分があるかを記録＝コミットしたいわけで
その記録なしに差分だけみれても役に立たないっつーの
そこが根本的に違うというか、バージョン管理の役目がわかってない
980: (ﾜｯﾁｮｲ 09e4-chQ5) 2022/11/06(日)16:10 ID:az1H5JFk0(4/7) AAS
「ブッ込んでおけば後で取り出せるバケツ」など言っているが、
必要とされていたのは内容を同期できる複数のバケツで、
なおかつバケツ同士が常にオンラインで通信しているわけではない
そういう問題に取り組んだ結果だ
981: (ﾜｯﾁｮｲ 09e4-chQ5) 2022/11/06(日)16:12 ID:az1H5JFk0(5/7) AAS
そういう魔法のバケツを生み出すために、ただのバケツならできることがgitでは制限されていたりもする
ユーザから見て不自由のない完全な魔法のバケツを生み出そうとしたプロジェクトは複雑すぎてことごとく失敗してきた
982: (ﾜｯﾁｮｲ b114-pSqO) 2022/11/06(日)16:14 ID:JyiC8cnE0(6/6) AAS
バケツの中に入っている袋詰めの塩や砂糖を、一つづつ取り出したいのであって
バケツの中に全部入ってるから、遠心分離機でも使って
取り出せばいいだろうじゃないんだよなｗ
983: (ﾜｯﾁｮｲ 09e4-chQ5) 2022/11/06(日)16:36 ID:az1H5JFk0(6/7) AAS
前スレは消費に1年半かかってるのに、このスレは半年ぐらいで終わりだな
次スレ立ててみるけど失敗したらゴメン
984: (ﾜｯﾁｮｲ 09e4-chQ5) 2022/11/06(日)16:41 ID:az1H5JFk0(7/7) AAS
次スレ
Git 19
2chｽﾚ:tech
985(1): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)19:18 ID:OfQ8ymDc0(18/24) AAS
相変わらずお前ら盛大に勘違いしてるが、とりあえず、
× Gitはパッチ管理ツールである
○ Gitはパッチ適用ツールである
○ Gitはパッチ記録ツールである
としよう。管理は出来てない。何を管理すべきか分かってないから。
commitメッセージなんてただのラベルに過ぎない。
986(1): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)19:19 ID:OfQ8ymDc0(19/24) AAS
例えば今回俺が送った再現コード、あれはどこに配置されるのだ？
>>977の通り、「何故この変更を行ったのか」の完全情報がそこにある。
まさか捨てたりしないよな？
バグパッチに於いて、重要な物から順に、
1. そのバグを修正するコード
2. そのバグを再現するコード
：
10000, commitメッセージ
だ。どんなに丁寧にcommitメッセージを書いたところで、「それ、あなたの感想ですよね？」でしかない。
肝心なところを書き間違ってるかもしれないし、信用も出来ない。
省10
987: (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)19:20 ID:OfQ8ymDc0(20/24) AAS
こうなってないだろ。一回パッチ当てて動きました！満足です！じゃないんだよ。
繰り返すが、commitメッセジーをいくら丁寧に書いても意味無い。
再現コードに比べたら本当にゴミ以下。
逆に、再現コードに辿り着けるのなら、後はラベルが正しく付いてれば十分なんだ。
それ以上の情報は、commitメッセージのテキストではなく、
再現コードとバグ報告＝完全情報を見た方がいいから。
で、GitHubはまあこれに近いよ。
そもそもバグ報告自体Webだし、少なくともIssueからバグの完全情報に当たれる。
Gitはどうなの？
今回の俺と同様の、過去のバグ報告の再現コードを生かせてるのか？
省13
988(1): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)19:20 ID:OfQ8ymDc0(21/24) AAS
ちなみにchromeの連中は気持ち悪いほどregressionテストしてるぞ。
本来は、ああするべきなんだろうよ。
regressionテスト自体はタダ(スクリプトで自動実行)だからね。
バグ「管理」というのなら、原因を究明して、少なくとも同じバグが出ないようにしないといけない。
それはcommitメッセージをいくら丁寧に詳細に書いても、達成出来るものではない。
分かりやすく言うとな、「体調管理」と言われれば、少なくとも同じ原因で風邪を引かないようにするだろ。
なら、「バグ管理」なら、最低限レビューしてregressionテストしないと駄目だよ。
それはcommitメッセージ云々では出来ない。だからパッチ「適用」「記録」ツール。
989: (ﾜｯﾁｮｲ ad14-pSqO) 2022/11/06(日)19:24 ID:VM2X6i580(1/6) AAS
>>985
> commitメッセージなんてただのラベルに過ぎない。
その言葉からお前がわかってないのが明らかなんだけど？
990: (ﾜｯﾁｮｲ ad14-pSqO) 2022/11/06(日)19:26 ID:VM2X6i580(2/6) AAS
>>988
うん。だからそのchromeはここまで徹底してコミットを管理してる
それを見習え
外部ﾘﾝｸ:github.com
991: (ﾜｯﾁｮｲ ad14-pSqO) 2022/11/06(日)19:27 ID:VM2X6i580(3/6) AAS
regressionする際にもコミットを管理するのは重要で
コミット単位で戻してテストする
動かないコードをコミットすることはない
お前みたいにテキストエディタで修正するたびにコミットとかしない
992: (ﾜｯﾁｮｲ ad14-pSqO) 2022/11/06(日)19:28 ID:VM2X6i580(4/6) AAS
なんでchromeのコミットメッセージが
こんなに詳しく書かれているのか、その理由を考えたら？
993: (ﾜｯﾁｮｲ ad14-pSqO) 2022/11/06(日)19:32 ID:VM2X6i580(5/6) AAS
バージョン管理はソースコードの変更履歴を管理するものなので
そこにバグ管理という別の概念を持ち出すのも頭悪い
バグ管理は別のツールでやれ
994(2): (ﾜｯﾁｮｲ 515f-pSqO) 2022/11/06(日)19:55 ID:sj15aRfA0(3/4) AAS
>>986
> 例えば今回俺が送った再現コード、あれはどこに配置されるのだ？
修正コミットのログから URL で辿れるようになるかな。
外部ﾘﾝｸ:public-inbox.org
995: (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)20:08 ID:OfQ8ymDc0(22/24) AAS
>>994
それは鯖に置いてるだけだろ。まあそれはそれで十分で、（この意味では最初のMLでも十分)
問題は、
1. .git上、つまりソースコード改変ツリーから簡単に辿れるよう、
commitメッセージにそのリンクは落とされている(落とされる予定）なのか？
そうじゃないと>>977が達成出来ないだろ。
2. そしてregressionテストパターンとして登録され、今後ずっと実行されるのか？
3. そもそも根本の原因はソースコードの程度が酷いことであり、レビューしろよマジで
だよ。
レイヤーの考え方がない奴等ばかりなので通じないかもしれないが、
省6
996(1): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)20:11 ID:OfQ8ymDc0(23/24) AAS
>>994
と思ったがすまん、見落とした。
> 修正コミットのログ
つまりこれ、コミットメッセージそのものなのか？
ちょっと確認したいんだが、どこ見ればいいんだ？GitのGitHubから？
997(1): (ﾜｯﾁｮｲ 515f-pSqO) 2022/11/06(日)20:22 ID:sj15aRfA0(4/4) AAS
>>996
そう。コミットメッセージを含めてML上でレビュー中。まだ本体リポジトリには入ってない。
挙がってるレビューコメントを受けてそのうち第２弾が投稿されて取り込まれるんじゃないかな。
君もソースコードの質が気になるなら修正を送ってくれていいんだよ。さぁさぁ。
998(1): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)20:38 ID:OfQ8ymDc0(24/24) AAS
>>997
つまりあれがそのままに近い状態で入るのか？
まあそれは見守るとして、本来はちゃんとラベルを付け替えないとまずい。
俺が送った段階では高い確率で「free忘れによるメモリリーク」と推定出来たが、
断定は出来なかったので、単に「メモリ食いすぎ」としてる。
だから、メモリリークだと「断定」出来た人が概略を書き直さないといけない。
が、まあ、これは多分為されるだろう。見守るよ。
> 君もソースコードの質が気になるなら修正を送ってくれていいんだよ。さぁさぁ。
これは本質的に無理だ。多分俺、というか、いわゆるCコードを拒絶すると思うよ。
間違いなく、連中は自己の能力に自信持ってて、傲慢で、言うこと聞かない連中だ。
省11
999: (ﾜｯﾁｮｲ ad14-pSqO) 2022/11/06(日)20:40 ID:VM2X6i580(6/6) AAS
>>998
お前がちゃんとやれって言われるだけだよ
お前雑なんだよ。無能なのに張り切るな。空回りしてるぞｗ
1000: (ﾌﾞｰｲﾓ MM96-1bV6) 2022/11/06(日)20:46 ID:wlljBD17M(1) AAS
質問いいすか？
1001(1): 1001 ID:Thread(1/2) AAS
このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 197日 17時間 21分 4秒
1002(1): 1002 ID:Thread(2/2) AAS
5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
省4
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.041s