ソースコード管理を行う分散型バージョン管理システム、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
Git 19
■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん (ﾜｯﾁｮｲ 8be4-Cw2/)
2022/11/06(日) 16:40:27.51ID:az1H5JFk02デフォルトの名無しさん (ﾜｯﾁｮｲ debb-qVfh)
2022/11/06(日) 17:05:45.20ID:FBkt/oHG0 乙
3デフォルトの名無しさん (ﾜｯﾁｮｲ ad14-pSqO)
2022/11/06(日) 20:50:19.64ID:VM2X6i580 前スレの結論
- git はバージョン管理ソフト
- バージョン管理ソフトはバックアップソフトじゃない
- 管理するのはソースコードじゃなくて変更履歴
- お前の汚い試行錯誤の作業履歴をバージョン管理するな
- gitはお前の作業の管理ツールではない
- コミットメッセージはきちんとかけ
- git はバージョン管理ソフト
- バージョン管理ソフトはバックアップソフトじゃない
- 管理するのはソースコードじゃなくて変更履歴
- お前の汚い試行錯誤の作業履歴をバージョン管理するな
- gitはお前の作業の管理ツールではない
- コミットメッセージはきちんとかけ
4デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss)
2022/11/06(日) 20:59:13.27ID:OfQ8ymDc0 前スレ>>1000
どうぞ。ってか俺が答える訳じゃないけどな。
どうぞ。ってか俺が答える訳じゃないけどな。
5デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss)
2022/11/06(日) 21:16:22.34ID:OfQ8ymDc0 前スレ>>999
それが本質的に違うんだよ。
連中はいわゆるコードの「清潔さ」に価値を置いてないから（一般価値観からすると）デタラメなコードになってる。
そこに「綺麗な」コードを持って行っても、
え？なに？綺麗なだけ？バグは直ってないの？なら要らないよ
になるんだよ。「綺麗な」コードは汚いコードと同じ動作をする、綺麗なだけのコードだから。
そして「汚い」コードの方が簡単に書ける（＝設計を必要としない）から、手数では負ける。
だからもう既に「汚い」コードのパッチが出てる時点で、
誰かが「綺麗な」コードを持ち寄っても連中の価値観では無視される。
（仮に採用されるとしても、今後とんでもない糞コードで上書きされる事になるので、コードを投げたくもない）
ただな、「綺麗な」コードの目的は、結局のところ長期的保守だから、
今も、今までも、この方法でずっと保守出来てる、
とする連中には、効かないし、確かに意味のないものかもしれないんだよ。
だけどこれは学術界からすると異端も異端、でもそれで確かに回っちゃってるんだから、
どうなのよこれ？なんだよ。どっちが正しいのか/適切なのかも俺にはよく分からん。
ただ俺は、綺麗なコードを書きたいし、それが良しとされる世界がいいから、とりあえず近づかずにいよう、って感じ。
多分一般Cの連中も同じじゃないかと思われる。だからあの状態なわけで。
まあこれはさておき、だからマージ回数とかも半端ないわけで、
> ブランチを切るのに大変時間がかかっていました。
> 大規模なプロジェクトになると数十秒かかったりすることもありました。
> Gitだとこの作業が一瞬でできます。（前スレ897)
で、Linusは「一日で480しかブランチ切れないようでは仕事にならない！」というわけだが、
そりゃあんただけで、世界の他の誰もそこに苦労してないから、そりゃそんなもん存在しないよ、でしかない。
だからもう、何もかもが根本的に違うんだよ。
それが本質的に違うんだよ。
連中はいわゆるコードの「清潔さ」に価値を置いてないから（一般価値観からすると）デタラメなコードになってる。
そこに「綺麗な」コードを持って行っても、
え？なに？綺麗なだけ？バグは直ってないの？なら要らないよ
になるんだよ。「綺麗な」コードは汚いコードと同じ動作をする、綺麗なだけのコードだから。
そして「汚い」コードの方が簡単に書ける（＝設計を必要としない）から、手数では負ける。
だからもう既に「汚い」コードのパッチが出てる時点で、
誰かが「綺麗な」コードを持ち寄っても連中の価値観では無視される。
（仮に採用されるとしても、今後とんでもない糞コードで上書きされる事になるので、コードを投げたくもない）
ただな、「綺麗な」コードの目的は、結局のところ長期的保守だから、
今も、今までも、この方法でずっと保守出来てる、
とする連中には、効かないし、確かに意味のないものかもしれないんだよ。
だけどこれは学術界からすると異端も異端、でもそれで確かに回っちゃってるんだから、
どうなのよこれ？なんだよ。どっちが正しいのか/適切なのかも俺にはよく分からん。
ただ俺は、綺麗なコードを書きたいし、それが良しとされる世界がいいから、とりあえず近づかずにいよう、って感じ。
多分一般Cの連中も同じじゃないかと思われる。だからあの状態なわけで。
まあこれはさておき、だからマージ回数とかも半端ないわけで、
> ブランチを切るのに大変時間がかかっていました。
> 大規模なプロジェクトになると数十秒かかったりすることもありました。
> Gitだとこの作業が一瞬でできます。（前スレ897)
で、Linusは「一日で480しかブランチ切れないようでは仕事にならない！」というわけだが、
そりゃあんただけで、世界の他の誰もそこに苦労してないから、そりゃそんなもん存在しないよ、でしかない。
だからもう、何もかもが根本的に違うんだよ。
6デフォルトの名無しさん (ﾜｯﾁｮｲ 852c-gUJl)
2022/11/06(日) 21:21:37.64ID:OQq0sbmT0 え、何？まだ続けるつもりなの？
てか、優秀な入門書とか既に出てるし大人しくそれ読んでりゃいいのに
てか、優秀な入門書とか既に出てるし大人しくそれ読んでりゃいいのに
7デフォルトの名無しさん (ﾜｯﾁｮｲ 515f-pSqO)
2022/11/06(日) 21:33:34.35ID:sj15aRfA0 >>5
> 連中はいわゆるコードの「清潔さ」に価値を置いてない
これがきみの思い込みで間違いであることは、きみの報告に対して挙がった 3 つのパッチの最後
"[PATCH 3/3] diff.c: use diff_free_queue()" が何の挙動も変えないコードクリーンアップである
ことを見れば明らかだね。
https://public-inbox.org/git/20221102220142.574890-4-szeder.dev@gmail.com/
思い込みで無意味な長文を垂れ流してスレを汚すのは止めていただきたい。
> 連中はいわゆるコードの「清潔さ」に価値を置いてない
これがきみの思い込みで間違いであることは、きみの報告に対して挙がった 3 つのパッチの最後
"[PATCH 3/3] diff.c: use diff_free_queue()" が何の挙動も変えないコードクリーンアップである
ことを見れば明らかだね。
https://public-inbox.org/git/20221102220142.574890-4-szeder.dev@gmail.com/
思い込みで無意味な長文を垂れ流してスレを汚すのは止めていただきたい。
8デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss)
2022/11/06(日) 21:51:26.30ID:OfQ8ymDc0 >>7
それ、コード構造が根本的に違うんだよ。
で、君のむかつきは、Git連中のむかつきそのもので、
俺や普通のCプログラマがいわゆるCコード持って行ったら、その対応なんだと分かるんだよ。
だから多分距離を置かれてる。
そして本人達はそれに気づいてない。けど困ってもいない。なんだかねー。
まー良く言えば多様性だねー(棒)
まあいいや、この話は結局所堂々巡りだし、続ける意味もないし、終わりにしようよ。
俺の持論としては、
「お前は分かってない、ということを相手に分からせるのが一番難しくて、それが出来れば8割終わってる」
なんだけど、まあ君らも俺に対して思ってるでしょ。そんなもんだよ。
それ、コード構造が根本的に違うんだよ。
で、君のむかつきは、Git連中のむかつきそのもので、
俺や普通のCプログラマがいわゆるCコード持って行ったら、その対応なんだと分かるんだよ。
だから多分距離を置かれてる。
そして本人達はそれに気づいてない。けど困ってもいない。なんだかねー。
まー良く言えば多様性だねー(棒)
まあいいや、この話は結局所堂々巡りだし、続ける意味もないし、終わりにしようよ。
俺の持論としては、
「お前は分かってない、ということを相手に分からせるのが一番難しくて、それが出来れば8割終わってる」
なんだけど、まあ君らも俺に対して思ってるでしょ。そんなもんだよ。
9デフォルトの名無しさん (ﾜｯﾁｮｲ debb-qVfh)
2022/11/06(日) 22:35:01.21ID:FBkt/oHG0 複数人の共同開発だと、綺麗なコード書くより、綺麗なパッチを書く方が生産性が高くなるんだよ。そして将来綺麗なパッチが書けるように予め備えておくこと。
変更の行数とかそんなのは誤差だよ。一番時間のかかるのは人間どうしの理解、コミュニケーションなので、そこの効率が良いのが良いコードで綺麗なパッチなんだよ。
コミットメッセージがむしろ本体。
変更の行数とかそんなのは誤差だよ。一番時間のかかるのは人間どうしの理解、コミュニケーションなので、そこの効率が良いのが良いコードで綺麗なパッチなんだよ。
コミットメッセージがむしろ本体。
10デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss)
2022/11/06(日) 22:54:22.81ID:OfQ8ymDc0 すまんがついで。
だから、Gitのコードをよくしたければ、Linusにレクチャーして貰えばいいんだよ。
そもそも彼のプロジェクトだし、彼は世界一に近い達人だし、彼の話ならGitの連中は聞くだろうし。
ちなみにLinusのコードはマジで凄い。
kernelコードでマクロで抽象化してるのがあって、
ブログ記事にしてる奴がいたからググれば出てくるはずだが、マジで記事書きたくなる位凄い。
こんな使い方あるのかよー、ってちょっと驚く。
OOPをCでやると全部手動だから面倒なのだけど、出来ないわけではない。
ただ、抽象はちょっときつくて、やったら普通にバグりそうなので俺ならやりたくないのだが、
はえー、なるほどこうすればいいのですかー、みたいなコードになってる。
で、Linusは送られてきたパッチに対して、
「僕はこういうコードを見るたびに、ああこの人はポインタの使い方を知らないのだな、と悲しくなるんだ」
とか言ってたから、コードを一応はレビューしてたんだろう。
だけど多分そのまま通してしまってるところが普通ではない。
もっとも、Linus基準だと、世界中の殆ど全てが糞コードなんだろうけどさ。
だから、Gitのコードをよくしたければ、Linusにレクチャーして貰えばいいんだよ。
そもそも彼のプロジェクトだし、彼は世界一に近い達人だし、彼の話ならGitの連中は聞くだろうし。
ちなみにLinusのコードはマジで凄い。
kernelコードでマクロで抽象化してるのがあって、
ブログ記事にしてる奴がいたからググれば出てくるはずだが、マジで記事書きたくなる位凄い。
こんな使い方あるのかよー、ってちょっと驚く。
OOPをCでやると全部手動だから面倒なのだけど、出来ないわけではない。
ただ、抽象はちょっときつくて、やったら普通にバグりそうなので俺ならやりたくないのだが、
はえー、なるほどこうすればいいのですかー、みたいなコードになってる。
で、Linusは送られてきたパッチに対して、
「僕はこういうコードを見るたびに、ああこの人はポインタの使い方を知らないのだな、と悲しくなるんだ」
とか言ってたから、コードを一応はレビューしてたんだろう。
だけど多分そのまま通してしまってるところが普通ではない。
もっとも、Linus基準だと、世界中の殆ど全てが糞コードなんだろうけどさ。
11デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss)
2022/11/06(日) 23:25:51.81ID:OfQ8ymDc0 >>9
> 綺麗なコード書くより、綺麗なパッチを書く方が生産性が高くなるんだよ。
それは根本的に違う。
綺麗なコードはバグを含みにくく、或いはバグだと見た瞬間分かるから、
将来的にパッチが要らない。だから、基本的戦略が
一般： バグが発生しないように綺麗なコードにしよう。(パッチを不要にする作戦）
Git： バグは直せばいい。目も手もある。だからコードは汚くても、パッチも汚くても、問題ない。
パッチなんていくらでも当てられるし、世界最高のパッチ適用システムを全員が熟知している。
(だから元のコードはボロボロでバグだらけでも大した問題にならない)
なんだよ。あのパッチも汚いよ。それが分からないのはお前の問題。
ただ、元のコードが汚いからパッチも汚いわけで、あの元コードで綺麗なパッチを書くのは無理だ。
だから本来はかなり大がかりな修正が必要なのだけど、誰も気づいてないし、指摘もしない。（ように見える）
ただ多分、その前の根本戦略も違ってて、
Gitが出来た2005頃は「動いているコードはいじるな」だったんだよ。
それが、2010頃からか？「動いているコードであっても、少しでも改善出来るならどんどん直せ」になってる。
これは前者だと本当にすさまじい勢いでコードが劣化するから、すぐに使い物にならなくなると分かったのと、
色々みんな隠蔽やリファクタに慣れてきて、「正しく構成していれば」割と安全に直せるようになったのがある。(多分)
Git見る限り、もしかするとまだ前者でやってるかもしれない。それだと多分この先いつか破綻する。
だからみんな危険を冒してリファクタしてるわけでさ。
（と言いたいところだが、普通の開発では完全に頓挫するレベルを既に明らかに越えているので、このまま行けるのかも？)
ただ9のコードについての見解は完全に間違いだし、釣りレベルだが、
人についてはまあその通りで、
バザール開発においては人を集められること＝目と手の数こそがパワーの源泉であるのは事実だ。
だからそれを取り持つGitシステムが重要なのも事実だ.。
でも、バグパッチのcommitメッセージがいくら綺麗でも、それで人は寄って来ないよ。やっぱたぶんLinusだと思うよ。
> 綺麗なコード書くより、綺麗なパッチを書く方が生産性が高くなるんだよ。
それは根本的に違う。
綺麗なコードはバグを含みにくく、或いはバグだと見た瞬間分かるから、
将来的にパッチが要らない。だから、基本的戦略が
一般： バグが発生しないように綺麗なコードにしよう。(パッチを不要にする作戦）
Git： バグは直せばいい。目も手もある。だからコードは汚くても、パッチも汚くても、問題ない。
パッチなんていくらでも当てられるし、世界最高のパッチ適用システムを全員が熟知している。
(だから元のコードはボロボロでバグだらけでも大した問題にならない)
なんだよ。あのパッチも汚いよ。それが分からないのはお前の問題。
ただ、元のコードが汚いからパッチも汚いわけで、あの元コードで綺麗なパッチを書くのは無理だ。
だから本来はかなり大がかりな修正が必要なのだけど、誰も気づいてないし、指摘もしない。（ように見える）
ただ多分、その前の根本戦略も違ってて、
Gitが出来た2005頃は「動いているコードはいじるな」だったんだよ。
それが、2010頃からか？「動いているコードであっても、少しでも改善出来るならどんどん直せ」になってる。
これは前者だと本当にすさまじい勢いでコードが劣化するから、すぐに使い物にならなくなると分かったのと、
色々みんな隠蔽やリファクタに慣れてきて、「正しく構成していれば」割と安全に直せるようになったのがある。(多分)
Git見る限り、もしかするとまだ前者でやってるかもしれない。それだと多分この先いつか破綻する。
だからみんな危険を冒してリファクタしてるわけでさ。
（と言いたいところだが、普通の開発では完全に頓挫するレベルを既に明らかに越えているので、このまま行けるのかも？)
ただ9のコードについての見解は完全に間違いだし、釣りレベルだが、
人についてはまあその通りで、
バザール開発においては人を集められること＝目と手の数こそがパワーの源泉であるのは事実だ。
だからそれを取り持つGitシステムが重要なのも事実だ.。
でも、バグパッチのcommitメッセージがいくら綺麗でも、それで人は寄って来ないよ。やっぱたぶんLinusだと思うよ。
12デフォルトの名無しさん (ﾜｯﾁｮｲ 09e4-chQ5)
2022/11/06(日) 23:52:01.89ID:az1H5JFk013デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss)
2022/11/06(日) 23:58:44.71ID:OfQ8ymDc0 >>12
初段階では関係ない。それは「動いていない」コードだから。
安定稼働した、もう追加機能もパッチもあまり必要ない、と思ってからの話になる。
俺の常識が通用する連中ではないが、普通は多分数年の安定稼働後だ。
初段階では関係ない。それは「動いていない」コードだから。
安定稼働した、もう追加機能もパッチもあまり必要ない、と思ってからの話になる。
俺の常識が通用する連中ではないが、普通は多分数年の安定稼働後だ。
14デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss)
2022/11/07(月) 00:00:33.44ID:FOShOpAE0 ちょっと言い方が悪かった。
お前ら、Gitはもうインフラだ！ファイル形式も変えられない！とか、言ってたろ。
そう思えてから、の話。
お前ら、Gitはもうインフラだ！ファイル形式も変えられない！とか、言ってたろ。
そう思えてから、の話。
15デフォルトの名無しさん (ﾜｯﾁｮｲ 09e4-chQ5)
2022/11/07(月) 00:04:01.53ID:Cj0S/1FH016デフォルトの名無しさん (ﾜｯﾁｮｲ 09e4-chQ5)
2022/11/07(月) 00:06:27.27ID:Cj0S/1FH0 一番最初のコミットe83c516331をcheckoutすると壮観だな7つの簡単なコマンドしかない
init-db update-cache show-diff write-tree read-tree commit-tree cat-file
makeが有る環境に持っていくのちょっと面倒だからやらないけど、これたぶん簡単にmakeできそうで、動きそう
init-db update-cache show-diff write-tree read-tree commit-tree cat-file
makeが有る環境に持っていくのちょっと面倒だからやらないけど、これたぶん簡単にmakeできそうで、動きそう
17デフォルトの名無しさん (ﾜｯﾁｮｲ 6e7c-Dn6t)
2022/11/07(月) 00:08:01.82ID:aqPNJv/g0 Gitないともう仕事できない
おっちょこちょいだからpush前にDiff見れるの超助かるわ
おっちょこちょいだからpush前にDiff見れるの超助かるわ
18デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss)
2022/11/07(月) 00:29:40.36ID:FOShOpAE0 >>15
ああ書き方が曖昧だったが、変わったのはソフトウェア工学/業界の戦略だよ。もっと大きい話。
Gitはどっちの戦略でいつ頃までやってて、なんて事は俺は全く知らん。
ただパッチ見る限り、何か制約でもあるのか？と思える位に不自然だというだけ。
直すところそこじゃねーだろ、みたいな。
ああ書き方が曖昧だったが、変わったのはソフトウェア工学/業界の戦略だよ。もっと大きい話。
Gitはどっちの戦略でいつ頃までやってて、なんて事は俺は全く知らん。
ただパッチ見る限り、何か制約でもあるのか？と思える位に不自然だというだけ。
直すところそこじゃねーだろ、みたいな。
19デフォルトの名無しさん (ﾜｯﾁｮｲ 09e4-chQ5)
2022/11/07(月) 00:32:07.26ID:Cj0S/1FH020デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss)
2022/11/07(月) 00:33:15.61ID:FOShOpAE021デフォルトの名無しさん (ﾜｯﾁｮｲ 09e4-chQ5)
2022/11/07(月) 00:36:35.26ID:Cj0S/1FH022デフォルトの名無しさん (ﾜｯﾁｮｲ debb-qVfh)
2022/11/07(月) 05:30:07.71ID:qUYbWD2h0 ド素人目。
「綺麗なコードだとバグを生まない」とか机上の空論なんだよ。人間はミスをするし機械は壊れるんだよ。
バグを生まないコードよりも、誰もが問題の原因をすぐに発見できてすぐに修正できる方が優れてるんだよ。
多数のプロジェクトの長年の経験によるベストプラクティス。
だから git 使うし、コミットメッセージをきちんと書くんだよ。コミットメッセージの有り難さとか理解できないやつが、バージョン管理ツールのスレで偉そうに語んな。
「綺麗なコードだとバグを生まない」とか机上の空論なんだよ。人間はミスをするし機械は壊れるんだよ。
バグを生まないコードよりも、誰もが問題の原因をすぐに発見できてすぐに修正できる方が優れてるんだよ。
多数のプロジェクトの長年の経験によるベストプラクティス。
だから git 使うし、コミットメッセージをきちんと書くんだよ。コミットメッセージの有り難さとか理解できないやつが、バージョン管理ツールのスレで偉そうに語んな。
23デフォルトの名無しさん (ﾜｯﾁｮｲ b114-pSqO)
2022/11/07(月) 06:17:25.58ID:9phkcvNE0 >>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 シェルやシェルスクリプトは
> これに向いた仕様になっている。それを見ていこう。
そもそもバグを生むのが間違い。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 シェルやシェルスクリプトは
> これに向いた仕様になっている。それを見ていこう。
24デフォルトの名無しさん (ﾜｯﾁｮｲ 85c2-evei)
2022/11/07(月) 07:52:49.70ID:4MIK6HWO0 いつまでしょうもないレスバトル続けんの？
25デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss)
2022/11/07(月) 08:50:06.37ID:FOShOpAE0 >>23
キャラ作りもあるのだろうけど、冒頭はクレイジーだな。
blob(ただのコンテナ)が取り出せなくなることはないし、最悪自分で書けば済む。
それ以外は思想には同意するが、実際のやり方にはあまり賛同しない。が、当たってはいる。
学生の授業としては面白いだろう。選択教科なら名物になる可能性はある。(必修でこれはまずい)
キャラ作りもあるのだろうけど、冒頭はクレイジーだな。
blob(ただのコンテナ)が取り出せなくなることはないし、最悪自分で書けば済む。
それ以外は思想には同意するが、実際のやり方にはあまり賛同しない。が、当たってはいる。
学生の授業としては面白いだろう。選択教科なら名物になる可能性はある。(必修でこれはまずい)
26デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss)
2022/11/07(月) 08:54:30.27ID:FOShOpAE0 お前らに話が通じないのは、お前らがコードを書かない連中だからだ。
だからリアルで例えてみる。Gitに習ってplumbing(配管工事)、つまり水道管だ。
一般的には、住宅に水道管を敷設する際、
高低差や区画情報(私有地ではなく道路の下しか通せない)を考慮し、
最初から、こういうツリー形状にすると計画を立ててから、工事をする。(設計)
勿論分譲予定が決まらなければ区画情報がないので無理だし、
測量が終わってなければ高低差情報が無いので無理だ。
そしていざ工事する際は、道路を封鎖することになるので、事前に告知し、
当日は誘導員を配置し、周辺交通の妨げにならないようにする。(リリースの計画)
敷設する水道管は当然新品だ。30-40年使えるようにね。(綺麗なコード)
そしてもし水漏れしたら、それが凍結による偶発的な事故なのか、
或いは何らかの設計ミスや施工ミスに依るものなのか、
また経年劣化で交換が必要なのか、検討する。
同じ事故を繰り返さない為にね。(レビュー)
これが一般的なやり方。
工事は順番だから、待たされることもある。
家庭で水漏れしたら、周辺の水道屋さん(当たり前だが資格試験はある)を頼って、大体数日後に直してもらえる。
だからリアルで例えてみる。Gitに習ってplumbing(配管工事)、つまり水道管だ。
一般的には、住宅に水道管を敷設する際、
高低差や区画情報(私有地ではなく道路の下しか通せない)を考慮し、
最初から、こういうツリー形状にすると計画を立ててから、工事をする。(設計)
勿論分譲予定が決まらなければ区画情報がないので無理だし、
測量が終わってなければ高低差情報が無いので無理だ。
そしていざ工事する際は、道路を封鎖することになるので、事前に告知し、
当日は誘導員を配置し、周辺交通の妨げにならないようにする。(リリースの計画)
敷設する水道管は当然新品だ。30-40年使えるようにね。(綺麗なコード)
そしてもし水漏れしたら、それが凍結による偶発的な事故なのか、
或いは何らかの設計ミスや施工ミスに依るものなのか、
また経年劣化で交換が必要なのか、検討する。
同じ事故を繰り返さない為にね。(レビュー)
これが一般的なやり方。
工事は順番だから、待たされることもある。
家庭で水漏れしたら、周辺の水道屋さん(当たり前だが資格試験はある)を頼って、大体数日後に直してもらえる。
27デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss)
2022/11/07(月) 08:55:05.40ID:FOShOpAE0 バザールでは、水道が出ないより出た方が便利だから、各自が勝手に水道管を引いてしまう。(設計をしない)
水漏れしたら？その時に考えればいいよ。
いや実際漏れてるんだけど？ならパッチ当てよう。塞げばいいだけでしょ。
水の出が悪いんだけど？うーん、ちょっと高低差に無理があったからね、ポンプでも足そうか。
そんなことしたら水圧が上がって水道管割れちゃうよ？まあ、やってみればいいでしょ。
あ～あ、割れちゃったよ、てか錆すぎだろこれ！うん、だって元々中古だし。(最初からボロボロのコード)
え？最初は新品使うのが常識でしょ？いや、すぐ交換出来るんだからボロボロのでも問題ないでしょ。
いや～、毎回業者呼ぶの大変じゃない？業者？僕が工事すればいいだけだから問題ないよ。
え？それじゃ素人工事で全然駄目じゃん？いや、水漏れする度に何度でも工事すればいいだけでしょ。(ボロボロのパッチ)
でもやっぱ業者呼んだ方が…。そこまで言うなら、まあすぐ呼べるんだけど。秒速で対応してくれるし。
え？秒速？うん、水漏れしたんだけど！って言えば、誰かがあり得ない速度でシャシャッてきて交換部品(パッチ)とアドバイスをくれるんだよ。
そんなのあり得るの？うん、だって僕がその、世界規模での交換部品流通システムを開発したんだから。(Git)
とまあ、素人によるデタラメ工事＆秒速のモグラ叩き的修復で、乗り切ろうというわけだ。
水漏れしたら？その時に考えればいいよ。
いや実際漏れてるんだけど？ならパッチ当てよう。塞げばいいだけでしょ。
水の出が悪いんだけど？うーん、ちょっと高低差に無理があったからね、ポンプでも足そうか。
そんなことしたら水圧が上がって水道管割れちゃうよ？まあ、やってみればいいでしょ。
あ～あ、割れちゃったよ、てか錆すぎだろこれ！うん、だって元々中古だし。(最初からボロボロのコード)
え？最初は新品使うのが常識でしょ？いや、すぐ交換出来るんだからボロボロのでも問題ないでしょ。
いや～、毎回業者呼ぶの大変じゃない？業者？僕が工事すればいいだけだから問題ないよ。
え？それじゃ素人工事で全然駄目じゃん？いや、水漏れする度に何度でも工事すればいいだけでしょ。(ボロボロのパッチ)
でもやっぱ業者呼んだ方が…。そこまで言うなら、まあすぐ呼べるんだけど。秒速で対応してくれるし。
え？秒速？うん、水漏れしたんだけど！って言えば、誰かがあり得ない速度でシャシャッてきて交換部品(パッチ)とアドバイスをくれるんだよ。
そんなのあり得るの？うん、だって僕がその、世界規模での交換部品流通システムを開発したんだから。(Git)
とまあ、素人によるデタラメ工事＆秒速のモグラ叩き的修復で、乗り切ろうというわけだ。
28デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss)
2022/11/07(月) 08:55:55.03ID:FOShOpAE0 ってな感じ。これぐらいのギャップがある。
設計もしないし、一切のレビューもしないし、反省もしない。
だから事故りまくりだが、すぐに修復されるので、巨視的に見れば水道を使えてる時間は長い。
これが、従来型の工事と比べて、どっちがサービス提供時間が長いか、ということなんだと思う。
水道工事は物理的なので、どうしても道路を掘り返す手間がかかるから、従来型の方が普通はよいとされるはずだけど、
コードは、経年劣化はないし、(ただの情報なので)交換も極めて容易だから、このアプローチが出来てしまうのか？
って衝撃が「伽藍とバザール」だよ。
俺も今それをまざまざと見つけられてるわけだ。
しかし、この発想には付いていけないし、付いていきたくもない。
俺の家にはきちんと計画して新品の水道管を敷いて欲しいし、順当な範囲なら、工事の順番待ちもするよ。
それで、「お前が水道工事業者で、新品の水道管を持ってるのなら、寄越せ！」って言ってるのが今のお前らだ。
いやいやいや、そうだとしても、こいつらとは関わっちゃいけない、と思うのが普通でしょ。
ただ実際は、Linusが基本設計をしているので、LinuxもGitも、
「文系馬鹿だから管を繋げば水が出ると思ってて、水道が山を越えててまるで話にならない」
みたいなことはない。これが
> 9. 賢いデータ構造と間抜けなコードのほうが、その逆よりずっとまし。
で、Linusは基本設計を終えた上で、
末端の水道工事なら無資格業者でも全く問題ない、それより工事しない方が問題、としてるだけ。
実際、基本設計(水道ツリー)がきちんと出来てれば、各住宅付近の引き込みは、単に繋げるだけに近いのも事実。
バックエンドのGitデータ構造の出し入れだけきちっとしてれば、
フロントエンドの各コマンドなんてバグってたら交換すればいい程度なのも事実。
実際、今回のメモリリークなんてそのフロントエンド内でもさらにどうでもいい案件で、新品や資格業者を使うまでもない。
従来型は、工事である限り新品であり資格業者必須だが、これが問題だ！というわけ。
設計もしないし、一切のレビューもしないし、反省もしない。
だから事故りまくりだが、すぐに修復されるので、巨視的に見れば水道を使えてる時間は長い。
これが、従来型の工事と比べて、どっちがサービス提供時間が長いか、ということなんだと思う。
水道工事は物理的なので、どうしても道路を掘り返す手間がかかるから、従来型の方が普通はよいとされるはずだけど、
コードは、経年劣化はないし、(ただの情報なので)交換も極めて容易だから、このアプローチが出来てしまうのか？
って衝撃が「伽藍とバザール」だよ。
俺も今それをまざまざと見つけられてるわけだ。
しかし、この発想には付いていけないし、付いていきたくもない。
俺の家にはきちんと計画して新品の水道管を敷いて欲しいし、順当な範囲なら、工事の順番待ちもするよ。
それで、「お前が水道工事業者で、新品の水道管を持ってるのなら、寄越せ！」って言ってるのが今のお前らだ。
いやいやいや、そうだとしても、こいつらとは関わっちゃいけない、と思うのが普通でしょ。
ただ実際は、Linusが基本設計をしているので、LinuxもGitも、
「文系馬鹿だから管を繋げば水が出ると思ってて、水道が山を越えててまるで話にならない」
みたいなことはない。これが
> 9. 賢いデータ構造と間抜けなコードのほうが、その逆よりずっとまし。
で、Linusは基本設計を終えた上で、
末端の水道工事なら無資格業者でも全く問題ない、それより工事しない方が問題、としてるだけ。
実際、基本設計(水道ツリー)がきちんと出来てれば、各住宅付近の引き込みは、単に繋げるだけに近いのも事実。
バックエンドのGitデータ構造の出し入れだけきちっとしてれば、
フロントエンドの各コマンドなんてバグってたら交換すればいい程度なのも事実。
実際、今回のメモリリークなんてそのフロントエンド内でもさらにどうでもいい案件で、新品や資格業者を使うまでもない。
従来型は、工事である限り新品であり資格業者必須だが、これが問題だ！というわけ。
29デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss)
2022/11/07(月) 08:59:07.21ID:FOShOpAE0 この辺は実はもっと長期スパンの戦略もあって、「わざと」ゴミパッチでもやらせてる可能性もある。
実は今プーチンがやろうとしてるのだけど、30万人動員だっけ？あれが適切か、について、
ウクライナの戦場だと、前線に動員された兵士が1年後に生き残ってる確率は10%位になってしまってるらしいのだが、
逆に言えば10%は生き残るわけで、30万人の素人を動員したら1年後にはその過酷な状況を生き残った3万人の精兵に化ける、
だから長期戦視野で、1年後に欲しい人数の10倍、素人でも構わないから動員してしまえ、そうすれば死にはするが供給は出来る、という話。
これはソフトウェアも同じで、保守人材が欲しいならそれなりに育てる必要はあって、
Git的なワークフローに慣れてもらう必要はある。
だから今はど素人のクソコードでも受け入れてれば、数年後には10%位は熟練者になって残ってくれるかも？という戦略だ。
今回は本当にどうでもいいバグではあるので、素人工事でも練習にはなるからやらせておけ、ということ。
だから意図的にレビューもせずにスルーしてる可能性もあるし、この戦略も一概に悪いとも言えない。
勿論こんなのではリークは止まらないが、元々バグを修復するのではなく、修復する練習が目的だから問題ない。
ただ一般的には、こういうのは資格取得時に技能含めて講習することであって、
いちいち水漏れ工事させてユーザーに迷惑かけつつ教育するもんじゃない！ではあるが、
言っちゃ悪いが新人のOJTでの飛び込み営業とか完全にこれだし、リアルでやってる連中もいる。(今はもう無いのかもしれんが)
だからまあ、俺は少なくともGitに対しては半年ROMるべきなんだよ。
連中の戦略がまるで見えない。そもそも何も考えてないっぽいが。
（いや待て、これは孔明の罠だ状態)
実は今プーチンがやろうとしてるのだけど、30万人動員だっけ？あれが適切か、について、
ウクライナの戦場だと、前線に動員された兵士が1年後に生き残ってる確率は10%位になってしまってるらしいのだが、
逆に言えば10%は生き残るわけで、30万人の素人を動員したら1年後にはその過酷な状況を生き残った3万人の精兵に化ける、
だから長期戦視野で、1年後に欲しい人数の10倍、素人でも構わないから動員してしまえ、そうすれば死にはするが供給は出来る、という話。
これはソフトウェアも同じで、保守人材が欲しいならそれなりに育てる必要はあって、
Git的なワークフローに慣れてもらう必要はある。
だから今はど素人のクソコードでも受け入れてれば、数年後には10%位は熟練者になって残ってくれるかも？という戦略だ。
今回は本当にどうでもいいバグではあるので、素人工事でも練習にはなるからやらせておけ、ということ。
だから意図的にレビューもせずにスルーしてる可能性もあるし、この戦略も一概に悪いとも言えない。
勿論こんなのではリークは止まらないが、元々バグを修復するのではなく、修復する練習が目的だから問題ない。
ただ一般的には、こういうのは資格取得時に技能含めて講習することであって、
いちいち水漏れ工事させてユーザーに迷惑かけつつ教育するもんじゃない！ではあるが、
言っちゃ悪いが新人のOJTでの飛び込み営業とか完全にこれだし、リアルでやってる連中もいる。(今はもう無いのかもしれんが)
だからまあ、俺は少なくともGitに対しては半年ROMるべきなんだよ。
連中の戦略がまるで見えない。そもそも何も考えてないっぽいが。
（いや待て、これは孔明の罠だ状態)
30デフォルトの名無しさん (ﾜｯﾁｮｲ 09e4-1bV6)
2022/11/07(月) 10:31:12.71ID:Cj0S/1FH0 相手してしまってゴメン
もう見えないように設定した
もう見えないように設定した
31デフォルトの名無しさん (ｱｳｱｳｳｰ Sacd-oA9A)
2022/11/07(月) 11:56:14.65ID:cJG23Zwza 長文の人、仕事したこととか共同作業したことあるんか？
32デフォルトの名無しさん (ﾜｯﾁｮｲ 515f-pSqO)
2022/11/07(月) 13:20:11.88ID:ygJfBeHE0 やめろよまた長文レスが来るだろ。
33デフォルトの名無しさん (ｵｯﾍﾟｹ Sr79-sZZ3)
2022/11/07(月) 20:02:36.71ID:4UzpVkkhr >>32
草
草
34デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss)
2022/11/07(月) 21:23:08.09ID:FOShOpAE0 >>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人のプログラマ(サンデープログラマでも全く問題ない)を集められれば、勝てる事になる。
それらのコマンドのレイヤーは、
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人のプログラマ(サンデープログラマでも全く問題ない)を集められれば、勝てる事になる。
35デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss)
2022/11/07(月) 21:26:17.35ID:FOShOpAE0 あと誰か、初期実装の時と現時点で、フォーマットが同じか知らないか？
上位互換か？(＝初期実装版で書いた.gitは最新版で問題なく読める)
それとも完全互換？(＝現最新版で書いた.gitは初期実装版でも問題なく読める)
P.S. bookのURLを何度か貼ってくれた人達ありがとう。
今読み進めてるが、俺にはbookの方が断然よかった。
上位互換か？(＝初期実装版で書いた.gitは最新版で問題なく読める)
それとも完全互換？(＝現最新版で書いた.gitは初期実装版でも問題なく読める)
P.S. bookのURLを何度か貼ってくれた人達ありがとう。
今読み進めてるが、俺にはbookの方が断然よかった。
36デフォルトの名無しさん (ﾜｯﾁｮｲ 85c2-evei)
2022/11/07(月) 21:26:22.00ID:4MIK6HWO0 もう勘弁してつかあさい
37デフォルトの名無しさん (ｵｯﾍﾟｹ Sr79-sZZ3)
2022/11/07(月) 22:13:30.35ID:4UzpVkkhr >>31にノータッチな時点でもう答え出てたね
38デフォルトの名無しさん (ﾜｯﾁｮｲ f510-zlm6)
2022/11/07(月) 23:00:12.96ID:uxPQwm720 10月の終わりから、What's cooking in git.git を浜野氏以外の人がＭＬに投稿している。
浜野氏は不調なんかな？
浜野氏は不調なんかな？
39デフォルトの名無しさん (ﾜｯﾁｮｲ f510-zlm6)
2022/11/07(月) 23:03:36.95ID:uxPQwm720 bisect-in-c の一連のパッチが17回も修正して、浜野氏がいろいろ言って、
現在[Stalled] になってる。
作者のjs ってwindows 版作っている人で以前も浜野氏にパッチをrejectされまくりで
険悪な雰囲気になっていた記憶がある。
現在[Stalled] になってる。
作者のjs ってwindows 版作っている人で以前も浜野氏にパッチをrejectされまくりで
険悪な雰囲気になっていた記憶がある。
40デフォルトの名無しさん (ﾜｯﾁｮｲ 515f-pSqO)
2022/11/07(月) 23:31:59.99ID:ygJfBeHE0 >>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. ...
メンテナ不在に耐えられるかのテスト中らしいよ。おもしろいことするね。
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. ...
メンテナ不在に耐えられるかのテスト中らしいよ。おもしろいことするね。
41デフォルトの名無しさん (ﾜｯﾁｮｲ f510-EsyA)
2022/11/07(月) 23:41:45.67ID:uxPQwm720 >>40
なるほど
なるほど
42デフォルトの名無しさん (ﾜｯﾁｮｲ debb-qVfh)
2022/11/08(火) 02:36:21.93ID:JjaG4816043デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss)
2022/11/08(火) 06:57:02.11ID:0xdMrcDS0 >>42
まあお前らがGit屋だってのはよく分かったよ
まあお前らがGit屋だってのはよく分かったよ
44デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss)
2022/11/08(火) 09:23:56.98ID:0xdMrcDS0 ついでだからソースを読めない君達にも分かるように、あのパッチのヤバさを説明してみよう。
バグ＝ゴキブリ出現と例える。
嫌悪感がある人はここで読むのを止めてくれ。
バグ＝ゴキブリ出現と例える。
嫌悪感がある人はここで読むのを止めてくれ。
45デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss)
2022/11/08(火) 09:24:55.86ID:0xdMrcDS0 俺「あ、ゴキブリっぽい何か見つけました」
Git「はいゴキブリですね。ゴキブリホイホイを設置しました！」
Git「１箇所では足りないようなので、複数箇所にゴキブリホイホイを設置しました！」
Git「木目調のゴキブリホイホイに変更しました！」
いや違うだろぉぉぉぉぉぉぉ！そうじゃねえだろぉぉぉ！
ゴキブリの侵入経路を確認して塞ぐとか、
冷蔵庫や戸棚どかして一切全部掃除し直してさらにバルサン炊くとかだろぉぉぉぉ！
(言ってないけど)
Git「え？でもゴキブリが出る所全部にゴキブリホイホイを設置すれば、ゴキブリには遭遇しなくなりますよ？
見た目？そのための木目調のゴキブリホイホイですよ？なんなら好きなキャラ描いて書いて貰ってもいいですよ？
それでは無限にゴキブリが出る？なら無限にゴキブリホイホイ設置するだけですよ？」
こりゃ駄目だ、話が通じねえ、と思うだろ。
Gitの連中はバグの表面的なところだけを繕ってて、そのバグが発生した根本の原因、
つまり今回は壁がボロボロで穴が空きまくっててゴキブリが侵入してきてるんだけど、そこを見ようともしてないんだ。
というより、壁がボロボロだからゴキブリが侵入して来る、という感覚そのものがない。(因果関係を考えてない)
だから壁を直そうとかいう話に繋がらないんだよ。
そしていくらでもゴキブリホイホイを設置すれば、遭遇しなくなると思ってる。
(そりゃそうかもしれないが、そうじゃねえだろぉぉぉ！と叫びたくもなるだろ)
だから今回のパッチ、明らかに方向性が違うから、
俺だったら、というより従来型のCプログラマなら、見た瞬間rejectするんだよ。
それが分からない連中が、大まじめにゴキブリホイホイ設置して喜んでるんだから、こりゃ関わっちゃいけない、と思うだろ。
しかしこれで回ってる。
Gitにやられた連中は、アニメや映画の悪役ばりに、「く、、っこんな奴に！！！」と思ってるだろうさ。
正しい対応： 壁の塗り直し/補修
まだ許せる対応： バルサン
Gitで行われる対応： ゴキブリホイホイの多数設置
Git「はいゴキブリですね。ゴキブリホイホイを設置しました！」
Git「１箇所では足りないようなので、複数箇所にゴキブリホイホイを設置しました！」
Git「木目調のゴキブリホイホイに変更しました！」
いや違うだろぉぉぉぉぉぉぉ！そうじゃねえだろぉぉぉ！
ゴキブリの侵入経路を確認して塞ぐとか、
冷蔵庫や戸棚どかして一切全部掃除し直してさらにバルサン炊くとかだろぉぉぉぉ！
(言ってないけど)
Git「え？でもゴキブリが出る所全部にゴキブリホイホイを設置すれば、ゴキブリには遭遇しなくなりますよ？
見た目？そのための木目調のゴキブリホイホイですよ？なんなら好きなキャラ描いて書いて貰ってもいいですよ？
それでは無限にゴキブリが出る？なら無限にゴキブリホイホイ設置するだけですよ？」
こりゃ駄目だ、話が通じねえ、と思うだろ。
Gitの連中はバグの表面的なところだけを繕ってて、そのバグが発生した根本の原因、
つまり今回は壁がボロボロで穴が空きまくっててゴキブリが侵入してきてるんだけど、そこを見ようともしてないんだ。
というより、壁がボロボロだからゴキブリが侵入して来る、という感覚そのものがない。(因果関係を考えてない)
だから壁を直そうとかいう話に繋がらないんだよ。
そしていくらでもゴキブリホイホイを設置すれば、遭遇しなくなると思ってる。
(そりゃそうかもしれないが、そうじゃねえだろぉぉぉ！と叫びたくもなるだろ)
だから今回のパッチ、明らかに方向性が違うから、
俺だったら、というより従来型のCプログラマなら、見た瞬間rejectするんだよ。
それが分からない連中が、大まじめにゴキブリホイホイ設置して喜んでるんだから、こりゃ関わっちゃいけない、と思うだろ。
しかしこれで回ってる。
Gitにやられた連中は、アニメや映画の悪役ばりに、「く、、っこんな奴に！！！」と思ってるだろうさ。
正しい対応： 壁の塗り直し/補修
まだ許せる対応： バルサン
Gitで行われる対応： ゴキブリホイホイの多数設置
46デフォルトの名無しさん (ﾜｯﾁｮｲ debb-qVfh)
2022/11/08(火) 09:54:49.01ID:JjaG48160 口先乙
長文書いてる暇があったらお前のいう正しいコードを書いて公開して見ろよ。
別に採用されなくても長文でグダグダ書くよりコードで見せた方が早いだろ。
言ってることが事実ならコードで見せれるだろ。お前ならどうするか具体的に見せろよ。
それが今すぐできないんなら、お前の主張は無価値な机上の空論ってことになる。
長文書いてる暇があったらお前のいう正しいコードを書いて公開して見ろよ。
別に採用されなくても長文でグダグダ書くよりコードで見せた方が早いだろ。
言ってることが事実ならコードで見せれるだろ。お前ならどうするか具体的に見せろよ。
それが今すぐできないんなら、お前の主張は無価値な机上の空論ってことになる。
47デフォルトの名無しさん (ﾜｯﾁｮｲ 515f-pSqO)
2022/11/08(火) 09:59:26.44ID:Nwn3p3fK0 やめろよまた長文でやらない理由レスがくるだろ。
48デフォルトの名無しさん (ﾜｯﾁｮｲ ad17-koQr)
2022/11/08(火) 10:35:58.86ID:jk+PH9G/0 https://github.com/Byron/gitoxide
誰かやるかなあと思ったらやっぱりいた
誰かやるかなあと思ったらやっぱりいた
49デフォルトの名無しさん (ｵｯﾍﾟｹ Sr79-sZZ3)
2022/11/08(火) 17:23:38.36ID:LFTDtpXpr50デフォルトの名無しさん (ﾜｯﾁｮｲ debb-qVfh)
2022/11/09(水) 02:28:31.49ID:zaNhnmv/0 >>49
git の人気が悔しくて悪口書きにきてるだけだから具体例とか出るわけないよ。
git の人気が悔しくて悪口書きにきてるだけだから具体例とか出るわけないよ。
51デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss)
2022/11/09(水) 06:24:34.62ID:raFZ+G/S052デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss)
2022/11/09(水) 06:25:32.42ID:raFZ+G/S053デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss)
2022/11/09(水) 06:27:44.26ID:raFZ+G/S0 >>46
そうやって無駄に煽ってネット上の善意を吸収/浪費してきたのだろうよ。
コードクレクレ君は死ね。
(ただ本当に、誰でも書けるレベルのコードすら書けてないことをGit陣営は自覚した方がいい。
というか、書けない、ではなく、書かない、に近くて、
美しいコードに価値なんて無い、だからデタラメでもいいからさっさと書け、という価値観が見える。今の君にもね）
しかし俺としては「美しいコードは素晴らしい」という価値観の世界にしたいので、
Gitの状況を知った現在、Gitには肩入れしたくないんだな。
むしろ反Gitに肩入れして、Gitを殲滅したくなってきてる。
こんな価値観の連中をのさばらせておくのは、よろしくない。
多分今後はバグ報告も送らない。
だってあれに俺は3-6時間かかってるけど、まるで生かせてないし、見る限り無駄だったよ。
ただここで色々君らに情報を貰ったのは感謝してる。前スレ最後で数時間相手してくれた人には特に。
あと、大昔にさっぱり意味が分からなかった(事すら認識出来てなかった)「伽藍とバザール」を理解出来たのはよかったけど。
お前らのオススメのGit以外のOSSのVCSって、SubVersionなのか？
バケツに構ってる場合じゃないんだけど、いつか見てみるよ。
ただ飲食店が衛生的/不衛生なのと、美味い/不味いは別の軸だからな～。
VCSの根本の問題は、「管理側」が作ってることなんだろう。
Gitは「使う側」が作ったから、プログラマにとっては既存のVCSより断然仕様がいい。
ただLinusは「mergeしかしない側」だから、merge特化で、
俺みたいに日々の業務の履歴保持やバックアップ用には出来て無く、使い心地が悪い。
なら今後、「使う側」が「日々の業務用」のVCSを作れば決定版になるのだろう。
ただ、Gitに問題を感じないのだから、
Linusのコードの書き方はかなり最初期からアジャイルで、一般とは違うのか？とも思ってる。
(究極のアジャイルが>>23)
この辺も後日確認する予定。
そうやって無駄に煽ってネット上の善意を吸収/浪費してきたのだろうよ。
コードクレクレ君は死ね。
(ただ本当に、誰でも書けるレベルのコードすら書けてないことをGit陣営は自覚した方がいい。
というか、書けない、ではなく、書かない、に近くて、
美しいコードに価値なんて無い、だからデタラメでもいいからさっさと書け、という価値観が見える。今の君にもね）
しかし俺としては「美しいコードは素晴らしい」という価値観の世界にしたいので、
Gitの状況を知った現在、Gitには肩入れしたくないんだな。
むしろ反Gitに肩入れして、Gitを殲滅したくなってきてる。
こんな価値観の連中をのさばらせておくのは、よろしくない。
多分今後はバグ報告も送らない。
だってあれに俺は3-6時間かかってるけど、まるで生かせてないし、見る限り無駄だったよ。
ただここで色々君らに情報を貰ったのは感謝してる。前スレ最後で数時間相手してくれた人には特に。
あと、大昔にさっぱり意味が分からなかった(事すら認識出来てなかった)「伽藍とバザール」を理解出来たのはよかったけど。
お前らのオススメのGit以外のOSSのVCSって、SubVersionなのか？
バケツに構ってる場合じゃないんだけど、いつか見てみるよ。
ただ飲食店が衛生的/不衛生なのと、美味い/不味いは別の軸だからな～。
VCSの根本の問題は、「管理側」が作ってることなんだろう。
Gitは「使う側」が作ったから、プログラマにとっては既存のVCSより断然仕様がいい。
ただLinusは「mergeしかしない側」だから、merge特化で、
俺みたいに日々の業務の履歴保持やバックアップ用には出来て無く、使い心地が悪い。
なら今後、「使う側」が「日々の業務用」のVCSを作れば決定版になるのだろう。
ただ、Gitに問題を感じないのだから、
Linusのコードの書き方はかなり最初期からアジャイルで、一般とは違うのか？とも思ってる。
(究極のアジャイルが>>23)
この辺も後日確認する予定。
54デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss)
2022/11/09(水) 06:33:44.28ID:raFZ+G/S0 あとさらについで。既に書いたように俺は君達には感謝してるから、
君達の成長の糧になるネタを残しておこう。俺なりの返礼だ。
Git陣営も、君達も、チームで働く意味を理解出来ていない。
チームを上手く機能させるには、「自分」ではなく「相手」の仕事を減らさないといけない。
そしてお互いに「相手」の仕事を減らす事により、チーム全体の仕事量が減り、生産効率が上がる。
これの古典的手法がドキュメントで、まあGitはこの点は十分出来てるよ。
(前言った解像度の不一致の件、あれは直しておいてくれ。ただ全般的にはかなりよく出来てる類だ)
だけど今回の顛末、俺は3-6時間かけて、丁寧にバグレポートを上げた。
再現コードをわざわざ作り直し、途中で出てきた回避策も入れて、最終チェックもした。
雑なレポートなら1-2時間で出来るところ、3時間ほど余分にかけて精度を上げてる。
一発で分かりやすく再現しなければ、余分に1-2時間ほど確認作業が必要になってしまう。
仮に5人で対応してくれた場合、そんなことで「チームとして」5-10時間消費するより、
俺があらかじめ3時間消費して精度を上げた方が、「チームとして」2-7時間得する、という戦略なんだよ。
君達の成長の糧になるネタを残しておこう。俺なりの返礼だ。
Git陣営も、君達も、チームで働く意味を理解出来ていない。
チームを上手く機能させるには、「自分」ではなく「相手」の仕事を減らさないといけない。
そしてお互いに「相手」の仕事を減らす事により、チーム全体の仕事量が減り、生産効率が上がる。
これの古典的手法がドキュメントで、まあGitはこの点は十分出来てるよ。
(前言った解像度の不一致の件、あれは直しておいてくれ。ただ全般的にはかなりよく出来てる類だ)
だけど今回の顛末、俺は3-6時間かけて、丁寧にバグレポートを上げた。
再現コードをわざわざ作り直し、途中で出てきた回避策も入れて、最終チェックもした。
雑なレポートなら1-2時間で出来るところ、3時間ほど余分にかけて精度を上げてる。
一発で分かりやすく再現しなければ、余分に1-2時間ほど確認作業が必要になってしまう。
仮に5人で対応してくれた場合、そんなことで「チームとして」5-10時間消費するより、
俺があらかじめ3時間消費して精度を上げた方が、「チームとして」2-7時間得する、という戦略なんだよ。
55デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss)
2022/11/09(水) 06:34:47.94ID:raFZ+G/S0 Gitの連中は、俺のレポートで、「同種のバグの存在」を全く気にしていない。
それが彼等の技術的問題か、人格的問題かは分からないけど、
壁に穴が空いてることを気にせず、ゴキブリホイホイを多数設置して済ませようとしてる。
これだと、今回のではバグは収まらず、「同種のバグレポート」が、多分あと10通位必要だ。
そりゃ確かにあと10通来てその都度対応すれば全経路にゴキブリホイホイを設置出来るかもしれない。
だけどこれは、俺と同様の通報者だけで30-60時間消費、さらに対応する連中も数時間ずつ、
まあ単純に3時間として、5人なら3時間*5人*10回＝150時間消費するから、合計180-210時間消費することになる。
なら、最初のパッチを作る奴が10時間ほどかけて精査し、
「う～ん、これは壁の大規模補修が必要で、あと30時間ほどかかりますのでお待ち下さい」でも40時間の消費で、
140-170時間の黒字になるんだよ。だから本来はこれを目指さないといけない。
これが「バザール」で出来る事かどうかは俺には分からないけれども、
リソースが限られているプロプライエタリだとこうするしかないから、これがド定番で、
むしろGitの対応に怒りすら感じてるし、
まともに機能してるチームで働いたことのある奴は同様だろうよ。
相手の時間をすさまじく雑に扱ってて、しかも当人達はそれを自覚出来てない。
まともな奴ほど、次からはもう送らない、という選択になる。俺もそう。
(と、ふと思ったが、そもそも俺が既に5番目とか7番目の気がしてきた…orz)
それが彼等の技術的問題か、人格的問題かは分からないけど、
壁に穴が空いてることを気にせず、ゴキブリホイホイを多数設置して済ませようとしてる。
これだと、今回のではバグは収まらず、「同種のバグレポート」が、多分あと10通位必要だ。
そりゃ確かにあと10通来てその都度対応すれば全経路にゴキブリホイホイを設置出来るかもしれない。
だけどこれは、俺と同様の通報者だけで30-60時間消費、さらに対応する連中も数時間ずつ、
まあ単純に3時間として、5人なら3時間*5人*10回＝150時間消費するから、合計180-210時間消費することになる。
なら、最初のパッチを作る奴が10時間ほどかけて精査し、
「う～ん、これは壁の大規模補修が必要で、あと30時間ほどかかりますのでお待ち下さい」でも40時間の消費で、
140-170時間の黒字になるんだよ。だから本来はこれを目指さないといけない。
これが「バザール」で出来る事かどうかは俺には分からないけれども、
リソースが限られているプロプライエタリだとこうするしかないから、これがド定番で、
むしろGitの対応に怒りすら感じてるし、
まともに機能してるチームで働いたことのある奴は同様だろうよ。
相手の時間をすさまじく雑に扱ってて、しかも当人達はそれを自覚出来てない。
まともな奴ほど、次からはもう送らない、という選択になる。俺もそう。
(と、ふと思ったが、そもそも俺が既に5番目とか7番目の気がしてきた…orz)
56デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss)
2022/11/09(水) 06:36:12.11ID:raFZ+G/S0 だからさ、Gitの連中がデタラメやってるのも、
共同開発()してる君達が、俺が何を問題視してるかを全く理解出来ないのも、
チームで働く意味を理解出来てないからなんだよ。
それは機能してるチームで活動した経験がないから。
共同開発()は、Gitを使えば、或いは人数がいれば、達成出来ることではない。もっと上のレイヤーの戦略だ。
(俺が上記で指摘した点なんて、完全にアナログだし)
それは君達がGitで「管理」出来ると勘違いしてたのと同様、レイヤーを間違ってる。
Gitは「適用」「記録」ツールであって、管理ツールではない。
(記録＝台帳管理だから、それが管理だ！のレベルで君達は止まってる)
道具は所詮道具であって、○○使ってれば大丈夫！なんて事にはならないし、
世間はそのレベルで戦ってないんだよ。もっと上位の戦略で優劣を競ってる。
で、この辺でいいかな？
余計なお世話だったかもしれないが、
俺は君達やGit陣営の問題点を分かりやすく示すことにより、俺なりの返礼にしたつもりだ。
(ただGit陣営はこういう諫言を無視してきたから今がああなのだとは断言出来る。
同じ事を思った奴が世界でこれまで誰もいなかったなんてあり得ないから。
だから書くだけ無駄だったかもだが、まあ、受け取る受け取らないは君らの自由だ）
もう借りを返したつもりなので、今後は君達に問題点を見つけても無視する。
出来てるつもりの共同開発()ごっこを引き続き楽しむ自由も、君達にはある。
共同開発()してる君達が、俺が何を問題視してるかを全く理解出来ないのも、
チームで働く意味を理解出来てないからなんだよ。
それは機能してるチームで活動した経験がないから。
共同開発()は、Gitを使えば、或いは人数がいれば、達成出来ることではない。もっと上のレイヤーの戦略だ。
(俺が上記で指摘した点なんて、完全にアナログだし)
それは君達がGitで「管理」出来ると勘違いしてたのと同様、レイヤーを間違ってる。
Gitは「適用」「記録」ツールであって、管理ツールではない。
(記録＝台帳管理だから、それが管理だ！のレベルで君達は止まってる)
道具は所詮道具であって、○○使ってれば大丈夫！なんて事にはならないし、
世間はそのレベルで戦ってないんだよ。もっと上位の戦略で優劣を競ってる。
で、この辺でいいかな？
余計なお世話だったかもしれないが、
俺は君達やGit陣営の問題点を分かりやすく示すことにより、俺なりの返礼にしたつもりだ。
(ただGit陣営はこういう諫言を無視してきたから今がああなのだとは断言出来る。
同じ事を思った奴が世界でこれまで誰もいなかったなんてあり得ないから。
だから書くだけ無駄だったかもだが、まあ、受け取る受け取らないは君らの自由だ）
もう借りを返したつもりなので、今後は君達に問題点を見つけても無視する。
出来てるつもりの共同開発()ごっこを引き続き楽しむ自由も、君達にはある。
57デフォルトの名無しさん (ｱｳｱｳｸｰ MM39-Tlaq)
2022/11/09(水) 06:40:41.84ID:ocNu9S1hM こんな人がPLだったら話長い人だなあと思って敬遠するわ。PMには向いて無さそうな人に思う
58デフォルトの名無しさん (ﾜｯﾁｮｲ 515f-pSqO)
2022/11/09(水) 06:41:02.07ID:lvNzmAyI0 https://producingoss.com/ja/setting-tone.html#avoid-private-discussions
> 公開されている場所で議論することによるさまざまな損失があなたの頭の中に浮かぶことでしょう。...
> 本当は何もわかっていないのに 「自分はすべてわかっている」と勘違いしているボランティアへの
> 対応 (どんなプロジェクトでもこの手の人がいます。彼らのうち何人かは将来すばらしい貢献をしてくれる
> ことになるでしょうが、 中にはずっと勘違いしたままの人だっています)、ある問題 X が
> より大きい問題 Y の一部であるときに、 なぜ問題 Y ではなく問題 X だけを解決したいのかを
> 理解してくれない人たち、 などなど。...
> 公開されている場所で議論することによるさまざまな損失があなたの頭の中に浮かぶことでしょう。...
> 本当は何もわかっていないのに 「自分はすべてわかっている」と勘違いしているボランティアへの
> 対応 (どんなプロジェクトでもこの手の人がいます。彼らのうち何人かは将来すばらしい貢献をしてくれる
> ことになるでしょうが、 中にはずっと勘違いしたままの人だっています)、ある問題 X が
> より大きい問題 Y の一部であるときに、 なぜ問題 Y ではなく問題 X だけを解決したいのかを
> 理解してくれない人たち、 などなど。...
59デフォルトの名無しさん (ﾜｯﾁｮｲ 515f-nsye)
2022/11/09(水) 09:01:13.54ID:xm6SvStZ0 長文君にはゴミ箱がお似合い
ごみ箱でバージョン管理する手法が提案される
https://srad.jp/submission/54492/
Windowsのゴミ箱を「作業フォルダ」として使っている人は意外といるらしい→驚愕の声続々
https://togetter.com/li/892609
ごみ箱でバージョン管理する手法が提案される
https://srad.jp/submission/54492/
Windowsのゴミ箱を「作業フォルダ」として使っている人は意外といるらしい→驚愕の声続々
https://togetter.com/li/892609
60デフォルトの名無しさん (ｱｳｱｳｳｰ Sacd-oA9A)
2022/11/09(水) 09:32:33.75ID:KYaOBnwRa https://twitpic.com/dtqxgo
画像貼れるかわからないけど、なかなかいい提案
画像貼れるかわからないけど、なかなかいい提案
61デフォルトの名無しさん (ｵｯﾍﾟｹ Sr79-sZZ3)
2022/11/09(水) 09:50:39.39ID:fSnT1d04r 長文くんは空想と現実の区別がついてなさそう
レポートも本当に送ってるんだか
レポートも本当に送ってるんだか
62デフォルトの名無しさん (ﾜｯﾁｮｲ 5e8f-gUJl)
2022/11/09(水) 12:19:42.34ID:iczqgiJF0 日々の作業のバックアップだけしたいならそもそもVCS使う必要ないしな
63デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss)
2022/11/10(木) 00:01:03.02ID:lrWcMZ4k0 >>58
その切り取り方はだいぶ酷い。続き読んだら正反対の結論だし。
ちなみに本編のその部分の内容には同意。リンク先は俺にはまあまあ面白い。ありがとう。
切り取り方に悪意がないとして、それが君の意見なら、
回答は、上位戦略、
「動いているコードはいじるな」「動いているコードであっても、改善出来るのならどんどん改善しろ」(11)
による。前者の場合はXの修正に留め、後者の場合はYを修正する。
ただこれはソフトウェア界では既に結論が出てて、「後者(Y)じゃないと無理」だ。(よって疎結合化は必須)
だから『今は』余程の事がない限り後者で、
その本が前者なのは、上梓が2005.10で、おそらく2003頃の常識で書かれてるから。
その頃は前者が主流だったのは11に書いたとおり。
そしてGitももしかして？なのは18に書いた通り。修正が『今の常識からすると』普通ではないから。
その切り取り方はだいぶ酷い。続き読んだら正反対の結論だし。
ちなみに本編のその部分の内容には同意。リンク先は俺にはまあまあ面白い。ありがとう。
切り取り方に悪意がないとして、それが君の意見なら、
回答は、上位戦略、
「動いているコードはいじるな」「動いているコードであっても、改善出来るのならどんどん改善しろ」(11)
による。前者の場合はXの修正に留め、後者の場合はYを修正する。
ただこれはソフトウェア界では既に結論が出てて、「後者(Y)じゃないと無理」だ。(よって疎結合化は必須)
だから『今は』余程の事がない限り後者で、
その本が前者なのは、上梓が2005.10で、おそらく2003頃の常識で書かれてるから。
その頃は前者が主流だったのは11に書いたとおり。
そしてGitももしかして？なのは18に書いた通り。修正が『今の常識からすると』普通ではないから。
64デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss)
2022/11/10(木) 00:01:23.56ID:7zTsALdP0 ただ、Gitの場合はおそらく技術的問題だと思う。
Xの修正に留めるのは、変に壊さない為だが、Git陣営は今壊れているところすらも「きちんと」直そうとしてない。
だから、そこで言われてるXでもないんだ。
ちなみに、「正しいXの修正」が45における「バルサン」だ。
壁の補修が必要なのは分かるが、それは今とても出来ないから(或いは賃貸等でそもそも出来ないから)、
せめて今出来る最善手で、ということ。
Gitは今打てる最善手すら打とうとしてない。
(コードの修正範囲を絞られたとしても、もっとましな解決方法がある)
だから多分技術的にも足りてなくて、それは本人達の慢心だよ。
傲慢でつけあがってるから、他人がどういう解決をしているか調べたこと無いんだよ。
Cの基本的手法を見たこと無いはずがないし、よくよく考えれば、見た目違うだけで、
C++も、C#も、Rustも、本質的には同じ解決方法を採ってる。
だから、C以外の言語であっても「きちんと掘り下げて」勉強してたら、こうはならないんだよ。
多分連中は、Cを書けるだけで満足してて、しかもCの基本的(=伝統的)手法を馬鹿にしてる。だからこんな事になってる。
(スクリプト系も全く使えないから仕様もおかしな事になってるし)
だから不勉強の根っこは人格的問題で、結果、技術不足が発生してる。
というところまで見えてしまうから、まともな奴は近づかないよ。
俺もこりゃ駄目だ、大体こんな奴等に構ってられる状況でもないし、って感じ。
そもそもLinusがいるんだから任せときゃ問題ない。
Xの修正に留めるのは、変に壊さない為だが、Git陣営は今壊れているところすらも「きちんと」直そうとしてない。
だから、そこで言われてるXでもないんだ。
ちなみに、「正しいXの修正」が45における「バルサン」だ。
壁の補修が必要なのは分かるが、それは今とても出来ないから(或いは賃貸等でそもそも出来ないから)、
せめて今出来る最善手で、ということ。
Gitは今打てる最善手すら打とうとしてない。
(コードの修正範囲を絞られたとしても、もっとましな解決方法がある)
だから多分技術的にも足りてなくて、それは本人達の慢心だよ。
傲慢でつけあがってるから、他人がどういう解決をしているか調べたこと無いんだよ。
Cの基本的手法を見たこと無いはずがないし、よくよく考えれば、見た目違うだけで、
C++も、C#も、Rustも、本質的には同じ解決方法を採ってる。
だから、C以外の言語であっても「きちんと掘り下げて」勉強してたら、こうはならないんだよ。
多分連中は、Cを書けるだけで満足してて、しかもCの基本的(=伝統的)手法を馬鹿にしてる。だからこんな事になってる。
(スクリプト系も全く使えないから仕様もおかしな事になってるし)
だから不勉強の根っこは人格的問題で、結果、技術不足が発生してる。
というところまで見えてしまうから、まともな奴は近づかないよ。
俺もこりゃ駄目だ、大体こんな奴等に構ってられる状況でもないし、って感じ。
そもそもLinusがいるんだから任せときゃ問題ない。
65デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss)
2022/11/10(木) 00:01:54.15ID:7zTsALdP0 ちなリンク先
> "綺麗で、読みやすくバグのないコードを書きましょう。" といったことをガイドラインに書いても意味がありません。
> もちろん、これらは望ましいことではありますが、 これらが望ましくないと思われる世界は存在しないので、言及する価値がないのです。
> https://producingoss.com/ja/written-rules.html
なおGitとこのスレ
> "綺麗で、読みやすくバグのないコードを書きましょう。" といったことをガイドラインに書いても意味がありません。
> もちろん、これらは望ましいことではありますが、 これらが望ましくないと思われる世界は存在しないので、言及する価値がないのです。
> https://producingoss.com/ja/written-rules.html
なおGitとこのスレ
66デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss)
2022/11/10(木) 00:02:35.94ID:7zTsALdP0 >>59,60
それを揶揄するのがお前らの傲慢なところだ。(60は賛同かもだが)
それは、「ユーザーが実際に求めてる機能はその程度で十分」ということなんだよ。
まさに、例のブランコ状態。Gitなんて超超超超オーバースペックだ。
たださすがに「ゴミ箱」は怖いから、
「バケツ」アプリで、GUIは完全にゴミ箱と同じ、ただし消せないし消えない、で一般には十分なんだよ。
従来VCSが提供したもの： 管理者に都合がいいだけの、すさまじく使いにくいVCS
Gitが提供したもの： 超超超超オーバースペックで、確かに何でも出来るが、すさまじく分かりにくいVCS
ユーザーが本当に欲しかったもの： 消えないゴミ箱
それを揶揄するのがお前らの傲慢なところだ。(60は賛同かもだが)
それは、「ユーザーが実際に求めてる機能はその程度で十分」ということなんだよ。
まさに、例のブランコ状態。Gitなんて超超超超オーバースペックだ。
たださすがに「ゴミ箱」は怖いから、
「バケツ」アプリで、GUIは完全にゴミ箱と同じ、ただし消せないし消えない、で一般には十分なんだよ。
従来VCSが提供したもの： 管理者に都合がいいだけの、すさまじく使いにくいVCS
Gitが提供したもの： 超超超超オーバースペックで、確かに何でも出来るが、すさまじく分かりにくいVCS
ユーザーが本当に欲しかったもの： 消えないゴミ箱
■ このスレッドは過去ログ倉庫に格納されています
