22/11/06 10:57:26.83 FBkt/oHG0.net
長々と無駄な長文と大量投稿でスレを穢すんじゃねー。
単に既存のバージョン管理ツールと、git の考え方の違いが理解できてないだけじゃねーか。
・git はパッチ管理ツール、作業履歴管理ツールじゃない。
・ソフトウェアはパッチとパッチを当てる順番で構成されている。
1000回唱えろ。この思想が気に要らなければそもそも git 使うな。
995:デフォルトの名無しさん
22/11/06 10:59:15.02 OfQ8ymDc0.net
>>943
と思ったが、ffじゃないとhashが違うからウザいな。別物扱いだから、一々確認いるし。
オブジェクトツリーはffの方がいい。
ただこれだとcommit履歴が無く、俺的にはまずいので、別に保存したい。
ソースと混ざるとウザイので、可能なら分離したい。
ドキュメントによるとマルチルートも出来るらしいが、これはどうやってやるんだ？
> Each project must have at least one root. A project can also have multiple roots, though that isn’t common (or necessarily a good idea).
996:デフォルトの名無しさん
22/11/06 1
997:1:04:28.51 ID:OfQ8ymDc0.net
998:デフォルトの名無しさん
22/11/06 11:33:11.11 sj15aRfA0.net
ということにしたいのですね。
999:デフォルトの名無しさん
22/11/06 11:46:16.67 FBkt/oHG0.net
>>949
お前の狭い世間なんて知るか
お前は話題の電動ドリル買ってきて釘打つのに不便ガンガンってやりながら文句言ってるのと同じレベル
そもそもマニュアルもちゃんと読めてないだろ。root と route を間違える英語レベル
背伸びして git 学ぶ前に高校に進学して英語学んだ方が近道だぞ
1000:デフォルトの名無しさん
22/11/06 11:51:22.62 OfQ8ymDc0.net
>>950
いや事実だよ。
Linusは確かにmergeしかしないんだろうけど。
だけどその、mergeするパッチを書く奴は、それを一発で書けたわけがないんだ。
何日もかけて、何回も直して、そこに到達してる。
この過程のサポートがGitにはない。
別branchで作業してもmerge時にhash値が組み込まれるから、
確かに俺がやろうとしてる「日々の進捗」をcommitされると除去出来ずウザイんだろうさ。
しかしパッチのコードは必ずGit-repoをクローンしてから出発するのだから、
Gitにこのサポートが無く、パッチを当てる人はいきなり完成したパッチを書け！勿論でバッグ済みだぞ！みたいな構造なのがおかしい。
すくなくとも、捨てbranch機能があって、そこで日々の作業を終わらせた結果、
mergeするときには本ブランチでその結果がいきなり生えたように見せる機能
(捨てbranchとmergeしても中身の結果だけもらって親にはしない）
みたいな機能が必要なんだよ。
ただまあ、これは今でも手動だと出来た気はするが。
だからまあ、確かにパッチ管理ツールであって、
ソフトウェア開発時のバージョン管理ツールではないんだろうさ。
だけど、今、全世界のGitで、mergeコミットと通常のcommit、どっちが多いか考えれば、自明だろ。
一つのパッチを作るまでにも何回もcommitが必要なのだから。
1001:デフォルトの名無しさん
22/11/06 12:07:06.70 FBkt/oHG0.net
>>952
アホか。共同開発が全く理解できてねーじゃねーか。
お前の試行錯誤の記録を push しようとしてんじゃねーよ。
手元で試行錯誤して実装できたら、それを元に綺麗なパッチに書き直す作業するんだよ。
そして完成した綺麗なパッチ群のみを共有リポジトリに公開するんだよ。
1002:デフォルトの名無しさん
22/11/06 12:19:51.48 OfQ8ymDc0.net
>>948
一応見つけた。 git worktree らしい。
複数のbranchを同時に開く機能で、DBで言うATTACHっぽい。
1003:デフォルトの名無しさん
22/11/06 12:20:57.36 JyiC8cnE0.net
試行錯誤はすべて記録に残すべき
→じゃあテキストエディタで保存するたびに記録するべきっていうのか？
こういう話なので無視すんなよ？ｗ
1004:デフォルトの名無しさん
22/11/06 12:21:44.03 JyiC8cnE0.net
バージョン管理はソースコードの変更履歴を残すのであって
作業履歴を残すものじゃないっていうのが分かってなさすぎ
1005:デフォルトの名無しさん
22/11/06 12:30:26.14 OfQ8ymDc0.net
>>953
それはいいんだけどさ、その肝心のパッチを書く人へのサポートがまるでないだろ。
出発点がgit clone で、その上で作業して、終われば pull request する前提なのにさ。
そしてOSSではなく一般企業等で使ってる奴は、
当たり前だが日々の作業のバックアップや巻き戻し出来るシステムが必要で、そう使ってる。
だから、Gitが難しすぎるというのは、目的外使用だから意味が分かりにくい、というのはあるね。
Indexもマージの時には�
1006:った方が便利なんだろうしさ。(ただのcommitには邪魔でしかない） しかし確かに、Linusに言わせれば、全く問題ないんだろうさ。彼はmergeしかしないしね。 そして他のVCSよりまし、という理由でGitを使う奴は、混乱するんだろうさ。VCSと聞いてきたのだからね。 確かにパッチ管理システムだよGitは。ソースコード生成時のサポートシステムではない。
1007:デフォルトの名無しさん
22/11/06 12:32:16.81 OfQ8ymDc0.net
>>955
> こういう話なので無視すんなよ？ｗ
無視する/しない以前に、何が言いたいのか分からないから反応しようがないんだよ。
1008:デフォルトの名無しさん
22/11/06 12:42:58.45 sj15aRfA0.net
>>957
> それはいいんだけどさ、その肝心のパッチを書く人へのサポートがまるでないだろ。
rebase あるよ。
元のローカルブランチを消さないでおけば記録もぜんぶ残るし。よかったね。
1009:デフォルトの名無しさん
22/11/06 12:43:13.14 FBkt/oHG0.net
>>957
git ほどパッチを書くのに向いてるツールは他にないぞ。
index 無しでどうやってパッチの分割とかするんだよ？
1010:デフォルトの名無しさん
22/11/06 12:53:16.71 OfQ8ymDc0.net
>>960
最初から一つずつ書けば分割の必要ないし、
Index無くてもdiffの出力を絞ってpatchに食わせれば普通に分割出来るだろ。
1011:デフォルトの名無しさん
22/11/06 13:02:38.08 JyiC8cnE0.net
>>958
書いてあるとおりじゃん。
試行錯誤の履歴を全部取れというなら、テキストエディタで保存するごとに
gitでコミットしなければならないはずだ
お前の主張はそういうことなんだから、それをちゃんとやれってこと
1012:デフォルトの名無しさん
22/11/06 13:04:02.78 JyiC8cnE0.net
>>961
コミットがメチャクチャなのに、どうやってdiffとってパッチできると思ってるの？
そのdiffには関係がない修正が大量に入ってるだろ
1013:デフォルトの名無しさん
22/11/06 13:37:22.28 FBkt/oHG0.net
>>961
なんも分かってないことを露呈しているな。
A,B,C,D,Eとコミットした後に Cはc1,c2,c3に分割すべきで、BとEは一つにすべきで、Aは不要だったと気づいたらどうすんの？
こういうのがお手軽にできて綺麗なパッチ群に整理できるのがパッチ管理ツールである git の利点なんだ。
そういうのやったことないだろ？
1014:デフォルトの名無しさん
22/11/06 13:39:49.06 az1H5JFk0.net
>>954
脊髄反射で理解したつもりになって書いてるだろ正解率が著しく低い
git worktreeは一つのリポジトリに追加のワークツリーを用意して、異なるブランチをそれぞれ別のワークツリーにcheckoutできるようにする機能
DBのATTACHとは全然違う
マルチルートは普通に作ったリポジトリをfetchやpushで合成してmerge --allow-unrelated-historiesすればできる
でもこれはかなり特殊な用途に使うもので普段使いするようなものではない
1015:デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss)
22/11/06 13:46:46.96 OfQ8ymDc0.net
>>965
実は今し方ドキュメント読んで、これは違うと書こうとしたところだった。
wor,ktreeはstashの代わりで、同時作業用ではないね。
> マルチルートは普通に作ったリポジトリをfetchやpushで合成して
ああこれは俺の要求とは違うね。
まあ、もう地味に.git/.xxx/に転がそうと思案中。
1016:デフォルトの名無しさん
22/11/06 13:57:15.91 OfQ8ymDc0.net
>>963,964
お前らunixコマンドの使い方知らないだろ。
patch/merge/diff3はgit以前からあるコマンドで、多分初期Gitはそのまま使ってたと思うが。
具体的な使い方は以下。
今、元 fileA に対して、変更後 fileC になってるが、実は中間の fileB が欲しかったとする。このとき、
cp fileA fileB
diff fileA fileC | less -N; // ここで該当行を確認する。例えば10-20行目なら、
diff fileA fileC | sed -n '10,20 p' | patch fileB
これでfileBが得られるんだよ。これ以上色々複雑な時用に diff3 とか merge もある。
だからパッチの分割はすぐ出来るんだよ。
1017:デフォルトの名無しさん
22/11/06 14:05:27.55 az1H5JFk0.net
>>967
そういう作業を必要で
1018:無くすためにgitが生まれた patchの提出をgitの分散リポジトリ上で可能とするためにね 963とか964が行ってるpatchというのは、いわゆるpatchファイルのことではなく、ブランチ上に存在する差分の事 そのpatchを整理するのに index や rebase がある
1019:デフォルトの名無しさん
22/11/06 14:19:49.14 FBkt/oHG0.net
もしかして、もしかすると、git では「パッチ＝コミット」っていうことすら理解できてないのだろうか。
まさかそんな人はいないよね。単に言動が変な人なだけだよね。
1020:デフォルトの名無しさん
22/11/06 14:25:32.34 OfQ8ymDc0.net
>>968
知ってるよ。
ただまあ、確かにパッチ管理ツールだ。
プログラマはこれをソースコード管理ツールとして使おうとするから問題なのだろう。
バックアップが取れて、履歴が戻れれば何でもいいんだが、mergeも出来るから便利だからね。
なお俺は
> ブランチ上に存在する差分の事
も所詮はdiffだ、という立場だよ。だから元のunixコマンドで何とでもなるし、
それをシェルスクリプトで集大成したのが初期Gitだろ。
1021:デフォルトの名無しさん
22/11/06 14:31:58.60 FBkt/oHG0.net
>>970
ちがうぞ。最初からパッチ管理ツールとして設計されるぞ。
そしてパッチ管理ツールなんだから、パッチの出力機能さえあれば良いんだぞ。
それ以外の差分が欲しかったら別の外部ツール使えば良いんだぞ。それこそ基本だろ
1022:デフォルトの名無しさん
22/11/06 14:33:28.64 OfQ8ymDc0.net
>>969
各commmit「点」でdiff取ったときに落ちる情報って何？
ああcommitメッセージか？そんなのは知らんし要らんよ、って立場。
つか、commitメッセージガーなんて言い訳にならないから、
どのみちソースコードを確認するしかないんだよ。
commitメッセージはその手がかりとラベルに過ぎない。これが俺、というか多分普通のプログラマの立場。
お前らはcommitメッセージが間違ってたら、そいつに責任を負わせられるんだろうさ。
ソースコード読めないからね。
ソースコード読める奴ならこんな言い訳効かないんだよ、何でお前が上にいるんだ！監督する為だろ！になる。
さすがに素通しはヤバい。
そしてどう見てもヤバいパッチを素通ししてるから、なんじゃあこりゃあ？ってなってる。
1023:デフォルトの名無しさん
22/11/06 14:36:33.55 OfQ8ymDc0.net
>>971
ああそれが diff のデフォルト出力をさせない理由だな。
651から一周回ったが、なるほど色々状況は理解出来たよ。賛同はしないが。
1024:デフォルトの名無しさん
22/11/06 14:45:12.77 FBkt/oHG0.net
>>972
だからお前の考えてるような作業履歴管理ツールじゃないんだから、あきらめて他所へ行け。
gitはパッチ管理ツール。そしてパッチは何時、誰が、何のために作成したかが重要情報なんだよ。それを管理してるんだよ。
ソースコードの保管するツールじゃねーぞ。
1025:デフォルトの名無しさん
22/11/06 14:49:22.34 OfQ8ymDc0.net
>>974
そこは違うんだな。
みんな結局自分でやるのも作るのも面倒だから、既に動いてるツールを使ってるだけだよ。
Gitの機能のサブセットで十分にカバー出来るのなら、Git使えばいいだけ。
1026:デフォルトの名無しさん
22/11/06 14:56:19.71 OfQ8ymDc0.net
>>974
だからな、前言ったように、ブッ込んでおけば後で取り出せるバケツでしかないんだよ。
そのバケツにゴテゴテ付いてるから難しそうだが、要らない機能は使わなければいいだけ。
ただ、履歴保持の範囲を知らずに使って、実は記録されていませんでは困るから、使う前に調べてる。
1027:デフォルトの名無しさん
22/11/06 15:45:34.08 o7v4FvnP0.net
URLﾘﾝｸ(www.praha-inc.com)
そもそもコミットメッセージは何のためにあるのでしょうか？
コミットログのうちコードの変更履歴には「コードをどのように変更したか」という情報が含まれていますが、「コードを何故変更したのか」という情報はコミットメッセージを読まないと分かりません。機能追加、バグ修正、パフォーマンスのためなど、変更した理由は様々なものが考えられます。
もちろんコードを変更した本人に聞けば変更した意図はわかると思いますが、変更した本人にいつ�
1028:ﾅも聞ける状況であるとは限りません。 「何故コードを変更したのか」という情報が欲しい時のためにコミットメッセージが存在します。 加えて、コミットメッセージは基本的に他人が読むものです。 他人というと同僚やコントリビューターなどが挙げられると思いますが、この「他人」には未来の自分も含んでいます。自分が書いたコミットメッセージを数ヶ月先の自分が読む場合、過去の自分のコミットメッセージを未来の自分が読むことになります。 つまり、コミットメッセージは自分以外の人のために存在するのです。
1029:デフォルトの名無しさん
22/11/06 15:52:02.65 az1H5JFk0.net
まあこいつは分散バージョン管理の難しさを理解できていない
一人でしかプログラム組んだことがないのだろう
gitのややこしいと感じる仕様のほとんどは分散リポジトリ管理に起因していて、分散リポジトリ管理の問題をできるだけ明示的にシンプルに解決しようという意図で設計されている
1030:デフォルトの名無しさん
22/11/06 15:55:03.47 JyiC8cnE0.net
ほんとなぁ、POSIX原理主義だからユニケージだかUSP研究所だかしらんが
例のあいつも、バージョン管理のツールを、バックアップツールとしてしか考えてねぇ
だからとりあえずファイルを入れておけば差分はdiffで見れるだろとか
訳のわからんことを言い出す
ある時点とある時点の差を見たいんじゃねーんだよ
ある修正にどのような差分があるかを記録＝コミットしたいわけで
その記録なしに差分だけみれても役に立たないっつーの
そこが根本的に違うというか、バージョン管理の役目がわかってない
1031:デフォルトの名無しさん
22/11/06 16:10:07.15 az1H5JFk0.net
「ブッ込んでおけば後で取り出せるバケツ」など言っているが、
必要とされていたのは内容を同期できる複数のバケツで、
なおかつバケツ同士が常にオンラインで通信しているわけではない
そういう問題に取り組んだ結果だ
1032:デフォルトの名無しさん
22/11/06 16:12:28.94 az1H5JFk0.net
そういう魔法のバケツを生み出すために、ただのバケツならできることがgitでは制限されていたりもする
ユーザから見て不自由のない完全な魔法のバケツを生み出そうとしたプロジェクトは複雑すぎてことごとく失敗してきた
1033:デフォルトの名無しさん
22/11/06 16:14:37.71 JyiC8cnE0.net
バケツの中に入っている袋詰めの塩や砂糖を、一つづつ取り出したいのであって
バケツの中に全部入ってるから、遠心分離機でも使って
取り出せばいいだろうじゃないんだよなｗ
1034:デフォルトの名無しさん
22/11/06 16:36:01.68 az1H5JFk0.net
前スレは消費に1年半かかってるのに、このスレは半年ぐらいで終わりだな
次スレ立ててみるけど失敗したらゴメン
1035:デフォルトの名無しさん
22/11/06 16:41:37.94 az1H5JFk0.net
次スレ
Git 19
ｽﾚﾘﾝｸ(tech板)
1036:デフォルトの名無しさん
22/11/06 19:18:45.16 OfQ8ymDc0.net
相変わらずお前ら盛大に勘違いしてるが、とりあえず、
× Gitはパッチ管理ツールである
○ Gitはパッチ適用ツールである
○ Gitはパッチ記録ツールである
としよう。管理は出来てない。何を管理すべきか分かってないから。
commitメッセージなんてただのラベルに過ぎない。
1037:デフォルトの名無しさん
22/11/06 19:19:20.86 OfQ8ymDc0.net
例えば今回俺が送った再現コード、あれはどこに配置されるのだ？
>>977の通り、「何故この変更を行ったのか」の完全情報がそこにある。
まさか捨てたりしないよな？
バグパッチに於いて、重要な物から順に、
1. そのバグを修正するコード
2. そのバグを再現するコード
：
10000, commitメッセージ
だ。どんなに丁寧にcommitメッセージを書いたところで、「それ、あなたの感想ですよね？」でしかない。
肝心なところを書き間違ってるかもしれないし、信用も出来ない。
この点、再現コードは情報が完全で、全ての情報を過不足無く含んでいて、曖昧さもない。
だからcommitメッセージの情報価値なんて再現コードと比べたらゴミ以下で、
再現コードに対してのリンクで十分なんだよ。つまり、
○年○月○日に○○から送られてきた○○のバグ(メモリリーク
1038:)を修正する。 詳細はXXXX で、XXXXのところ、Git流ならSHA1ハッシュで、 その中に再現コードと詳細、今回なら全員のメールの全文を入れておくのがバグ管理だよ。 これで、「何故この変更を行ったのか」の完全情報が保たれる。 そして、再現コードは今後ずっとregressionテストに使う資産にする。 そうすれば、少なくとも過去と同じバグはリリース前に見つかる。
1039:デフォルトの名無しさん
22/11/06 19:20:02.27 OfQ8ymDc0.net
こうなってないだろ。一回パッチ当てて動きました！満足です！じゃないんだよ。
繰り返すが、commitメッセジーをいくら丁寧に書いても意味無い。
再現コードに比べたら本当にゴミ以下。
逆に、再現コードに辿り着けるのなら、後はラベルが正しく付いてれば十分なんだ。
それ以上の情報は、commitメッセージのテキストではなく、
再現コードとバグ報告＝完全情報を見た方がいいから。
で、GitHubはまあこれに近いよ。
そもそもバグ報告自体Webだし、少なくともIssueからバグの完全情報に当たれる。
Gitはどうなの？
今回の俺と同様の、過去のバグ報告の再現コードを生かせてるのか？
ならそういうディレクトリがあって、
bug_patches/XXXXXなハッシュが名前になってるディレクトリに再現コードその他がブチ込まれてて、
出荷前(というのもおかしいが)には全部一通り通せ、となってるはずだけど、
どう見てもそうなってないでしょ。
パッチ当てたから満足です、で終わってる。
こんなのでバグが収束するはずがない。
同じ連中が書いてるのだから、放置したら同レベルのバグを繰り返す。
だから本来は何故こんなバグが発生したのか？からコード構造を見直して、
そもそもそうならないようにするのだけど、そういう学びもないし、(だから基本すら出来てない)
regressionテストのネタにもしないのだから、今後ともバグだらけだよ。
ああ、Gitの達人揃いだから、「記録」は出来てるのだろうよ。だけどそれは「管理」ではない。
ただ、これがバザール流だ！と来るなら、はーそうですかー(棒)だよ。
目も手も数が違うし、俺には何が最適か分からんし。
1040:デフォルトの名無しさん
22/11/06 19:20:37.38 OfQ8ymDc0.net
ちなみにchromeの連中は気持ち悪いほどregressionテストしてるぞ。
本来は、ああするべきなんだろうよ。
regressionテスト自体はタダ(スクリプトで自動実行)だからね。
バグ「管理」というのなら、原因を究明して、少なくとも同じバグが出ないようにしないといけない。
それはcommitメッセージをいくら丁寧に詳細に書いても、達成出来るものではない。
分かりやすく言うとな、「体調管理」と言われれば、少なくとも同じ原因で風邪を引かないようにするだろ。
なら、「バグ管理」なら、最低限レビューしてregressionテストしないと駄目だよ。
それはcommitメッセージ云々では出来ない。だからパッチ「適用」「記録」ツール。
1041:デフォルトの名無しさん
22/11/06 19:24:47.08 VM2X6i580.net
>>985
> commitメッセージなんてただのラベルに過ぎない。
その言葉からお前がわかってないのが明らかなんだけど？
1042:デフォルトの名無しさん
22/11/06 19:26:23.98 VM2X6i580.net
>>988
うん。だからそのchromeはここまで徹底してコミットを管理してる
それを見習え
URLﾘﾝｸ(github.com)
1043:デフォルトの名無しさん
22/11/06 19:27:42.33 VM2X6i580.net
regressionする際にもコミットを管理するのは重要で
コミット単位で戻してテストする
動かないコードをコミットすることはない
お前みたいにテキストエディタで修正するたびにコミットとかしない
1044:デフォルトの名無しさん
22/11/06 19:28:57.43 VM2X6i580.net
なんでchromeのコミットメッセージが
こんなに詳しく書かれているのか、その理由を考えたら？
1045:デフォルトの名無しさん
22/11/06 19:32:31.47 VM2X6i580.net
バージョン管理はソースコードの変更履歴を管理するものなので
そこにバグ管理という別の概念を持ち出すのも頭悪い
バグ管理は別のツールでやれ
1046:デフォルトの名無しさん
22/11/06 19:55:47.23 sj15aRfA0.net
>>986
> 例えば今回俺が送った再現コード、あれはどこに配置されるのだ？
修正コミットのログから URL で辿れるようになるかな。
URLﾘﾝｸ(public-inbox.org)
1047:デフォルトの名無しさん
22/11/06 20:08:52.18 OfQ8ymDc0.net
>>994 それは鯖に置いてるだけだろ。まあそれはそれで十分で、（この意味では最初のMLでも十分) 問題は、 1. .git上、つまりソースコード改変ツリーから簡単に辿れるよう、 commitメッセージにそのリンクは落とされている(落とされる予定）なのか？ そうじゃないと>>977が達成出来ないだろ。 2. そしてregressionテストパターンとして登録され、今後ずっと実行されるのか？ 3. そもそも根本の原因はソースコードの程度が酷いことであり、レビューしろよマジで だよ。 レイヤーの考え方がない奴等ばかりなので通じないかもしれないが、 gitは適用/記録という下層レイヤーであって、バグ/パッチ「管理」は上位レイヤーの戦略だから、 gitで「管理」出来ると思ってるのが間違いなんだよ。記録は出来るが、管理は出来ない。 gitで出来るのは上の1だけだね。 だからcommitメッセージは勿論丁寧に書くべきなんだけど、丁寧に書けばいいわけでもないんだ。 それでバグやパッチが減るわけでもないから。 目的と手段の混同はどの界隈でもあるけど、ここの連中も大概だよ。
1049:デフォルトの名無しさん
22/11/06 20:11:50.13 OfQ8ymDc0.net
>>994
と思ったがすまん、見落とした。
> 修正コミットのログ
つまりこれ、コミットメッセージそのものなのか？
ちょっと確認したいんだが、どこ見ればいいんだ？GitのGitHubから？
1050:デフォルトの名無しさん
22/11/06 20:22:10.42 sj15aRfA0.net
>>996
そう。コミットメッセージを含めてML上でレビュー中。まだ本体リポジトリには入ってない。
挙がってるレビューコメントを受けてそのうち第２弾が投稿されて取り込まれるんじゃないかな。
君もソースコードの質が気になるなら修正を送ってくれていいんだよ。さぁさぁ。
1051:デフォルトの名無しさん
22/11/06 20:38:50.28 OfQ8ymDc0.net
>>997
つまりあれがそのままに近い状態で入るのか？
まあそれは見守るとして、本来はちゃんとラベルを付け替えないとまずい。
俺が送った段階では高い確率で「free忘れによるメモリリーク」と推定出来たが、
断定は出来なかったので、単に「メモリ食いすぎ」としてる。
だから、メモリリークだと「断定」出来た人が概略を書き直さないといけない。
が、まあ、これは多分為されるだろう。見守るよ。
> 君もソースコードの質が気になるなら修正を送ってくれていいんだよ。さぁさぁ。
これは本質的に無理だ。多分俺、というか、いわゆるCコードを拒絶すると思うよ。
間違いなく、連中は自己の能力に自信持ってて、傲慢で、言うこと聞かない連中だ。
世の中のCコードなんて、基本通りやってる物でほぼ全部だから、見たこと無いわけが無い。
それが何故そうなってるか理解出来ない、
つまり、王道を王道と理解出来ない奴等だからデタラメやってるわけで、
言うこと聞く連中ならそうはならない。
通常だと、やらせるだけやらせて、でもどうにももうダメポなときに、
そもそもお前のコードがおかしい、ここをこう直せ、なら簡単にメモリリークは抑えられる、とすると効くのだろうけど、
問題はバザールで、無限にモグラ叩き出来てしまって、実際にそれでやろうとしてることだよ。
マジかー、って、ちょっと驚きだが、まあ観戦だ。
ああちなみに、俺以外の誰でも、まともなC書ける奴なら、ちょっと引くコードだよ。
だからそこら辺の奴等に書かせても、もっとましなコードになるよ。そして俺もその程度だし。
というか単発のコードでそんなに技量の差なんて出ないし。
1052:デフォルトの名無しさん
22/11/06 20:40:54.42 VM2X6i580.net
>>998
お前がちゃんとやれって言われるだけだよ
お前雑なんだよ。無能なのに張り切るな。空回りしてるぞｗ
1053:デフォルトの名無しさん
22/11/06 20:46:49.73 wlljBD17M.net
質問いいすか？
1054:1001
Over 1000 Thread.net
このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 197日 17時間 21分 4秒
1055:過去ログ ★
[過去ログ]
■ このスレッドは過去ログ倉庫に格納されています