[過去ログ] Git 19 (1002レス)
上下前次1-新
このスレッドは過去ログ倉庫に格納されています。
次スレ検索 歴削→次スレ 栞削→次スレ 過去ログメニュー
273: (ワッチョイ b57b-3eqv) 2022/11/16(水)07:24 ID:4to+8mNM0(1/6) AAS
>>251
Gitのコンセプトはなかなかチャレンジングだぞ。
全世界で唯一の履歴、完全平行作業(各自が任意のファイルを自由に同時に編集)ってのは、上手く行けば確かに面白い。
思考に階層がまるでない君らには通じないと思うが、
ソフトウェアは本来、実装階層ではなくて、コンセプト階層で勝負すべきなんだよ。
274: (ワッチョイ b57b-3eqv) 2022/11/16(水)07:27 ID:4to+8mNM0(2/6) AAS
>>253
(俺が言うとろくな展開にならなそうだが)
rebaseは清書用だからな。コードを実際に書く人向けではない。
mergeだけでも問題なく行ける。というかrebase自体がほぼmergeだし。
ここはGitのコンセプトがずれてて、
> リベースかマージか
> 外部リンク:www.git-scm.comリベースかマージか
二者択一ではなく、共存が正しいのだが、機能的に欠けてるからおかしな事になってる。
共存させる為には経路情報が必要で、俺はそれが当然保存されてると思ってて探したのに無い!で始まったのが前スレ814-
この辺、Gitに欠けてる機能を補完するとしたら第二弾以降になる。まあ全く予定無しだが。
rebaseを常用するのは、少なくとも従来スタイル(>>127)だとマネジメントが機能してない証拠でしかなく不味い。
Gitが開発の手法を変えた!とか言われてるのはこの辺ぶち壊して、
従来型の(やってる感だけの)マネジメントなんて要りません!としたからだろうけど、
(まあ実際の所ろくにマネジメント出来てないし、
仮に問題が分かったとしても後からでは余計に邪魔でしかないので手当も出来ず、
なら最初から何もやりません!ってのも分からなくもないが)
Gitの場合はついでにアナログ的努力、具体的には176内
・regressionテスト
・レビュー
・コーディングルール
もイラネ!って全部捨ててるのはさずがに駄目だと思うが、これで回ってきてるのも事実だからな。
まあこれはさておき、多分rebaseの馬鹿らしさを実感出来る状況にあること自体がマトモであり、幸せなんだろうよ。
そしてそれは知らない人には通じない。これもよくある状況だよ。
ドタバタしか知らない連中は、ドタバタするものだと思っちゃってる、ってこと。朝の支度と同じ。
Gitは力業(ちからわざ:パワープレイ)が出来るだけに、全部力業に持ち込んでて、力業に頼らない方策を無視してる。
これも勝つ為の戦略だ!はありだけど、例えばサッカーで力業しか無かったら色々言われるでしょ。
275: (ワッチョイ b57b-3eqv) 2022/11/16(水)07:27 ID:4to+8mNM0(3/6) AAS
>>262
あ~ cherry pick ってそういう意味か。意味不明な機能だなとしか思ってなかったわ。
ただそれって多分、三角マージの指定方法を洗練すればmergeに統合出来た話で、
別機能にするのは仕様の練り方が全然足りない気がするが。(まあその気すらないようだが)
276(1): (ワッチョイ 4b14-H0Ic) 2022/11/16(水)07:29 ID:iIuOsXs40(1/3) AAS
> ただそれって多分、三角マージの指定方法を洗練すればmergeに統合出来た話で、
できねーよ
頭悪いのか
277(1): (ワッチョイ 4b14-H0Ic) 2022/11/16(水)07:31 ID:iIuOsXs40(2/3) AAS
>>276
> rebaseを常用するのは、少なくとも従来スタイル(>>127)だとマネジメントが機能してない証拠でしかなく不味い。
rebaseを管理の機能だと思ってるから
アホなんだよなぁw
278: (ワッチョイ 4b14-H0Ic) 2022/11/16(水)07:33 ID:iIuOsXs40(3/3) AAS
> rebaseは清書用だからな。コードを実際に書く人向けではない。
これも理解してないやつのセリフ
適切なタイミングでコミットするから
rebaseが必要なんだが
ああ、コミットをpushと勘違いしてそうだなこいつw
279(1): (ワッチョイ 1d4e-Uv+W) 2022/11/16(水)08:09 ID:lN1QdtbS0(1/3) AAS
facebook(meta)がgit対抗ソフト出した!
外部リンク:engineering.fb.com
> 歴史的に、バージョン管理システムの使いやすさには多くの要望が残されてきました。開発者は、リポジトリの複雑なイメージを維持することが期待されており、一見単純な目標を達成するために難解なコマンドを使用することを余儀なくされることがよくあります。Saplingでそれを修正することを目指しました。
長文ガイジの言い分は正しかった!!
280(1): (ワッチョイ 1d4e-Uv+W) 2022/11/16(水)08:16 ID:lN1QdtbS0(2/3) AAS
> 多くのソース管理システムでは、コミットのスタックを操作することは特に困難です。スタックの早い段階でコミットに 1 行を追加するには、git rebase -iのような複雑なステートフル コマンドが必要です。Sapling は、最新のエンジニアでもスタック内のコミットを編集、再配置、および理解できるようにするための明示的なコマンドとワークフローを提供することで、これを簡単にします。
>
> 最も基本的なことは、スタック内のコミットを編集する場合、そのコミットをsl goto COMMITでチェックアウトし、変更を加えてsl amendで修正するだけです。Sapling は、スタックの一番上を新しく修正されたコミットに自動的に移動またはリベースするため、競合をすぐに解決できます。競合を今すぐ修正しないことを選択した場合は、そのコミットの作業を続行し、後でsl restackを実行してスタックを再び元に戻すことができます。Mercurial の Evolve 拡張機能に着想を得た Sapling は、内部で各コミットのミューテーション履歴を追跡し、スタックを何度編集しても、後でアルゴリズムによってスタックを再構築できるようにします。
Sugeeeeee!!!
281: (ワッチョイ 4b8f-+RSR) 2022/11/16(水)11:37 ID:4GOK4Qmg0(1) AAS
>>277
rebase自体がほぼmergeと言ってる時点でもうね…
OOPの話にしてもそうだけど、彼は点でしか物事捉えられないんだろうね
282(1): (アウアウウー Saa9-9aJV) 2022/11/16(水)12:11 ID:KM49zAuba(1/2) AAS
>>280
AI とか使って何とかするのか?
283(1): (アウアウウー Saa9-9aJV) 2022/11/16(水)12:19 ID:KM49zAuba(2/2) AAS
基本的なコマンドは一緒にしてあるんだね
Git Cheat Sheet
外部リンク:sapling-scm.com
284: (テテンテンテン MM4b-b9+P) 2022/11/16(水)12:50 ID:adH18wyIM(1) AAS
どうせ新しく作るならAndroidやiOSをサポートしてほしかった
285: (ワッチョイ adc2-owoj) 2022/11/16(水)13:04 ID:LmJ8L4ow0(1/3) AAS
Sapling is a new Git-compatible source control client.
だからgitリポジトリを操作するラッパーっていう感じか
286(1): (ワッチョイ 4bbb-tcgO) 2022/11/16(水)13:07 ID:cpWhvvM10(3/4) AAS
>>282
コンフリクトが出てもその場で直さずに放置して後で直せばいい、という阿呆な仕様でステートレスにしてるだけなので気にするな。
287: (アウアウウー Saa9-9aJV) 2022/11/16(水)13:21 ID:Y1TjeBe0a(1) AAS
>>286
凄くよく理解できました。
ありがとう。
Mercurial 使えはいいのかも。
288: (ワッチョイ 4bbb-tcgO) 2022/11/16(水)13:35 ID:cpWhvvM10(4/4) AAS
sl は
git のサブコマンドは(一見では)実態を表してないように見える
git rebase は万能過ぎて、最初に覚えるのがつらいので複数のコマンドに分割
って問題意識でコマンドを整理したんだろうな。histedit とかの命名に苦笑
どのみち一緒に使うことになるので最終的には手間が増えるだけな気がするけど
# うちでは sl ってやると蒸気機関車が走るよ
289: (ワッチョイ d55f-3TKi) 2022/11/16(水)15:13 ID:NssUpRQd0(1) AAS
🚂🚂🚂
290: (アウアウウー Saa9-9aJV) 2022/11/16(水)15:21 ID:sEsoti0qa(1) AAS
外部リンク:github.com
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
コーディングを開始する前にじっくりと設計した方が良い
このやり方では大きなものは作れない
上下前次1-新書関写板覧索設栞歴
あと 700 レスあります
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ
ぬこの手 ぬこTOP 0.014s