Git 19

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

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

45: デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2022/11/08(火) 09:24:55.86 ID:0xdMrcDS0

俺「あ、ゴキブリっぽい何か見つけました」
Git「はいゴキブリですね。ゴキブリホイホイを設置しました！」
Git「１箇所では足りないようなので、複数箇所にゴキブリホイホイを設置しました！」
Git「木目調のゴキブリホイホイに変更しました！」

いや違うだろぉぉぉぉぉぉぉ！そうじゃねえだろぉぉぉ！
ゴキブリの侵入経路を確認して塞ぐとか、
冷蔵庫や戸棚どかして一切全部掃除し直してさらにバルサン炊くとかだろぉぉぉぉ！
(言ってないけど)

Git「え？でもゴキブリが出る所全部にゴキブリホイホイを設置すれば、ゴキブリには遭遇しなくなりますよ？
　見た目？そのための木目調のゴキブリホイホイですよ？なんなら好きなキャラ描いて書いて貰ってもいいですよ？
　それでは無限にゴキブリが出る？なら無限にゴキブリホイホイ設置するだけですよ？」

こりゃ駄目だ、話が通じねえ、と思うだろ。
Gitの連中はバグの表面的なところだけを繕ってて、そのバグが発生した根本の原因、
つまり今回は壁がボロボロで穴が空きまくっててゴキブリが侵入してきてるんだけど、そこを見ようともしてないんだ。
というより、壁がボロボロだからゴキブリが侵入して来る、という感覚そのものがない。(因果関係を考えてない)
だから壁を直そうとかいう話に繋がらないんだよ。
そしていくらでもゴキブリホイホイを設置すれば、遭遇しなくなると思ってる。
(そりゃそうかもしれないが、そうじゃねえだろぉぉぉ！と叫びたくもなるだろ)

だから今回のパッチ、明らかに方向性が違うから、
俺だったら、というより従来型のCプログラマなら、見た瞬間rejectするんだよ。
それが分からない連中が、大まじめにゴキブリホイホイ設置して喜んでるんだから、こりゃ関わっちゃいけない、と思うだろ。
しかしこれで回ってる。
Gitにやられた連中は、アニメや映画の悪役ばりに、「く、、っこんな奴に！！！」と思ってるだろうさ。

正しい対応： 壁の塗り直し/補修
まだ許せる対応： バルサン
Gitで行われる対応： ゴキブリホイホイの多数設置

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

53: デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2022/11/09(水) 06:27:44.26 ID: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)
この辺も後日確認する予定。

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

83: デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2022/11/11(金) 06:51:48.71 ID:k022U7g40

あとGitが不味いのは、
・「素人向け」ではないこと。
これはCの様に、切れ味抜群だが、素人が使ったら怪我をする、が外面仕様としてモロに見えているところだ。
GUI版はここら辺対策出来てるのかもしれんが。ただ一般に言われてる
「Gitは難しすぎる。ちょっとした規模の開発になると、リポジトリを破壊する奴が出てきて、
『Git用員』が必要になってしまう。こんな事は他のVCSではなかった」には納得だ。
(正確に言うと、難しいのではなく、仕様が直感的でないのが問題。多機能は本来は問題にならない)
そして君達はまさにこの「Git用員」で、
ユーザーであるプログラマに「管理側に都合がいいGitの使い方」を強いてて、嫌われてるわけだ。
ただこれ、Gitの思想もおかしくて、両者が簡単に共存出来るようにすぐに出来るんだが、(Viewの変更だけで済む)
「管理側」が作ってるから実装したくないのだろうよ。だからこの辺、サクッと実装した物が出てくれば話は変わる。
C++やRustの連中も大概だが、実際問題としてCの糞コードを修正するよりは、最初から書いた方が早い。
これは基本アーキテクチャが素晴らしいからだ。
ただ実態は、幸か不幸か、ソースや開発体制のクソっぷりが基本アーキの良さで誤魔化せてしまってる。
ただこれも、バザールでは仕様なんだろう。なんだかねー。
> 9. 賢いデータ構造と間抜けなコードのほうが、その逆よりずっとまし。

これも例えて言うとな、Gitは「1本目の包丁」向けの仕様ではないんだよ。
今現在、Gitは無視出来ない存在になってて、プログラミング入門者、場合によっては大学でも使い方を教えるだろう。
ただ本来、VCSを学ぶのはまともなコードが書けてからで十分で、本末転倒なんだ。
むしろその程度の初心者ならセーブ禁止で、
毎日毎回「自分の頭の中にあるコード」を写経させた方が上達するだろうよ。学生には嫌われるだろうけど。

Gitは柳刃包丁や中華包丁と同様、「5～6本目の包丁」仕様であって、
三徳包丁のような「1本目の包丁」仕様ではないんだ。
ただ既に言ったが、これはGitが悪いのではなく、Gitを滅ぼせない他アプリが問題だから、
俺が加担するとしたら他アプリ＝「バケツ」製作側だ。
そして君達「Git用員」の需要を世界規模で消滅させ、路頭に迷わせるのが正しい解だね。

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

103: デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv) [sage] 2022/11/12(土) 06:57:39.26 ID:h41UD2lS0

>>97
(わざわざ色々考えてくれたのなら手間かけてすまんが)
正直全く分からんし、俺はstashも糞仕様と思うから使う気ない。
というか、Gitの連中、「仕様は小さくあるべき」という感覚がそもそも無いと思う。
俺だったら、branchなんて、各ディレクトリにそのままマッピングする。
つまり、sample.txtの開発なら、

.git
master/sample.txt
develop/sample.txt
featureXXX/sample.txt
stash/sample.txt

で、実行パスは　xxxx/current/sample.txt としておいて、
ブランチの切換はcd、実行ブランチの切換は ln -s master current でよかった。
stashなんて不要機能そのものだよ。直感的じゃないし、そこまでGit信じ切れないし。

この馬鹿仕様で git add -A で取ってれば各ブランチの同時開発状況含めて完全にcommit履歴が保持出来る。これで十分だ。
Gitによってカレントディレクトリの内容が「上書き」されるのはかなり気持ち悪い。
zip展開するときと同様、バケツからは明示的に取り出さないと上書きされない、が分かりやすくて良いんだよ。
branch切換で全部上書きで入れ替わるのは、頻繁に過去と現在を往復するにはいい仕様だが、普通の人には要らん。

というわけでGitBucketは基本この方針でmasterに全ての履歴を数珠繋ぎ、
平行開発はディレクトリとシンボリックリンクで手動でやれ、
git branch xxxx で切り替えれば勿論切り替わるが、バックアップはその状態で取るのであしからず、
それが嫌なら一々masterに手動で戻せ、(自動戻しは失敗するときがあるので付けない)
だから戻し忘れたら一見ちぐはぐになるが、どのみち何処かに残ってるからなんとか探し出せ、という仕様。
要するにGitBucketはbranchを無視する。
(現在のbranchの記録はしておく。これでbranchを使う人も使わない人も問題ない)

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

109: デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv) [sage] 2022/11/12(土) 10:59:50.02 ID:h41UD2lS0

>>104
> デスクトップに置いて管理されている事になっているファイルをコントロールできるようにして欲しい。
それはやる。というか、今考えている動作モードは2つで、
A. ある階層以下全部の履歴を記録
B. 明示的に指定したファイルまたはディレクトリの履歴を記録
で、Aがgit的、Bがゴミ箱的な使い方になる。
ライトユーザーにはBの方が直感的だろう。
毎日「ゴミ箱ならぬ記録箱」にブッ込んでおけば、万一の時に引っ張り出せるだけ、という使い方だ。
ただし中身がgitなので、当然Aの方が実装しやすい。

当たり前だが同居させないと余分なコードがいるので、無理にでも同居させる。
この解だが、一応

.git
c/users/user/desktop

みたいに、カレントをルートと見立てたファイルツリーとし、
明示的に指定されたらそこ(ディレクトリまたはファイル)を指すシンボリックリンクを作ってgitに取らせるつもり。
(この場合は上記desktopが実際のdesktopを指すシンボリックリンク)
これで不味いかね？普通に読むだけならシンボリックリンクは実体が見えるので、
gitがシンボリックリンクを特に区別しないならこれで全く問題ないはずなんだが。(未調査)
或いは git add c:/users/user/desktop とか、絶対パスで指定した方が上手く行くのだろうか？
しかし見る限り git add で指定するのは通常はカレント下だけなので、
(仕様的には使えたとしても)変なバグを踏みそうなので回避した方が無難ではある。
この仕様で問題なのは、パスが糞長いと記録出来なくなること。
つまり、カレント下に絶対パスを付け加えるので、実体のファイルツリーよりも「常に」カレント分だけパスが長くなり、
パスの文字数の上限(今も260文字らしい)を越えると記録出来なくなる。
> https://learn.microsoft.com/ja-jp/windows/win32/fileio/maximum-file-path-limitation
だからガチもん商用アプリではこの解は使えない。
(仮にルートに置いてもc:\の3文字は長くなるので、ユーザーファイルが合計258-260文字のパスになってるときに記録出来ない)
が、今回は、「そんな糞長いパスにするな」で終わり、諦める。(WARNINGは出す)

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

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

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

ぬこの手ぬこTOP 0.022s