Git 19

2022/11/06(日) 16:40:27.51

ソースコード管理を行う分散型バージョン管理システム、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 17
https://mevius.5ch.net/test/read.cgi/tech/1599016710/
Git 18
http://mevius.5ch.net/test/read.cgi/tech/1650651945/

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

2022/11/06(日) 17:05:45.20

乙

2022/11/06(日) 20:50:19.64

前スレの結論

- git はバージョン管理ソフト
- バージョン管理ソフトはバックアップソフトじゃない
- 管理するのはソースコードじゃなくて変更履歴
- お前の汚い試行錯誤の作業履歴をバージョン管理するな
- gitはお前の作業の管理ツールではない
- コミットメッセージはきちんとかけ

2022/11/06(日) 20:59:13.27

前スレ>>1000
どうぞ。ってか俺が答える訳じゃないけどな。

2022/11/06(日) 21:16:22.34

前スレ>>999
それが本質的に違うんだよ。
連中はいわゆるコードの「清潔さ」に価値を置いてないから（一般価値観からすると）デタラメなコードになってる。
そこに「綺麗な」コードを持って行っても、

え？なに？綺麗なだけ？バグは直ってないの？なら要らないよ

になるんだよ。「綺麗な」コードは汚いコードと同じ動作をする、綺麗なだけのコードだから。
そして「汚い」コードの方が簡単に書ける（＝設計を必要としない）から、手数では負ける。
だからもう既に「汚い」コードのパッチが出てる時点で、
誰かが「綺麗な」コードを持ち寄っても連中の価値観では無視される。
（仮に採用されるとしても、今後とんでもない糞コードで上書きされる事になるので、コードを投げたくもない）

ただな、「綺麗な」コードの目的は、結局のところ長期的保守だから、
今も、今までも、この方法でずっと保守出来てる、
とする連中には、効かないし、確かに意味のないものかもしれないんだよ。

だけどこれは学術界からすると異端も異端、でもそれで確かに回っちゃってるんだから、
どうなのよこれ？なんだよ。どっちが正しいのか/適切なのかも俺にはよく分からん。

ただ俺は、綺麗なコードを書きたいし、それが良しとされる世界がいいから、とりあえず近づかずにいよう、って感じ。
多分一般Cの連中も同じじゃないかと思われる。だからあの状態なわけで。

まあこれはさておき、だからマージ回数とかも半端ないわけで、
> ブランチを切るのに大変時間がかかっていました。
> 大規模なプロジェクトになると数十秒かかったりすることもありました。
> Gitだとこの作業が一瞬でできます。（前スレ897)
で、Linusは「一日で480しかブランチ切れないようでは仕事にならない！」というわけだが、
そりゃあんただけで、世界の他の誰もそこに苦労してないから、そりゃそんなもん存在しないよ、でしかない。

だからもう、何もかもが根本的に違うんだよ。

2022/11/06(日) 21:21:37.64

え、何？まだ続けるつもりなの？
てか、優秀な入門書とか既に出てるし大人しくそれ読んでりゃいいのに

2022/11/06(日) 21:33:34.35

>>5
> 連中はいわゆるコードの「清潔さ」に価値を置いてない
これがきみの思い込みで間違いであることは、きみの報告に対して挙がった 3 つのパッチの最後
"[PATCH 3/3] diff.c: use diff_free_queue()" が何の挙動も変えないコードクリーンアップである
ことを見れば明らかだね。
https://public-inbox.org/git/20221102220142.574890-4-szeder.dev@gmail.com/

思い込みで無意味な長文を垂れ流してスレを汚すのは止めていただきたい。

2022/11/06(日) 21:51:26.30

>>7
それ、コード構造が根本的に違うんだよ。

で、君のむかつきは、Git連中のむかつきそのもので、
俺や普通のCプログラマがいわゆるCコード持って行ったら、その対応なんだと分かるんだよ。
だから多分距離を置かれてる。
そして本人達はそれに気づいてない。けど困ってもいない。なんだかねー。

まー良く言えば多様性だねー(棒)
まあいいや、この話は結局所堂々巡りだし、続ける意味もないし、終わりにしようよ。
俺の持論としては、
「お前は分かってない、ということを相手に分からせるのが一番難しくて、それが出来れば8割終わってる」
なんだけど、まあ君らも俺に対して思ってるでしょ。そんなもんだよ。

2022/11/06(日) 22:35:01.21

複数人の共同開発だと、綺麗なコード書くより、綺麗なパッチを書く方が生産性が高くなるんだよ。そして将来綺麗なパッチが書けるように予め備えておくこと。
変更の行数とかそんなのは誤差だよ。一番時間のかかるのは人間どうしの理解、コミュニケーションなので、そこの効率が良いのが良いコードで綺麗なパッチなんだよ。
コミットメッセージがむしろ本体。

2022/11/06(日) 22:54:22.81

すまんがついで。

だから、Gitのコードをよくしたければ、Linusにレクチャーして貰えばいいんだよ。
そもそも彼のプロジェクトだし、彼は世界一に近い達人だし、彼の話ならGitの連中は聞くだろうし。

ちなみにLinusのコードはマジで凄い。
kernelコードでマクロで抽象化してるのがあって、
ブログ記事にしてる奴がいたからググれば出てくるはずだが、マジで記事書きたくなる位凄い。
こんな使い方あるのかよー、ってちょっと驚く。
OOPをCでやると全部手動だから面倒なのだけど、出来ないわけではない。
ただ、抽象はちょっときつくて、やったら普通にバグりそうなので俺ならやりたくないのだが、
はえー、なるほどこうすればいいのですかー、みたいなコードになってる。

で、Linusは送られてきたパッチに対して、
「僕はこういうコードを見るたびに、ああこの人はポインタの使い方を知らないのだな、と悲しくなるんだ」
とか言ってたから、コードを一応はレビューしてたんだろう。
だけど多分そのまま通してしまってるところが普通ではない。
もっとも、Linus基準だと、世界中の殆ど全てが糞コードなんだろうけどさ。

2022/11/06(日) 23:25:51.81

>>9
> 綺麗なコード書くより、綺麗なパッチを書く方が生産性が高くなるんだよ。
それは根本的に違う。
綺麗なコードはバグを含みにくく、或いはバグだと見た瞬間分かるから、
将来的にパッチが要らない。だから、基本的戦略が

一般：バグが発生しないように綺麗なコードにしよう。(パッチを不要にする作戦）
Git：バグは直せばいい。目も手もある。だからコードは汚くても、パッチも汚くても、問題ない。
　パッチなんていくらでも当てられるし、世界最高のパッチ適用システムを全員が熟知している。
　(だから元のコードはボロボロでバグだらけでも大した問題にならない)

なんだよ。あのパッチも汚いよ。それが分からないのはお前の問題。
ただ、元のコードが汚いからパッチも汚いわけで、あの元コードで綺麗なパッチを書くのは無理だ。
だから本来はかなり大がかりな修正が必要なのだけど、誰も気づいてないし、指摘もしない。（ように見える）

ただ多分、その前の根本戦略も違ってて、
Gitが出来た2005頃は「動いているコードはいじるな」だったんだよ。
それが、2010頃からか？「動いているコードであっても、少しでも改善出来るならどんどん直せ」になってる。
これは前者だと本当にすさまじい勢いでコードが劣化するから、すぐに使い物にならなくなると分かったのと、
色々みんな隠蔽やリファクタに慣れてきて、「正しく構成していれば」割と安全に直せるようになったのがある。(多分)
Git見る限り、もしかするとまだ前者でやってるかもしれない。それだと多分この先いつか破綻する。
だからみんな危険を冒してリファクタしてるわけでさ。
（と言いたいところだが、普通の開発では完全に頓挫するレベルを既に明らかに越えているので、このまま行けるのかも？)

ただ9のコードについての見解は完全に間違いだし、釣りレベルだが、
人についてはまあその通りで、
バザール開発においては人を集められること＝目と手の数こそがパワーの源泉であるのは事実だ。
だからそれを取り持つGitシステムが重要なのも事実だ.。
でも、バグパッチのcommitメッセージがいくら綺麗でも、それで人は寄って来ないよ。やっぱたぶんLinusだと思うよ。

2022/11/06(日) 23:52:01.89

>>11
2005年4月に最初のコミットが行われて、そこから2006年4月ぐらいの差分見てみると物凄い変更されてて、
この段階で「動いているコードはいじるな」とかありえないと思うんだけど

2022/11/06(日) 23:58:44.71

>>12
初段階では関係ない。それは「動いていない」コードだから。
安定稼働した、もう追加機能もパッチもあまり必要ない、と思ってからの話になる。
俺の常識が通用する連中ではないが、普通は多分数年の安定稼働後だ。

2022/11/07(月) 00:00:33.44

ちょっと言い方が悪かった。
お前ら、Gitはもうインフラだ！ファイル形式も変えられない！とか、言ってたろ。
そう思えてから、の話。

2022/11/07(月) 00:04:01.53

>>14
お前ホント書き込み全部適当だよな
2010年から劣化してるとかも適当に言ってるだろ

2022/11/07(月) 00:06:27.27

一番最初のコミットe83c516331をcheckoutすると壮観だな7つの簡単なコマンドしかない
init-db update-cache show-diff write-tree read-tree commit-tree cat-file
makeが有る環境に持っていくのちょっと面倒だからやらないけど、これたぶん簡単にmakeできそうで、動きそう

2022/11/07(月) 00:08:01.82

Gitないともう仕事できない
おっちょこちょいだからpush前にDiff見れるの超助かるわ

2022/11/07(月) 00:29:40.36

>>15
ああ書き方が曖昧だったが、変わったのはソフトウェア工学/業界の戦略だよ。もっと大きい話。
Gitはどっちの戦略でいつ頃までやってて、なんて事は俺は全く知らん。

ただパッチ見る限り、何か制約でもあるのか？と思える位に不自然だというだけ。
直すところそこじゃねーだろ、みたいな。

2022/11/07(月) 00:32:07.26

>>18
お前の言うことは全部適当すぎて何も信用できないんだけど？
例えばその見たパッチのhash出せる？

2022/11/07(月) 00:33:15.61

>>19
>>7

2022/11/07(月) 00:36:35.26

>>20
いやいや最近のじゃなくてその2010年ごろから劣化してきたパッチのhashだよ
もしかして >>7 見ただけで、これは2010年ごろからの全体の劣化！とかわかっちゃうの？スゴイなお前エスパーか

2022/11/07(月) 05:30:07.71

ド素人目。
「綺麗なコードだとバグを生まない」とか机上の空論なんだよ。人間はミスをするし機械は壊れるんだよ。
バグを生まないコードよりも、誰もが問題の原因をすぐに発見できてすぐに修正できる方が優れてるんだよ。
多数のプロジェクトの長年の経験によるベストプラクティス。
だから git 使うし、コミットメッセージをきちんと書くんだよ。コミットメッセージの有り難さとか理解できないやつが、バージョン管理ツールのスレで偉そうに語んな。

2022/11/07(月) 06:17:25.58

>>22
そもそもバグを生むのが間違い。POSIX原理主義ならバグは生まれない。この本に書いてある。

初めてのPOSIX原理主義超進化を遂げたシェルスクリプトを学ぶ15回の講義
https://richlab.org/coterie/lpf.html

そもそもPOSIX原理主義ではgitを禁止してる。バイナリでデータを保存しているから
何年かたってgitから別のソフトに変わったときに取り出せなくなる。
バージョン管理ならシェルスクリプトを使えばよい。コミットはcp -pRやrsyncで十分だ。
冒頭コメントにファイルの名前や最終更新者や更新日時をかけ
diffで差分も見れるしgrepで検索できる。さらにはsed やAWK などをパイプで繋ぎ
ワンライナーとして実行すれば様々な切り口で過去リビジョンの閲覧ができる
楽をするな。工夫しろ、悩んで自分で解決策を見つけ出せ

> 12.1.1　1 行書いては実行 - そもそもバグを生まない
>
> デバッグという作業は、そもそもやる必要を無くせるのであればそれに越したことはない。
> デバッグ作業そのものからは、何も新たなコードは生まれない。
> 何もコードを生まない作業に好き好んで時間を割きたくはないからな。
>
> そんなことできるのか、と思うかもしれんが、答えは「1 行書き足しては実行、書き足しては実行……を
> 繰り返す」である。このことは既に今まで何度か言ってきた。何十行何百行もあるプログラムを
> 書き終えた後でおかしな動きをすることがわかったら、どの行に問題が潜んでいるのかの特定には時間がかかる。
> あるいは、全部作った後で出来上がったコードを見ながらテスト項目を立案するのも骨の折れる作業だ。
>
> 一方、毎行1 行ずつ書き足しては実行というテストをしていて、ある1 行書き足した時点で
> おかしな動きになったと気づけば、今書いた1 行に原因がある可能性が高く、場所の特定に割く時間を抑えられる。
>
> 1 行書いては実行というのはべつにシェルスクリプトに限ったテクニックではない。
> コンパイル不要な言語ならどれでも気軽にできる。しかし、UNIX シェルやシェルスクリプトは
> これに向いた仕様になっている。それを見ていこう。

2022/11/07(月) 07:52:49.70

いつまでしょうもないレスバトル続けんの？

2022/11/07(月) 08:50:06.37

>>23
キャラ作りもあるのだろうけど、冒頭はクレイジーだな。
blob(ただのコンテナ)が取り出せなくなることはないし、最悪自分で書けば済む。

それ以外は思想には同意するが、実際のやり方にはあまり賛同しない。が、当たってはいる。
学生の授業としては面白いだろう。選択教科なら名物になる可能性はある。(必修でこれはまずい)

2022/11/07(月) 08:54:30.27

お前らに話が通じないのは、お前らがコードを書かない連中だからだ。
だからリアルで例えてみる。Gitに習ってplumbing(配管工事)、つまり水道管だ。

一般的には、住宅に水道管を敷設する際、
高低差や区画情報(私有地ではなく道路の下しか通せない)を考慮し、
最初から、こういうツリー形状にすると計画を立ててから、工事をする。(設計)
勿論分譲予定が決まらなければ区画情報がないので無理だし、
測量が終わってなければ高低差情報が無いので無理だ。
そしていざ工事する際は、道路を封鎖することになるので、事前に告知し、
当日は誘導員を配置し、周辺交通の妨げにならないようにする。(リリースの計画)
敷設する水道管は当然新品だ。30-40年使えるようにね。(綺麗なコード)
そしてもし水漏れしたら、それが凍結による偶発的な事故なのか、
或いは何らかの設計ミスや施工ミスに依るものなのか、
また経年劣化で交換が必要なのか、検討する。
同じ事故を繰り返さない為にね。(レビュー)
これが一般的なやり方。
工事は順番だから、待たされることもある。
家庭で水漏れしたら、周辺の水道屋さん(当たり前だが資格試験はある)を頼って、大体数日後に直してもらえる。

2022/11/07(月) 08:55:05.40

バザールでは、水道が出ないより出た方が便利だから、各自が勝手に水道管を引いてしまう。(設計をしない)
水漏れしたら？その時に考えればいいよ。
いや実際漏れてるんだけど？ならパッチ当てよう。塞げばいいだけでしょ。
水の出が悪いんだけど？うーん、ちょっと高低差に無理があったからね、ポンプでも足そうか。
そんなことしたら水圧が上がって水道管割れちゃうよ？まあ、やってみればいいでしょ。
あ～あ、割れちゃったよ、てか錆すぎだろこれ！うん、だって元々中古だし。(最初からボロボロのコード)
え？最初は新品使うのが常識でしょ？いや、すぐ交換出来るんだからボロボロのでも問題ないでしょ。
いや～、毎回業者呼ぶの大変じゃない？業者？僕が工事すればいいだけだから問題ないよ。
え？それじゃ素人工事で全然駄目じゃん？いや、水漏れする度に何度でも工事すればいいだけでしょ。(ボロボロのパッチ)
でもやっぱ業者呼んだ方が…。そこまで言うなら、まあすぐ呼べるんだけど。秒速で対応してくれるし。
え？秒速？うん、水漏れしたんだけど！って言えば、誰かがあり得ない速度でシャシャッてきて交換部品(パッチ)とアドバイスをくれるんだよ。
そんなのあり得るの？うん、だって僕がその、世界規模での交換部品流通システムを開発したんだから。(Git)
とまあ、素人によるデタラメ工事＆秒速のモグラ叩き的修復で、乗り切ろうというわけだ。