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)
とまあ、素人によるデタラメ工事＆秒速のモグラ叩き的修復で、乗り切ろうというわけだ。

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

ってな感じ。これぐらいのギャップがある。
設計もしないし、一切のレビューもしないし、反省もしない。
だから事故りまくりだが、すぐに修復されるので、巨視的に見れば水道を使えてる時間は長い。
これが、従来型の工事と比べて、どっちがサービス提供時間が長いか、ということなんだと思う。
水道工事は物理的なので、どうしても道路を掘り返す手間がかかるから、従来型の方が普通はよいとされるはずだけど、
コードは、経年劣化はないし、(ただの情報なので)交換も極めて容易だから、このアプローチが出来てしまうのか？
って衝撃が「伽藍とバザール」だよ。
俺も今それをまざまざと見つけられてるわけだ。
しかし、この発想には付いていけないし、付いていきたくもない。
俺の家にはきちんと計画して新品の水道管を敷いて欲しいし、順当な範囲なら、工事の順番待ちもするよ。
それで、「お前が水道工事業者で、新品の水道管を持ってるのなら、寄越せ！」って言ってるのが今のお前らだ。
いやいやいや、そうだとしても、こいつらとは関わっちゃいけない、と思うのが普通でしょ。

ただ実際は、Linusが基本設計をしているので、LinuxもGitも、
「文系馬鹿だから管を繋げば水が出ると思ってて、水道が山を越えててまるで話にならない」
みたいなことはない。これが
> 9. 賢いデータ構造と間抜けなコードのほうが、その逆よりずっとまし。
で、Linusは基本設計を終えた上で、
末端の水道工事なら無資格業者でも全く問題ない、それより工事しない方が問題、としてるだけ。
実際、基本設計(水道ツリー)がきちんと出来てれば、各住宅付近の引き込みは、単に繋げるだけに近いのも事実。
バックエンドのGitデータ構造の出し入れだけきちっとしてれば、
フロントエンドの各コマンドなんてバグってたら交換すればいい程度なのも事実。
実際、今回のメモリリークなんてそのフロントエンド内でもさらにどうでもいい案件で、新品や資格業者を使うまでもない。
従来型は、工事である限り新品であり資格業者必須だが、これが問題だ！というわけ。

2022/11/07(月) 08:59:07.21

この辺は実はもっと長期スパンの戦略もあって、「わざと」ゴミパッチでもやらせてる可能性もある。
実は今プーチンがやろうとしてるのだけど、30万人動員だっけ？あれが適切か、について、
ウクライナの戦場だと、前線に動員された兵士が1年後に生き残ってる確率は10%位になってしまってるらしいのだが、
逆に言えば10%は生き残るわけで、30万人の素人を動員したら1年後にはその過酷な状況を生き残った3万人の精兵に化ける、
だから長期戦視野で、1年後に欲しい人数の10倍、素人でも構わないから動員してしまえ、そうすれば死にはするが供給は出来る、という話。
これはソフトウェアも同じで、保守人材が欲しいならそれなりに育てる必要はあって、
Git的なワークフローに慣れてもらう必要はある。
だから今はど素人のクソコードでも受け入れてれば、数年後には10%位は熟練者になって残ってくれるかも？という戦略だ。
今回は本当にどうでもいいバグではあるので、素人工事でも練習にはなるからやらせておけ、ということ。
だから意図的にレビューもせずにスルーしてる可能性もあるし、この戦略も一概に悪いとも言えない。
勿論こんなのではリークは止まらないが、元々バグを修復するのではなく、修復する練習が目的だから問題ない。
ただ一般的には、こういうのは資格取得時に技能含めて講習することであって、
いちいち水漏れ工事させてユーザーに迷惑かけつつ教育するもんじゃない！ではあるが、
言っちゃ悪いが新人のOJTでの飛び込み営業とか完全にこれだし、リアルでやってる連中もいる。(今はもう無いのかもしれんが)

だからまあ、俺は少なくともGitに対しては半年ROMるべきなんだよ。
連中の戦略がまるで見えない。そもそも何も考えてないっぽいが。
（いや待て、これは孔明の罠だ状態)

2022/11/07(月) 10:31:12.71

相手してしまってゴメン
もう見えないように設定した

2022/11/07(月) 11:56:14.65

長文の人、仕事したこととか共同作業したことあるんか？

2022/11/07(月) 13:20:11.88

やめろよまた長文レスが来るだろ。

2022/11/07(月) 20:02:36.71

>>32
草

2022/11/07(月) 21:23:08.09

>>16
それらのコマンドのレイヤーは、

init-db, show-diff
commit-tree
write-tree, read-tree
update-cache, cat-file

だろうよ。まあlinusだしちゃんとしてるよ。
最下位を差し替えれば最終形式(blog)を、
tree階層を差し替えれば記録先(ファイルシステム)を、
commit階層を差し替えれば鍵(SHA1)を変更出来る。
当たり前だがこんなのやってるに決まってるんだよ。OOPの基本中の基本だし。
プログラマではないお前らは理解出来なくてもいいが、それで噛みついてこられても困る。
そして逆に、今鍵の交換程度で手こずってるのなら、
馬鹿がこの階層をぶち壊して直接階層を跨いでアクセスしてしまってるんだろうさ。
パッチ見る限り全く階層の意識がないからね。
動けばいいとしか思ってない馬鹿が書いたコードだよあれは。
ただ、10人の普通の人より1,000,000人の馬鹿だ！という戦略だし、実際それで何とかなってるのも事実。

ちなみに故ジョブスは「優秀なプログラマと無能なプログラマの生産効率の差は200倍だ」と言ってたらしい。
これは俺の体感とも大体合う。
戦闘力(最大200)*10人=2,000では戦闘力1,000,000と喧嘩してもどうにもならないので、
全く納得いかないが、バザール方式はエンジニアリングとしては正しい。
単純には、社内10人でプロプライエタリするよりは、
オープンにして2,000人のプログラマ(サンデープログラマでも全く問題ない)を集められれば、勝てる事になる。

2022/11/07(月) 21:26:17.35

あと誰か、初期実装の時と現時点で、フォーマットが同じか知らないか？
上位互換か？(＝初期実装版で書いた.gitは最新版で問題なく読める)
それとも完全互換？(＝現最新版で書いた.gitは初期実装版でも問題なく読める)

P.S. bookのURLを何度か貼ってくれた人達ありがとう。
今読み進めてるが、俺にはbookの方が断然よかった。

2022/11/07(月) 21:26:22.00

もう勘弁してつかあさい

2022/11/07(月) 22:13:30.35

>>31にノータッチな時点でもう答え出てたね

2022/11/07(月) 23:00:12.96

10月の終わりから、What's cooking in git.git　を浜野氏以外の人がＭＬに投稿している。
浜野氏は不調なんかな？

2022/11/07(月) 23:03:36.95

bisect-in-c の一連のパッチが17回も修正して、浜野氏がいろいろ言って、
現在[Stalled] になってる。
作者のjs ってwindows 版作っている人で以前も浜野氏にパッチをrejectされまくりで
険悪な雰囲気になっていた記憶がある。

2022/11/07(月) 23:31:59.99

>>38
https://public-inbox.org/git/xmqqwn8mh1di.fsf@gitster.g/
> Starting from next week (week #4---see ...),
> we'll try a mini "bus factor" exercise, where I will disappear from
> the list for a few weeks. ...
メンテナ不在に耐えられるかのテスト中らしいよ。おもしろいことするね。

2022/11/07(月) 23:41:45.67

>>40
なるほど

2022/11/08(火) 02:36:21.93

>>37
それは最初から答え出て太郎。
少人数でも共同開発したことあるやつがコミットメッセージ不要とか言うわけはない。