Git 18

2022/04/23(土) 03:25:45.27

ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。

Git - Fast Version Control System
http://git-scm.com/

◆関連サイト
Pro Git - Table of Contents
http://git-scm.com/book/ja
Git入門
http://www8.atwiki.jp/git_jp/

◆前スレ
Git 16©2ch.net
https://mevius.5ch.net/test/read.cgi/tech/1502726047/
Git 17
https://mevius.5ch.net/test/read.cgi/tech/1599016710/

VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

2022/11/06(日) 15:52:02.65

まあこいつは分散バージョン管理の難しさを理解できていない
一人でしかプログラム組んだことがないのだろう
gitのややこしいと感じる仕様のほとんどは分散リポジトリ管理に起因していて、分散リポジトリ管理の問題をできるだけ明示的にシンプルに解決しようという意図で設計されている

2022/11/06(日) 15:55:03.47

ほんとなぁ、POSIX原理主義だからユニケージだかUSP研究所だかしらんが
例のあいつも、バージョン管理のツールを、バックアップツールとしてしか考えてねぇ
だからとりあえずファイルを入れておけば差分はdiffで見れるだろとか
訳のわからんことを言い出す

ある時点とある時点の差を見たいんじゃねーんだよ
ある修正にどのような差分があるかを記録＝コミットしたいわけで
その記録なしに差分だけみれても役に立たないっつーの
そこが根本的に違うというか、バージョン管理の役目がわかってない

2022/11/06(日) 16:10:07.15

「ブッ込んでおけば後で取り出せるバケツ」など言っているが、
必要とされていたのは内容を同期できる複数のバケツで、
なおかつバケツ同士が常にオンラインで通信しているわけではない
そういう問題に取り組んだ結果だ

2022/11/06(日) 16:12:28.94

そういう魔法のバケツを生み出すために、ただのバケツならできることがgitでは制限されていたりもする
ユーザから見て不自由のない完全な魔法のバケツを生み出そうとしたプロジェクトは複雑すぎてことごとく失敗してきた

2022/11/06(日) 16:14:37.71

バケツの中に入っている袋詰めの塩や砂糖を、一つづつ取り出したいのであって

バケツの中に全部入ってるから、遠心分離機でも使って
取り出せばいいだろうじゃないんだよなｗ

2022/11/06(日) 16:36:01.68

前スレは消費に1年半かかってるのに、このスレは半年ぐらいで終わりだな
次スレ立ててみるけど失敗したらゴメン

2022/11/06(日) 16:41:37.94

次スレ
Git 19
http://mevius.5ch.net/test/read.cgi/tech/1667720427/

2022/11/06(日) 19:18:45.16

相変わらずお前ら盛大に勘違いしてるが、とりあえず、

× Gitはパッチ管理ツールである
○ Gitはパッチ適用ツールである
○ Gitはパッチ記録ツールである

としよう。管理は出来てない。何を管理すべきか分かってないから。
commitメッセージなんてただのラベルに過ぎない。

2022/11/06(日) 19:19:20.86

例えば今回俺が送った再現コード、あれはどこに配置されるのだ？
>>977の通り、「何故この変更を行ったのか」の完全情報がそこにある。
まさか捨てたりしないよな？

バグパッチに於いて、重要な物から順に、

1. そのバグを修正するコード
2. そのバグを再現するコード
：
10000, commitメッセージ

だ。どんなに丁寧にcommitメッセージを書いたところで、「それ、あなたの感想ですよね？」でしかない。
肝心なところを書き間違ってるかもしれないし、信用も出来ない。
この点、再現コードは情報が完全で、全ての情報を過不足無く含んでいて、曖昧さもない。
だからcommitメッセージの情報価値なんて再現コードと比べたらゴミ以下で、
再現コードに対してのリンクで十分なんだよ。つまり、

○年○月○日に○○から送られてきた○○のバグ(メモリリーク)を修正する。
詳細はXXXX

で、XXXXのところ、Git流ならSHA1ハッシュで、
その中に再現コードと詳細、今回なら全員のメールの全文を入れておくのがバグ管理だよ。
これで、「何故この変更を行ったのか」の完全情報が保たれる。
そして、再現コードは今後ずっとregressionテストに使う資産にする。
そうすれば、少なくとも過去と同じバグはリリース前に見つかる。

2022/11/06(日) 19:20:02.27

こうなってないだろ。一回パッチ当てて動きました！満足です！じゃないんだよ。
繰り返すが、commitメッセジーをいくら丁寧に書いても意味無い。
再現コードに比べたら本当にゴミ以下。
逆に、再現コードに辿り着けるのなら、後はラベルが正しく付いてれば十分なんだ。
それ以上の情報は、commitメッセージのテキストではなく、
再現コードとバグ報告＝完全情報を見た方がいいから。

で、GitHubはまあこれに近いよ。
そもそもバグ報告自体Webだし、少なくともIssueからバグの完全情報に当たれる。
Gitはどうなの？
今回の俺と同様の、過去のバグ報告の再現コードを生かせてるのか？
ならそういうディレクトリがあって、
bug_patches/XXXXXなハッシュが名前になってるディレクトリに再現コードその他がブチ込まれてて、
出荷前(というのもおかしいが)には全部一通り通せ、となってるはずだけど、
どう見てもそうなってないでしょ。
パッチ当てたから満足です、で終わってる。

こんなのでバグが収束するはずがない。
同じ連中が書いてるのだから、放置したら同レベルのバグを繰り返す。
だから本来は何故こんなバグが発生したのか？からコード構造を見直して、
そもそもそうならないようにするのだけど、そういう学びもないし、(だから基本すら出来てない)
regressionテストのネタにもしないのだから、今後ともバグだらけだよ。
ああ、Gitの達人揃いだから、「記録」は出来てるのだろうよ。だけどそれは「管理」ではない。

ただ、これがバザール流だ！と来るなら、はーそうですかー(棒)だよ。
目も手も数が違うし、俺には何が最適か分からんし。

2022/11/06(日) 19:20:37.38

ちなみにchromeの連中は気持ち悪いほどregressionテストしてるぞ。
本来は、ああするべきなんだろうよ。
regressionテスト自体はタダ(スクリプトで自動実行)だからね。

バグ「管理」というのなら、原因を究明して、少なくとも同じバグが出ないようにしないといけない。
それはcommitメッセージをいくら丁寧に詳細に書いても、達成出来るものではない。

分かりやすく言うとな、「体調管理」と言われれば、少なくとも同じ原因で風邪を引かないようにするだろ。
なら、「バグ管理」なら、最低限レビューしてregressionテストしないと駄目だよ。
それはcommitメッセージ云々では出来ない。だからパッチ「適用」「記録」ツール。

2022/11/06(日) 19:24:47.08

>>985
> commitメッセージなんてただのラベルに過ぎない。

その言葉からお前がわかってないのが明らかなんだけど？

2022/11/06(日) 19:26:23.98

>>988
うん。だからそのchromeはここまで徹底してコミットを管理してる
それを見習え
https://github.com/chromium/chromium/commits/main

2022/11/06(日) 19:27:42.33

regressionする際にもコミットを管理するのは重要で
コミット単位で戻してテストする
動かないコードをコミットすることはない
お前みたいにテキストエディタで修正するたびにコミットとかしない

2022/11/06(日) 19:28:57.43

なんでchromeのコミットメッセージが
こんなに詳しく書かれているのか、その理由を考えたら？

2022/11/06(日) 19:32:31.47

バージョン管理はソースコードの変更履歴を管理するものなので
そこにバグ管理という別の概念を持ち出すのも頭悪い
バグ管理は別のツールでやれ

2022/11/06(日) 19:55:47.23

>>986
> 例えば今回俺が送った再現コード、あれはどこに配置されるのだ？
修正コミットのログから URL で辿れるようになるかな。
https://public-inbox.org/git/20221102220142.574890-2-szeder.dev@gmail.com/

2022/11/06(日) 20:08:52.18

>>994
それは鯖に置いてるだけだろ。まあそれはそれで十分で、（この意味では最初のMLでも十分)
問題は、

1. .git上、つまりソースコード改変ツリーから簡単に辿れるよう、
commitメッセージにそのリンクは落とされている(落とされる予定）なのか？
そうじゃないと>>977が達成出来ないだろ。
2. そしてregressionテストパターンとして登録され、今後ずっと実行されるのか？
3. そもそも根本の原因はソースコードの程度が酷いことであり、レビューしろよマジで

だよ。
レイヤーの考え方がない奴等ばかりなので通じないかもしれないが、
gitは適用/記録という下層レイヤーであって、バグ/パッチ「管理」は上位レイヤーの戦略だから、
gitで「管理」出来ると思ってるのが間違いなんだよ。記録は出来るが、管理は出来ない。
gitで出来るのは上の1だけだね。
だからcommitメッセージは勿論丁寧に書くべきなんだけど、丁寧に書けばいいわけでもないんだ。
それでバグやパッチが減るわけでもないから。
目的と手段の混同はどの界隈でもあるけど、ここの連中も大概だよ。

2022/11/06(日) 20:11:50.13

>>994
と思ったがすまん、見落とした。

> 修正コミットのログ

つまりこれ、コミットメッセージそのものなのか？
ちょっと確認したいんだが、どこ見ればいいんだ？GitのGitHubから？

2022/11/06(日) 20:22:10.42

>>996
そう。コミットメッセージを含めてML上でレビュー中。まだ本体リポジトリには入ってない。
挙がってるレビューコメントを受けてそのうち第２弾が投稿されて取り込まれるんじゃないかな。
君もソースコードの質が気になるなら修正を送ってくれていいんだよ。さぁさぁ。

2022/11/06(日) 20:38:50.28

>>997
つまりあれがそのままに近い状態で入るのか？
まあそれは見守るとして、本来はちゃんとラベルを付け替えないとまずい。

俺が送った段階では高い確率で「free忘れによるメモリリーク」と推定出来たが、
断定は出来なかったので、単に「メモリ食いすぎ」としてる。
だから、メモリリークだと「断定」出来た人が概略を書き直さないといけない。

が、まあ、これは多分為されるだろう。見守るよ。

> 君もソースコードの質が気になるなら修正を送ってくれていいんだよ。さぁさぁ。
これは本質的に無理だ。多分俺、というか、いわゆるCコードを拒絶すると思うよ。
間違いなく、連中は自己の能力に自信持ってて、傲慢で、言うこと聞かない連中だ。
世の中のCコードなんて、基本通りやってる物でほぼ全部だから、見たこと無いわけが無い。
それが何故そうなってるか理解出来ない、
つまり、王道を王道と理解出来ない奴等だからデタラメやってるわけで、
言うこと聞く連中ならそうはならない。

通常だと、やらせるだけやらせて、でもどうにももうダメポなときに、
そもそもお前のコードがおかしい、ここをこう直せ、なら簡単にメモリリークは抑えられる、とすると効くのだろうけど、
問題はバザールで、無限にモグラ叩き出来てしまって、実際にそれでやろうとしてることだよ。
マジかー、って、ちょっと驚きだが、まあ観戦だ。
ああちなみに、俺以外の誰でも、まともなC書ける奴なら、ちょっと引くコードだよ。
だからそこら辺の奴等に書かせても、もっとましなコードになるよ。そして俺もその程度だし。
というか単発のコードでそんなに技量の差なんて出ないし。

2022/11/06(日) 20:40:54.42

>>998
お前がちゃんとやれって言われるだけだよ
お前雑なんだよ。無能なのに張り切るな。空回りしてるぞｗ

2022/11/06(日) 20:46:49.73

質問いいすか？

**1001** · Over 1000

このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 197日 17時間 21分 4秒