[過去ﾛｸﾞ] Git 19 (1002ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
61: (ｵｯﾍﾟｹ Sr79-sZZ3) 2022/11/09(水)09:50:39.39 ID:fSnT1d04r(1) AAS
長文くんは空想と現実の区別がついてなさそう
レポートも本当に送ってるんだか
84: (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/11(金)06:52:27.39 ID:k022U7g40(3/6) AAS
具体的に言うなら、「学習コスト高すぎ」問題だ。
見る限り50-100時間程度か？少なくともチームの一員として
「リポジトリを破壊せず、普段のコード提出は問題なくでき、チームに『Git用員』が不要」なレベルに到達するまでに。
ただこれは本当に酷い話で、「ゴミ箱」アプリなら完全に把握するまでに5分だろ。なら、50-100時間丸々開発に使える。
あと今回俺が言ってるクソソース問題、
実はCの場合は言語機能がほぼ無いので、ソリューションはどれも馬鹿げているほど単純で、
見れば分かるものしかない。(他言語では文法でサポートされてるので各々2-3時間の勉強が必須)
そしてあまりに馬鹿げてるから「イケてない」扱いされ、傲慢な若者には無視され、結果、メモリリークしてるわけだ。
これは「何故みんなこうするのか」をレクチャーすれば済む話で、
技術的には10分あれば十分なんだよ。(パッチ送ってくるレベルの奴には)
ただ、絶対人の話を聞かない連中だから、Linusがやるしかないけど、
これを省いてGitに学習時間50-100時間かけてクソコードを量産してるんだから、完全に本末転倒だろ。
ここで同種のバグを一掃しないと余計に時間がかかる、という感覚がないのもどうかしてるし。
gitが難しくて、結果的に「『頑張って』勉強するんだ！」みたいな奴が集まってるのはいいのかもしれんが、
頑張る方向を完全に間違ってる。
「ゴキブリホイホイの無限設置だ！」と頑張られても、そりゃ違う、と思うだろ。
(頑張る連中なんだから、正しい方向に導けば上手く流れるだけなのに、そうしないのは上部の怠慢だよ。つまりLinusだな。
頑張らない連中のケツを蹴飛ばして何とかするのとはだいぶ訳が違う)
100: (ﾜｯﾁｮｲ b57b-3eqv) 2022/11/12(土)06:46:43.39 ID:h41UD2lS0(3/29) AAS
ちな、CodeOfConduct読んで、あいつら中の人か！ってのが分かったので俺的査定。
Avar Arnfjord Bjarmason: 今なんとか方向修正を試みてるように見える。上手く導ければ有能だが、果たして？
Christian Couder: 出てきてないので不明
Junio C Hamano: 休暇中？らしい (40)
Taylor Blau: 無能。ってか閻魔大王が全スルーするならいないのと同じ。ちゃんと門番やれ。
そういえばGitのコーディングルールはどこにあるのだ？
今回ほどの糞コードは、コーディングルールで引っかけて落とせるはずだが。
107: (ﾜｯﾁｮｲ 2514-H0Ic) 2022/11/12(土)09:37:06.39 ID:Cj/ueztB0(3/9) AAS
>>103
> というわけでGitBucketは基本この方針でmasterに全ての履歴を数珠繋ぎ、
ああ、GitとGitHubの区別もついてなさそうだね
181: (ﾜｯﾁｮｲ b57b-3eqv) 2022/11/13(日)07:49:57.39 ID:Eh77ZCvU0(3/15) AAS
>>179,180
(内容が違うが答えは同じで)
いやあれはそういう意味ではない。どう読むかも自由ではあるが。
ただやっぱり、ここら辺はフォークで決着すべきで、それが正しいんだよ。
各自が思う方向に、突っ走ってみればいい。
アプリの品質も、最終的にはユーザー数*満足度の総和だから、Gitのやり方が間違ってる訳でもないんだろうさ。
でも俺は違うと思うから、違う方向を試す。
281: (ﾜｯﾁｮｲ 4b8f-+RSR) 2022/11/16(水)11:37:37.39 ID:4GOK4Qmg0(1) AAS
>>277
rebase自体がほぼmergeと言ってる時点でもうね…
OOPの話にしてもそうだけど、彼は点でしか物事捉えられないんだろうね
331: (ﾜｯﾁｮｲ b57b-3eqv) 2022/11/18(金)19:43:38.39 ID:AxmdzuHg0(4/5) AAS
>>324
俺もそう思うがそこはモノレポの限界なんだろ。
全てをありのままに記録するとbranchが煩雑すぎて余計意味分からんから、
いっそのこと熊手形状(ある点までは幹は一本でその先は一斉に分岐)に強制した上で、適用順に幹に追加、ということだろ。
幹は縞々模様になるが、一本鎖にはなるし、拡大すれば子細も得られ、縮小すればあらすじが得られる。
まあ初手としては悪くない選択だと思うよ。これまでのログを見慣れてる奴にも馴染みやすい。
そしてこの場合、rebaseをユーザーから隠蔽出来るから、(というか多分これが目的)
実際はありのまま全部記録してたが(M)、表示では一本鎖にしてました(V)、なんて事もツール内側だけで出来る。
だからsapling方式でユーザーは全く問題ないと分かったら、次手としてMVC分離で今君が言ってる事(＝俺が欲しい機能)もやれる。
ここら辺の作戦は、実用主義で良いと思うよ。ツールは、
・「今出来てない」ことが出来ないのは、大して問題にはならないが、
・「今出来てる」ことが出来なくなるのは、大問題だから
ユーザーからrebaseを本当に取り上げて良いかをまず様子見して、というわけだ。
(この点、ダイレクトにこの次手を目指すべき、と思う連中には物足りないだろうが、
作ってる連中が自分達のモノレポ用にチューニングしてるのだから、まあ仕方ない。
ただGitにはMVC臭がまるでなく、おかしな仕様になってる部分をmetaが修正してくれることには期待だ。
rebaseはViewでやるべきで、Modelでやるのは不味いし、基本にも反する。
ここら辺の判断が付かないのだから、Git開発陣はMVCを知らないのだと思うんだよね。つかあいつら色々不勉強すぎ)
ただ、根本的な問題は、今のGitは一次元(時間軸)方向に成長する「一つの」ものをトラッキングする用に出来てて、
モノレポみたいに「多数の」物をブチ込んだ場合に対応出来ないことだ。
モノレポの場合は成長方向が多数だから、例えば中央から外側各方向に成長するものであって、
記録としては年輪やレーダーチャートみたいな見え方にならないと駄目だが、少なくとも今のGitはそうなってない。ただの線だ。
(それはポリレポでやれ、なのだろうけど、適度に癒着してるからモノレポの方がいいという判断なのだろうし)
332(1): (ﾜｯﾁｮｲ b57b-3eqv) 2022/11/18(金)19:44:10.39 ID:AxmdzuHg0(5/5) AAS
>>329
それは紙媒体前提の、20年前の思考だよ。
実際Gitはそうだけど。
333: (ﾜｯﾁｮｲ 4bbb-tcgO) 2022/11/18(金)20:19:37.39 ID:jciRgkpH0(6/6) AAS
>>332
「紙媒体」ではなく「分散・非同期」でやる手続きな。git と科学研究の共通点。
「集中」とか「完全同期」とかの管理型が好みなら別の手順になる。
365: (ﾍﾞｰｲﾓ MM4f-Zm9Y) 2022/12/16(金)16:40:26.39 ID:2IJsKIMuM(1) AAS
おもしろかったので
Gitは最初1244行しかなかった
外部ﾘﾝｸ:zenn.dev
464: (ﾜｯﾁｮｲ 4602-DqiY) 2023/03/29(水)07:00:07.39 ID:TKZGCNiw0(1) AAS
>>453 だが、結局Busybox版MinGitにした
サイズ小さいし、VSCodeやEclipseのGit拡張機能からでも使えるし、十分だわ
475(1): (ﾜｯﾁｮｲ 2ecf-uluY) 2023/03/30(木)21:17:24.39 ID:jlqIRhmm0(1) AAS
そういうもんだけどその複数人たる他の人達はそのことについてあなたになんて言ってるのさ
705(1): (ﾜｯﾁｮｲ f784-aKLB) 2023/07/02(日)23:10:04.39 ID:r080W1xk0(1) AAS
チームの状況に合わせて臨機応変に運用を決めればいい
956: (ﾜｯﾁｮｲ aebb-+cpK) 2024/01/01(月)17:16:07.39 ID:rut3bssP0(1) AAS
git は常にPCの前に座っているプログラマ向けで、抽出も整形も必要ならいくらでも自分で専用のスクリプト組むし、git を部品に使って試行錯誤で自分環境DIYするようなトップ層向けツールなので仕方ない。
スマフォで綺麗に整形された変更履歴みたいとか、インストール一発で使える環境欲しいとか言い出すようなカジュアル層には向いていない。
おばちゃんの買い物にはF1カーもラリーカーも必要ないのと一緒。
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.035s