[過去ログ] Git 19 (1002レス)
1-

このスレッドは過去ログ倉庫に格納されています。
次スレ検索 歴削→次スレ 栞削→次スレ 過去ログメニュー
291: (ワッチョイ 1d4e-Uv+W) 2022/11/16(水)17:57 ID:lN1QdtbS0(3/3) AAS
でもお前ら正直Linusからの反撃(口撃)楽しみにしてるんだろ?
292: (アウアウウー Saa9-FFna) 2022/11/16(水)18:20 ID:z+sJwdsYa(1) AAS
sl ってやると蒸気機関車

世代がばれるな
293: (ワッチョイ adc2-owoj) 2022/11/16(水)18:25 ID:LmJ8L4ow0(2/3) AAS
今WSLにaptでslインストールしてみたけど蒸気機関車走ったわ
294: (ワッチョイ adc2-owoj) 2022/11/16(水)18:31 ID:LmJ8L4ow0(3/3) AAS
Macでもbrewでインストールできて蒸気機関車走った
295: (ワッチョイ e5e4-wjvv) 2022/11/16(水)18:35 ID:zNTc7QNW0(1/3) AAS
カレントブランチという概念が無くなって代わりにカレントコミットになるのね
カレントコミットはブランチのヘッドである必要が無くて、そのカレントコミットにamendとかcommitができる
amendするとカレントコミットからブランチヘッドまでを自動でリベースしてくれる

確かにひと手間減りそうだけど挙動を理解できてない奴が使うとリベースのコンフリクトが頻発して面倒なことになりそう
コンフリクト解決を後回しにできるみたいだけど溜めるとそれはそれで大変そう
296
(1): (ワッチョイ e5e4-wjvv) 2022/11/16(水)18:35 ID:zNTc7QNW0(2/3) AAS
みんなと共有済みのブランチでこの途中へのamendが出来ないようにしておかないと、amendした修正をマージするのが大変そうだけど、うまくやってくれる仕組みがあるのかな?
297: (ワッチョイ cd10-H0Ic) 2022/11/16(水)18:38 ID:5yQdaCF40(1) AAS
Git の最新アップデートから考える開発手法の潮流
外部リンク:speakerdeck.com
298: (ワッチョイ e5e4-wjvv) 2022/11/16(水)19:07 ID:zNTc7QNW0(3/3) AAS
ワークツリーの状態はカレントコミットが属するブランチの状態に保たれる?として、カレントコミットが複数のブランチに属してるような状態(できるのか?)ではどうなるのかな?
カレントコミットとは別にワークツリーの位置を指定するようなのは >>283 見ても見当たらないが、goto NAME と goto COMMIT でうまいことやってくれるのか
299: (ワッチョイ b57b-3eqv) 2022/11/16(水)23:51 ID:4to+8mNM0(4/6) AAS
>>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で無料公開してた漫画の所までしか知らないが、藤田の彼女がそうなってたような)
300: (ワッチョイ b57b-3eqv) 2022/11/16(水)23:51 ID:4to+8mNM0(5/6) AAS
この構造をぶち壊そうというのだから、Gitは過労死ストッパーとしては素晴らしいのかもしれんが、
俺や従来Cプログラマから見たら、「そんなコードでバグが取りきれる訳ねえだろ馬鹿かよ」でしかない。
その後の手間を考えたら、一度に直した方が楽なのに、それを選択しないのだから一緒にはやってられんよ、というわけ。
この根底には「手戻りを最小化する」という従来型アプローチの肯定がある。

対してGit教的にはこれは禁忌であり、「手戻りのコストが0ならいくら手戻りしても問題ないはずだ!」で、
Gitの場合は基本アーキだけは締めて、後は放置というわけだ。
CodingRuleやレビューはどうしても主観的だから、政治/哲学/信条が入り込む余地があって面倒なことは分かるけども、
完全に客観的なregressionテストまでやらないのは、逆方向の哲学を持ってるように見える。
つまり、従来型へのアンチテーゼだ。
まあ、従来型のアプローチにどこまで意味があったのか、という実験としては面白いだろうよ。
つき合ってられんので俺は降りるが。やり直すのが確定してる工事なんて無駄でしかない。
Gitが目指しているのは結局のところ、「ネットを介した人海戦術」でしかない。
そりゃ学術界からは相当嫌われるよ。
301
(1): (ワッチョイ b57b-3eqv) 2022/11/16(水)23:52 ID:4to+8mNM0(6/6) AAS
そういえば禿曰く、「コーディングを開始する前にじっくりと設計した方が良いプログラムの規模に下限はない」で、
これが従来型での基本だよ。
「やっぱ止めた」ではなく、「やっぱ止めた、になる事は、最初からやらない」が正しいとされる。
ただ当たり前だがこれには仕様聞いたら実装をぱぱっと思いつく程度の技術レベルは必要で、
お前らには全然無理だ。
Gitは馬鹿が闇雲にやってもなんとか前進出来るようにはしたから、そりゃお前らには必要なんだろうよ。
だから従来は「プログラミングの勉強をしてない奴は、ろくにメンテできない」世界だった。
今はお前らが「Gitを勉強してない奴はGitを使うな!」と言ってて、ツールの勉強はしてるらしいが、
全くプログラミングの勉強をしてないから、糞コードを糞コードとも認識出来なくなってる。
これはGit陣営もだ。なんだかねー。
ネット人海戦術を成功させる為には、どんな馬鹿でも有効な人材として使う為のツールは重要だけども、
やっぱ本末転倒だと思うぜ。
本来の目的であるプログラミングの勉強をすべきで、ツールはあくまで補助的なものだろ。
世界一のクレクレ君には、そりゃいつか誰かがいいコードくれるのだろうけどさ。マジでなんだかねー。
302
(1): (ワッチョイ 4b14-H0Ic) 2022/11/17(木)00:57 ID:PPyT+nV+0(1) AAS
コーディングを開始する前にじっくりと設計した方が良い
このやり方では大きなものは作れない
303
(2): (アウアウウー Saa9-9aJV) 2022/11/17(木)00:59 ID:SzkkMxOua(1) AAS
一応貼っておきます。
難解なコマンドって、何言ってるんだろ。

Metaの大規模ソースコード管理システム「Sapling」がオープンソース化
外部リンク:gigazine.net

>「一見すると単純なゴールに到達するためには、難解なコマンドを使わざるを得ない」といった点をSaplingは解決しており、さまざまな面でシンプルに仕上がっているとMetaは述べています。
304
(1): (ワッチョイ a5da-IBSA) 2022/11/17(木)07:02 ID:oFtgoZb10(1) AAS
Git終了のお知らせ

Metaの大規模ソースコード管理システム「Sapling」がオープンソース化 - GIGAZINE
外部リンク:gigazine.net
305: (アウアウウー Saa9-Y/9p) 2022/11/17(木)08:39 ID:t8CddWfYa(1) AAS
>>303
これは楽しみ

でもネーミングがダメだな
一般的な単語をそのまま使うのは検索性が劣るので普及しにくくなる
306: (ワッチョイ 1d4e-Uv+W) 2022/11/17(木)09:11 ID:782WqxX70(1/2) AAS
大抵の環境ではslって打つと汽車走るしなぁ
307: (アウアウウー Saa9-FFna) 2022/11/17(木)09:56 ID:V4QZv0Fqa(1/2) AAS
>>296
Git じゃなくて GitHub の話になるけど GitHub の fork はそこをうまく解決出来る手段だと思うわ
308: (アウアウウー Saa9-FFna) 2022/11/17(木)10:03 ID:V4QZv0Fqa(2/2) AAS
>>301
判ります
309: (ワッチョイ 4bce-IHKV) 2022/11/17(木)14:30 ID:gm2HE+q+0(1) AAS
zuckerにしとけばよかったのに

zucker --clone
310
(1): (ワッチョイ 1d4e-Uv+W) 2022/11/17(木)19:17 ID:782WqxX70(2/2) AAS
Gitオワタwww

Meta、Git互換のソースコード管理クライアント「Sapling」をオープンソース化
外部リンク:codezine.jp
> なお、インタラクティブなsmartlog Web UIも用意されており、「sl web」を実行するだけでWebブラウザが起動され、スマートログ、コミット、修正、チェックアウトなどの表示が可能となる。ほかにも、sl undo、sl redo、sl uncommit、sl unamendといったさまざまな操作を元に戻せるコマンドも用意されている。
311: (ベーイモ MMab-9aJV) 2022/11/17(木)19:53 ID:CXVXUQuWM(1) AAS
meta の人が首切られても twitter の人みたいにならないようにしてるんかな
312: (ワッチョイ cd10-4LeY) [age] 2022/11/17(木)19:55 ID:nV36xVvO0(1) AAS
>>310
お前何回同じリンク貼ってるの?
馬鹿なの?
>>303
>>304
313: (アウアウウー Saa9-Uv+W) 2022/11/17(木)20:29 ID:uFwG0ab0a(1) AAS
gitおじさんイライラで草w
codezineのリンクは初出だがw涙で字が見えないらしいwww
314: (アウアウウー Saa9-9aJV) 2022/11/17(木)20:45 ID:oYIw5RmVa(1) AAS
200m四方までズームで追える仕様が、200cm四方までズームで追える仕様になってないと、置きかわりは無理やで。
315
(2): (ワッチョイ 4bcf-H0Ic) 2022/11/17(木)21:19 ID:ArWNCDPA0(1) AAS
gitを使っている人ならsaplingの方が良いと思ったら乗り換えるだろうが
gitが難しいとか言ってる人に使いこなせるんだろうか
316: (ワッチョイ 4bbb-tcgO) 2022/11/17(木)22:08 ID:EURizIvt0(1) AAS
>>315
どうだろうね?
逆にgitに慣れた人が乗る換える利点は全くなさそうだけど、rebase 使ったことないとかほざいてる人たちは、とっと乗り換えるのが吉かもしれない。
ま、ちゃんとソースとか公開されてから評価なので今の時点で考えても無駄だな。
317: (ワッチョイ adc2-owoj) 2022/11/17(木)23:07 ID:S8efKX2d0(1) AAS
gitよりもできることが制限されるとしたら乗り換えるメリット全くないな
318: (ワッチョイ 4bbb-tcgO) 2022/11/18(金)00:06 ID:jciRgkpH0(1/6) AAS
ステージングがない時点で移行できる人は初心者とかに限られてる気がするんだけど……
319: (ワッチョイ 4b8f-+RSR) 2022/11/18(金)03:05 ID:NJJaJqGX0(1/2) AAS
ごくわずかしかいないhgユーザーなら移行もありなんじゃね
知らんけど
320: (ワッチョイ b57b-3eqv) 2022/11/18(金)06:51 ID:AxmdzuHg0(1/5) AAS
>>302
お前らではな。それがGit以前の「最低限」だったし、その状況でGNU/Linuxは完全に動作してた。
ただまあ、Gitが何でどういう連中に崇拝されてるのかは理解出来たよ。
最終目的の「長期的メンテナンス」を、「コードの品質」でやるか「スーパークレクレ君」でやるかの違いだ。
ん~、やはり全く納得できんが、まあ見物だ。
しかし「スーパークレクレ君」にしても、最低限の選別眼は必要だと思うがなあ。Git開発陣にはこれもない。

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

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

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

ぬこの手 ぬこTOP 0.012s