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