Git 19

[過去ﾛｸﾞ] Git 19 (1002ﾚｽ)
上下前次 1-新
通常表示 512ﾊﾞｲﾄ分割ﾚｽ栞

このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索歴削→次ｽﾚ栞削→次ｽﾚ過去ﾛｸﾞﾒﾆｭｰ

274: デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv) [sage] 2022/11/16(水) 07:27:07.12 ID:4to+8mNM0

>>253
(俺が言うとろくな展開にならなそうだが)
rebaseは清書用だからな。コードを実際に書く人向けではない。
mergeだけでも問題なく行ける。というかrebase自体がほぼmergeだし。
ここはGitのコンセプトがずれてて、
> リベースかマージか
> https://www.git-scm.com/book/ja/v2/Git-%E3%81%AE%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E6%A9%9F%E8%83%BD-%E3%83%AA%E3%83%99%E3%83%BC%E3%82%B9#_リベースかマージか
二者択一ではなく、共存が正しいのだが、機能的に欠けてるからおかしな事になってる。
共存させる為には経路情報が必要で、俺はそれが当然保存されてると思ってて探したのに無い！で始まったのが前スレ814-
この辺、Gitに欠けてる機能を補完するとしたら第二弾以降になる。まあ全く予定無しだが。

rebaseを常用するのは、少なくとも従来スタイル(>>127)だとマネジメントが機能してない証拠でしかなく不味い。
Gitが開発の手法を変えた！とか言われてるのはこの辺ぶち壊して、
従来型の(やってる感だけの)マネジメントなんて要りません！としたからだろうけど、
(まあ実際の所ろくにマネジメント出来てないし、
仮に問題が分かったとしても後からでは余計に邪魔でしかないので手当も出来ず、
なら最初から何もやりません！ってのも分からなくもないが)
Gitの場合はついでにアナログ的努力、具体的には176内
・regressionテスト
・レビュー
・コーディングルール
もイラネ！って全部捨ててるのはさずがに駄目だと思うが、これで回ってきてるのも事実だからな。

まあこれはさておき、多分rebaseの馬鹿らしさを実感出来る状況にあること自体がマトモであり、幸せなんだろうよ。
そしてそれは知らない人には通じない。これもよくある状況だよ。
ドタバタしか知らない連中は、ドタバタするものだと思っちゃってる、ってこと。朝の支度と同じ。
Gitは力業(ちからわざ：パワープレイ)が出来るだけに、全部力業に持ち込んでて、力業に頼らない方策を無視してる。
これも勝つ為の戦略だ！はありだけど、例えばサッカーで力業しか無かったら色々言われるでしょ。

http://mevius.5ch.net/test/read.cgi/tech/1667720427/274

299: デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv) [sage] 2022/11/16(水) 23:51:27.30 ID:4to+8mNM0

>>279
> What will stand out, though, is how every command is designed for simplicity and ease of use.
> There is no staging area.
> Fixing mistakes with ease
うむ。アプリに対する哲学は俺と同じだ。
ただまあ、同様につらつら考えてたが、どうも根本の戦略が違うと感じる。

従来： 手戻りを最小化する
Git： 手戻りの手間を極限まで減らせば、手戻りがあっても問題ない

ここで言う「手戻り」は、最狭義の
> やっぱやめた (271,272)
から、
・regressionテストを省いたことで、一部機能を壊したことに気づけなかったことによる、再修正
・レビューをしなかったことにより、不十分な修正であることを見逃してしまった事による、再追加修正
・CodingRuleを規定しなかったことにより、潜在的にバグを発生させやすいコードが存在し、結果的にバグが発生したことによる、修正
・OOPの基本を遵守しなかったことによる、ハッシュ交換程度での、大手間
・そもそも基本アーキがゴミな事による、実装では回避しようのない、大手間(Gitはこれは問題ない)
みたいな、広義～広範囲の物も含めてだ。

ただこれをきっちり成功させる為には、リーダーポジションにそれなりに優秀な奴が必要なのと、
そいつにだけどうしても過重な負担がかかってしまうのが問題だ。
これは、相手の力量を見極めて仕事を配分していくので、手駒がない場合には自分でやらざるを得ない、というより、
無理に振ったところでどうせ後で全部やり直しになるところまで確定的に見えてしまうので、自分でやることを選択してしまうからだ。
例の「ブラック会社に勤めてるんだが、もう俺は限界かもしれない」の藤田がそれで、完全に過労死コースになる。
(俺はWebで無料公開してた漫画の所までしか知らないが、藤田の彼女がそうなってたような)

http://mevius.5ch.net/test/read.cgi/tech/1667720427/299

320: デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv) [sage] 2022/11/18(金) 06:51:03.16 ID:AxmdzuHg0

>>302
お前らではな。それがGit以前の「最低限」だったし、その状況でGNU/Linuxは完全に動作してた。
ただまあ、Gitが何でどういう連中に崇拝されてるのかは理解出来たよ。
最終目的の「長期的メンテナンス」を、「コードの品質」でやるか「スーパークレクレ君」でやるかの違いだ。
ん～、やはり全く納得できんが、まあ見物だ。
しかし「スーパークレクレ君」にしても、最低限の選別眼は必要だと思うがなあ。Git開発陣にはこれもない。

昔から「仕事は段取り8割」と言われていて、プログラミングにもこれは当てはまるが、
「それなりの経験を積まないと、何が起こるかまるで想定出来ないので、段取りしようにも出来ない」という本質的な問題があって、
Gitはここを破壊したのだろう。だから本質的に初心者ホイホイで、初心者こそGitの恩恵にあやかれる。
道路工事やビル建設とは違い、情報だけを相手にするプログラミングだから、成立するのかもしれん。
Git開発陣見てると「段取り？何それ美味しいの？」だからね。
対して従来型は結局のところ「段取り」良くやろうとしてるだけだ。
ただGit開発陣以外はGitをツールとして段取り良くする為に使ってるし、俺はそいつらの方が正しいと思うけど。
それから、

従来： 「将来の手間の最小化」を目指し、今手間をかけて疎結合化する。(これにはリソースが限られているという大前提がある)
Git： 「リソースは無限大」なのだから、今の手間を最小化し、とにかく人を集めれば、いつか誰かが良いコードを書いてくれる。

とまあ、これも正反対だ。
結局のところ、従来型における「自分達でやらねばならない」という、
当たり前すぎて前提条件とも言われない、プロジェクトに於ける潜在意識みたいな物を、
Gitはぶち壊し、「いつか誰かがやってくれるんだから良いじゃん」とまあ、
(見てないけど)ゆたぽんに対する嫌悪感と同質の物を俺は感じる。あれもネットがなければまるで成立しないのが同じ。
良く言えばネット社会に適応したとも言えるわけだが、なんだかねー。

http://mevius.5ch.net/test/read.cgi/tech/1667720427/320

331: デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv) [sage] 2022/11/18(金) 19:43:38.39 ID:AxmdzuHg0

>>324
俺もそう思うがそこはモノレポの限界なんだろ。

全てをありのままに記録するとbranchが煩雑すぎて余計意味分からんから、
いっそのこと熊手形状(ある点までは幹は一本でその先は一斉に分岐)に強制した上で、適用順に幹に追加、ということだろ。
幹は縞々模様になるが、一本鎖にはなるし、拡大すれば子細も得られ、縮小すればあらすじが得られる。
まあ初手としては悪くない選択だと思うよ。これまでのログを見慣れてる奴にも馴染みやすい。

そしてこの場合、rebaseをユーザーから隠蔽出来るから、(というか多分これが目的)
実際はありのまま全部記録してたが(M)、表示では一本鎖にしてました(V)、なんて事もツール内側だけで出来る。
だからsapling方式でユーザーは全く問題ないと分かったら、次手としてMVC分離で今君が言ってる事(＝俺が欲しい機能)もやれる。
ここら辺の作戦は、実用主義で良いと思うよ。ツールは、
・「今出来てない」ことが出来ないのは、大して問題にはならないが、
・「今出来てる」ことが出来なくなるのは、大問題だから
ユーザーからrebaseを本当に取り上げて良いかをまず様子見して、というわけだ。
(この点、ダイレクトにこの次手を目指すべき、と思う連中には物足りないだろうが、
作ってる連中が自分達のモノレポ用にチューニングしてるのだから、まあ仕方ない。
ただGitにはMVC臭がまるでなく、おかしな仕様になってる部分をmetaが修正してくれることには期待だ。
rebaseはViewでやるべきで、Modelでやるのは不味いし、基本にも反する。
ここら辺の判断が付かないのだから、Git開発陣はMVCを知らないのだと思うんだよね。つかあいつら色々不勉強すぎ)

ただ、根本的な問題は、今のGitは一次元(時間軸)方向に成長する「一つの」ものをトラッキングする用に出来てて、
モノレポみたいに「多数の」物をブチ込んだ場合に対応出来ないことだ。
モノレポの場合は成長方向が多数だから、例えば中央から外側各方向に成長するものであって、
記録としては年輪やレーダーチャートみたいな見え方にならないと駄目だが、少なくとも今のGitはそうなってない。ただの線だ。
(それはポリレポでやれ、なのだろうけど、適度に癒着してるからモノレポの方がいいという判断なのだろうし)

http://mevius.5ch.net/test/read.cgi/tech/1667720427/331

上下前次 1-新書関写板覧索設栞歴

あと 645 ﾚｽあります
ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ AAｻﾑﾈｲﾙ

ぬこの手ぬこTOP 1.997s*