Git 19

1 名前：デフォルトの名無しさん [2022/11/06(日) 16:40:27.51 ID:az1H5JFk0.net] ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。 Git - Fast Version Control System git-scm.com/ ◆関連サイト Pro Git - Table of Contents git-scm.com/book/ja Git入門 www8.atwiki.jp/git_jp/ ◆前スレ Git 17 https://mevius.5ch.net/test/read.cgi/tech/1599016710/ Git 18 mevius.5ch.net/test/read.cgi/tech/1650651945/ VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured 231 名前：デフォルトの名無しさん mailto:sage [2022/11/14(月) 00:22:09.12 ID:aSCqNEw00.net] >>224 完全に、じゃなくて、そりゃグルーは書くんだよ。 (まあオブジェクト内側にブチ込んでしまえば見た目完全にはなるが) ただ、俺がやろうとしてることはVCSが普通に持ってる機能(のはず)だから、 VCS自体は何であれ多少の変更で動作するはずなんだよ。 てかお前らには構造の話は通じないから、ここら辺でいいか？ 大体、ゴミ箱アプリの中身がGitかSVNかなんて、交換可能に決まってるじゃん。 むしろなんでそれが無理だと思うのかが俺には分からん。 232 名前：デフォルトの名無しさん mailto:sage [2022/11/14(月) 00:32:35.55 ID:aSCqNEw00.net] >>222 知らんが、要らん。 これなら手動でディレクトリごとzipしとく、の方がマシだ。 233 名前：デフォルトの名無しさん mailto:sage [2022/11/14(月) 00:50:33.04 ID:i6KxBWUg0.net] >>225 例えばgithubに上げられてるCで書かれてるソフトのうち、「きちんと」書かれていると 思うのをいくつか挙げて、それはgitと比べてどのように「きちんと」しているか説明することは できないということで、「きちんと」したのは長文君の妄想内にしかないと思われてもしかたないな >>226 そう思うのならgitの代わりに「コードが糞ではなく開発グループがキモくない」と思うのを使えばいいだけ 234 名前：デフォルトの名無しさん mailto:sage [2022/11/14(月) 00:52:36.47 ID:huosUPX00.net] >>224 交換可能なはずがないんだよね そもそもSVNとgitでリポジトリの概念が違うんだから あとgitは実行速度を重視した実装になっているけど、彼の言うOOPが取り込まれたら実行速度がどれくらい落ちるか、個人的には非常に興味があるね 235 名前：デフォルトの名無しさん [2022/11/14(月) 01:28:19.71 ID:0VMo1QiO0.net] >>227 またろくに仕様を調べもしないでzipのほうがマシとか言って、傷口を広げるだけですよ 人格攻撃ではないのだが、40代ぐらい、正しいCやOOPは出来るほどの技術力は実際にはあるんだが、 人格に難がありすぎてビッグマウスで信用されずWeb業界でやっと拾ってもらえて、 だがGitが使えずWeb業界でも疎まれていて、鬱憤を晴らしにここにきてるのかな。 Gitを使いこなせないレベルのHTML/CSS屋とかならまあ求められてるものが違うからGitわかんないってのもわかるんだけど、 正しいCとかOOPとか言ってるのにGit使えないというのは、SIerしか考えられない不思議。 236 名前：デフォルトの名無しさん [2022/11/14(月) 01:31:10.94 ID:0VMo1QiO0.net] >>229 まあ単なる経験則になっちゃうしgit-svnの実装の問題だと言われたら コードを読んでない自分は反論できないので書かなかったけど、git-svnでどれだけ皆無理だと悟ったか知らないんだろうね 237 名前：デフォルトの名無しさん [2022/11/14(月) 01:36:05.46 ID:0VMo1QiO0.net] >>226 Gitのコミットはリモートリポジトリだったとしても必ず作業ディレクトリの.gitディレクトリに行われる一方で、Subversionのコミットはリモートリポジトリにする必要があるのに？ どのVCSも同じ機能があると思ったら大間違いだよ。CVSなんかかなり絶望的だと思うぞ(すまんCVSは流石に太古の昔しか使ってないので嘘かも) 238 名前：デフォルトの名無しさん mailto:sage [2022/11/14(月) 04:51:45.99 ID:PeuKV+c+0.net] 「バージョン管理ソフトを利用したゴミ箱アプリの開発」 ただしSubversionを使うときはサーバーが必要です。 ファイルを削除するたびにリモートにファイルを保存したりします。 ってことやろ？ 239 名前：デフォルトの名無しさん mailto:sage [2022/11/14(月) 06:36:03.20 ID:Vk7GKPFC0.net] >>225 長文君、どんどんボロが出るなあ きんちとしたCのコードなんて基準も何もない妄想って認めてるんだね 240 名前：デフォルトの名無しさん mailto:sage [2022/11/14(月) 07:31:46.61 ID:aSCqNEw00.net] >>233 SVN全く調べてない俺が勝手に想像してるのはその形態。 鯖立てなんて出来ません！な連中に対応するつもりだから、鯖立て必須は厳しい。 ただ、どうもこのスレの連中は、本当に全くプログラミング出来ないらしい。 >>101,102読めば、ああなるほどね、と並のプログラマならぱっと分かる。 あまりにもトンチンカンな話が多すぎる。マジでお前ら、死ねとしか思われてないぞそれは。 241 名前：デフォルトの名無しさん mailto:sage [2022/11/14(月) 07:32:21.12 ID:aSCqNEw00.net] ただ、いずれにしてもキモイよ。少なくとも俺には。 俺が想像してた世界： 「はい、バグっぽい何か」「ああバグだね」「直しといたぜ、確認よろしく」「とりあえずこちらでは動いた」 俺が思う本来Gitがあるべき姿： 「そのバグパッチ作ってみました」 「う～ん、君のコードはこの点が問題だから、ここをこう直してくれないかな。そうすれば、もっといいコードになる」 「マジか、このOSSではLinusから直接、技術指導を受けられるのか。なるほど勉強になったぜ」 「次も書くぜ！Linusには悪いが、どんどん教えて貰う！！！」 GitやSubversion： 「はい、バグっぽい何か」 「あらいいプログラマね、お茶してかない？」 「いや俺が欲しいのはバグが無くなったソフトウェアであって、 お茶したいわけでもないし、そもそもお前らと仲良くなりたいわけでもないんだが」（＝「SNSでやれ」) って書いてて思ったが、 SNS未発達時代のOSSはSNSも兼ねてて、こんなものなのかもしれん。 しかし今もそうなのはやはりキモイ。 完全にドライに技術的なら、CodeOfConduct(=ポリコレ宣言)なんてそもそも要らんし。 ただこれは俺が匿名文化に馴染んでるからであって、 一般人には実名SNS的対応の方が受けるのかもしれんし、まあご自由にどうぞ、ではある。 俺にはキモ過ぎて無理だな、ってだけで。 242 名前：デフォルトの名無しさん mailto:sage [2022/11/14(月) 07:48:51.42 ID:UbsjwJD50.net] >>236 これかかんの？ 俺が想像してた世界： 　略 俺が思う本来Gitがあるべき姿： 　略 俺が実際にやってること： 　　わーわーわーわーわーわーわーわーわーわーわーわーわーわーわーわーわーわー 243 名前：デフォルトの名無しさん mailto:sage [2022/11/14(月) 07:55:12.73 ID:aaTBlyIu0.net] >俺はもうお前らのフォローはしないと宣言したでしょ。 わかったから他所でやれよ。有言実行。 244 名前：デフォルトの名無しさん [2022/11/14(月) 10:23:41.00 ID:TzEiJIKc0.net] ごっみばけっつの人はさっさと専用スレ作って移動しろよ いつまでめーわくかけ続けるんだよ 245 名前：デフォルトの名無しさん mailto:sage [2022/11/14(月) 10:26:41.02 ID:a8E3Hx5Cr.net] 長文さんってgit とgithubの区別ついてなさそう 246 名前：デフォルトの名無しさん mailto:sage [2022/11/14(月) 11:29:40.73 ID:i6KxBWUg0.net] >>211 >内部DBを外部ソフトに委ねるのは、最大の目的は、そのソフトのツール群を使えるようにする為。 >最悪ユーザー側で何とでもなるというのは、ユーザーにも安心で、これは重要なんだよ。 >そして外部ソフト自体がバグってても勝手に直してもらえる。 長文君が「糞と思っている」gitをベースにしようとするのは、 コードの品質/アプリの仕様そのものが一番重要で、それさえあれば全てが上手く行く >>177 というのは間違いと思っていて、gitがこうなっているから、ということだな >C. コミュニティに人を集めれば自然と持続性は確保出来る。つまり人数が一番重要。 >これを取り持つのがツール(ツールやcommitメッセージが本体) >B. ドキュメントを整備しまくれば、後はがんばって読めばいいだけ。 >A. コードの品質なんて後から付いてくる。バグも誰かが勝手に直してくれる。 長文君は実際に何かを始めたわけではないけどな >>195 247 名前：デフォルトの名無しさん mailto:sage [2022/11/14(月) 11:40:54.89 ID:i6KxBWUg0.net] >>236 さっさと長文君ソフト(仮)作りを始めて自分の理想のコミュニティを作ればいいのに 検討したことや結果を公表する場所を決めて発表することすらできずに グダグダ言い続けるだけの長文君 248 名前：デフォルトの名無しさん [2022/11/14(月) 12:29:56.96 ID:EWF0SvAna.net] fork して branch した後なら いくらでも rebase して push -f しまくってる 249 名前：デフォルトの名無しさん [2022/11/14(月) 13:09:25.49 ID:EWF0SvAna.net] やっとここまで読んだ GitPail がふさわしい名前だと思う 250 名前：デフォルトの名無しさん mailto:sage [2022/11/14(月) 13:42:15.70 ID:Vk7GKPFC0.net] git って一部でもつけんじゃねー、って思う。 勘違い君に文句言いにこられても困る。 251 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 4b8f-X3QC) mailto:sage [2022/11/14(月) 18:27:40.45 ID:huosUPX00.net] git rebase --ontoを今更ながら知ったが便利だなこれ 今までgit rebase -iした後色々こねくり回してたけど楽になった 252 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 1514-H0Ic) mailto:sage [2022/11/14(月) 18:31:19.43 ID:UbsjwJD50.net] >>246 長文「バックアップしたいだけなのにそんな難しい機能はいらねーよ！」 253 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 4bbb-tcgO) mailto:sage [2022/11/14(月) 18:38:05.91 ID:Vk7GKPFC0.net] >>246 欲しいって思った機能って調べるとだいたいあるよね。 254 名前：デフォルトの名無しさん mailto:sage [2022/11/15(火) 06:02:57.49 ID:DDE9IX5V0.net] OSSがコミュニティ的なら、例の「コミュニティの一生」も当てはまってしまうと思うんだよな。 > https://dic.nicovideo.jp/a/%E3%82%B3%E3%83%9F%E3%83%A5%E3%83%8B%E3%83%86%E3%82%A3%E3%81%AE%E4%B8%80%E7%94%9F 【Gitの一生】 Linusが面白いことをする ↓ 面白いから凡人が集まってくる >>95 ↓ 住み着いた凡人が居場所を守るために主張し始める ↓ Linusが見切りをつけて居なくなる ↓ 残った凡人が面白くないことをする ↓ 面白くないので皆居なくなる >>176に書いたとおり、人数こそ力の源泉で、「人数の維持」が目的になってるように見える。 だけどそれは本来は手段で、「アプリの品質」を上げるのが目的でしょ。 (まあ賛同されるとは思ってないし、完全に平行線だが) そもそもGitって今完全にメンテナンス状態？ つまり、本質的な新規機能要求(バックエンドに追加が必要)は無く、View(フロントエンド)をいじってる状態か？ ならまあ、実際面白くもないだろうよ。勿論メンテナはご苦労さんだが。 ああそういえばSHA256対応だっけ？あれは単なる作業だよ、本来は。チャレンジングではないから、面白くもない。 (つかこれがチャレンジングになっちゃうのはコードが糞だからだ。これも何度も説明したけどさ) 255 名前：デフォルトの名無しさん mailto:sage [2022/11/15(火) 06:03:50.02 ID:DDE9IX5V0.net] >>244 Pailは確かにいい。 ただ問題なのは、バケツは全員通じるが、ペール？？？な連中向け(俺含めて)のソフトだということだ。 256 名前：デフォルトの名無しさん mailto:sage [2022/11/15(火) 10:54:20.75 ID:ITVdMBx/r.net] チャレンジングなことしたことないやつほどそういう言葉使うよねぇ エンジニアに妙な憧れ持ってそう 257 名前：デフォルトの名無しさん mailto:sage [2022/11/15(火) 11:04:07.91 ID:tWQzaYQC0.net] だから「バケツ(仮)」で新スレつくってそっち行け。git って付けなければ誰も文句は言わん。 258 名前：デフォルトの名無しさん mailto:sage [2022/11/15(火) 16:01:59.97 ID:u2Y2Sh ] [ここ壊れてます] 259 名前：/m0.net mailto: rebaseって使う機会無いんだけどなぁ 以前、どこかの職場で履歴は一直線がいいとか意味不明な理由でrebaseさせられていた時があったわｗ force pushするしかないし気味悪いｗ [] [ここ壊れてます] 260 名前：デフォルトの名無しさん mailto:sage [2022/11/15(火) 16:50:03.41 ID:bU8+MPV6a.net] 本探してたら、わかばちゃんの旧版の書評に https://honto.jp/ebook/pd-review_0628444763.html >実は現場では、SourceTreeは重要でありながら、きちんと使える人は意外と少ない。 本来はこの手の専門家であるはずのプログラマーは、コマンドでGitを使うため、SourceTreeには縁がないからである。 知らなかった。 261 名前：デフォルトの名無しさん mailto:sage [2022/11/15(火) 17:32:15.63 ID:5R6vrZIA0.net] >>253 あるパッチの中にtypoしているのが後で見つかった場合どうするの？ そのパッチを他のブランチに適用する時困るでしょ 262 名前：デフォルトの名無しさん mailto:sage [2022/11/15(火) 18:40:15.33 ID:u2Y2Sh/m0.net] >>255 別にまた修正すればいいだけじゃね？ 前のブランチに戻って修正するの？ｗ 263 名前：デフォルトの名無しさん mailto:sage [2022/11/15(火) 19:22:21.43 ID:5R6vrZIA0.net] >>256 ブランチが3つあったら 3回同じ修正しろって言ってるの？ ちょっと問題外すぎ rebaseいらない。だって3回修正すればいい だめだこりゃｗ 264 名前：デフォルトの名無しさん mailto:sage [2022/11/15(火) 19:26:08.61 ID:5R6vrZIA0.net] 多分最新のコードを見ながら必要な部分を 目視でより分けて修正しろって言ってるんだろうな 265 名前：デフォルトの名無しさん mailto:sage [2022/11/15(火) 19:33:40.07 ID:oaKUlL5c0.net] うちは自分の作業中にもメインブランチがどんどん進むからローカルでrebaseしまくりだな 266 名前：デフォルトの名無しさん mailto:sage [2022/11/15(火) 19:44:34.40 ID:5R6vrZIA0.net] >>259 普通そうだよね 定期的にrebaseしてないとマージが面倒になるし 267 名前：デフォルトの名無しさん mailto:sage [2022/11/15(火) 19:55:16.46 ID:aKa6LP36a.net] 長文さん、あぼ～んしたいからコテ入れてくれ 268 名前：デフォルトの名無しさん mailto:sage [2022/11/15(火) 20:22:00.46 ID:tWQzaYQC0.net] rebase 使わないとか git の利点半分くらい捨ててるぞ。 上で言われてるパッチ1個当てるくらいなら cherry-pick で済むけど ブランチを再構成したり、コミットの順番を入れ替えたり、コミットを統合したり、分離したり、コミットメッセージを修正したり、使わない日がないくらいの万能ツール。 269 名前：デフォルトの名無しさん mailto:sage [2022/11/15(火) 20:37:46.10 ID:5r8tW8Xc0.net] >>261 今週のうちには専用スレに引っ越してくれるらしいよ。 >>166 > スレは立てるが、肝心のアプリ名を今考え直してるところだから、来週まで待ってくれ。 まぁまた言うだけでやらない理由を長々と説明（）しはじめそうな気はしてるけど。 270 名前：デフォルトの名無しさん mailto:sage [2022/11/15(火) 22:12:13.74 ID:u2Y2Sh/m0.net] >>257 言っている意味が分からんｗ checkout -bした時点のbranchが間違ってましたって話？ｗ どっちにしてもrebaseなんていらんよｗ 271 名前：デフォルトの名無しさん mailto:sage [2022/11/15(火) 22:19:29.03 ID:26oE0jcj0.net] >>263 後からどうとでもつけられるアプリ名を理由に挙げるくらいだからね 「アプリ名が気にいらないから他のを考える」とか言いそう 272 名前：デフォルトの名無しさん mailto:sage [2022/11/15(火) 23:41:22.91 ID:xjjxhqm80.net] rebaseに関しては 履歴を戻ってでもコミットとその流れを綺麗にしたい派 と 戻るの面倒だし汚くてもいいじゃん派 がいるから話が噛み合わない 273 名前：デフォルトの名無しさん mailto:sage [2022/11/16(水) 00:06:32.65 ID:cpWhvvM10.net] コミットも含めて作品 ゴミを作ってる人には rebase は不要 そもそも git 不要だな 274 名前：デフォルトの名無しさん mailto:sage [2022/11/16(水) 02:10:40.58 ID:cpGIBcGj0.net] >>264 だからコミットが複数に分割されてしまうから rebaseして意味のある単位に整えるんだろうが いちいちパッチ当てるときに、 あれとこれとそれとどれを当ててくださいって 10個ぐらい持ってこられても困るぞ 275 名前：デフォルトの名無しさん mailto:sage [2022/11/16(水) 02:12:08.75 ID:cpGIBcGj0.net] >>266 コミットをパッチと考えて 後で再利用することを考えてる人 vs 後で見返すことなんてない人 の違いだな 結局一人プロジェクトなんよ rebaseを価値を理解してないのは 276 名前：デフォルトの名無しさん mailto:sage [2022/11/16(水) 02:52:08.03 ID:cpWhvvM10.net] 作りながら、やっぱりこのパッチは不要だから外そうとか、このパッチとこのパッチを両方適用して試そうとか、別の人の作業を取り込んで影響を調べようとか、お手軽自由自在にできるのが rebase の真髄 あと昨日の作業でタイポしちゃったとかでも直すのには rebase を使うのが基本 branch と rebase 無しでやれって言われたら気が狂いそう。もう昔には戻れない 277 名前：デフォルトの名無しさん mailto:sage [2022/11/16(水) 04:26:00.99 ID:WlnXLGJV0.net] パッチ適用 ←ここでコミット ↓ やっぱやめた ←ここでコミット ↓ ２つのパッチ適応 ←ここでコミット ↓ 別の人の作業を取り込んでみよう ←ここでコミット ↓ タイポ発見修整 ←ここでコミット 何がいけないの？これでいいじゃん 278 名前：デフォルトの名無しさん mailto:sage [2022/11/16(水) 04:42:56.11 ID:cpGIBcGj0.net] >>271 そんな都合よく行くかよｗ 実際の開発したことないのか？ パッチ適用 ←ここでコミット タイポ発見修整 ←ここでコミット バグ発見修整 ←ここでコミット やっぱやめた ←ここでコミット タイポ発見修整 ←ここでコミット ２つのパッチ適応 ←ここでコミット やっぱやめた ←ここでコミット タイポ発見修整 ←ここでコミット 別の人の作業を取り込んでみよう ←ここでコミット バグ発見修整 ←ここでコミット 3つのパッチ適応 ←ここでコミット バグ発見修整 ←ここでコミット タイポ発見修整 ←ここでコミット タイポ発見修整 ←ここでコミット こんな大量のゴミコミットの中から、必要な部分だけ取り出すとかできるかよ 普段から整頓しておけって、子供の頃に教わらなかったか？ 279 名前：デフォルトの名無しさん mailto:sage [2022/11/16(水) 07:24:52.25 ID:4to+8mNM0.net] >>251 Gitのコンセプトはなかなかチャレンジングだぞ。 全世界で唯一の履歴、完全平行作業(各自が任意のファイルを自由に同時に編集)ってのは、上手く行けば確かに面白い。 思考に階層がまるでない君らには通じないと思うが、 ソフトウェアは本来、実装階層ではなくて、コンセプト階層で勝負すべきなんだよ。 280 名前：デフォルトの名無しさん mailto:sage [2022/11/16(水) 07:27:07.12 ID:4to+8mNM0.net] >>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は力業(ちからわざ：パワープレイ)が出来るだけに、全部力業に持ち込んでて、力業に頼らない方策を無視してる。 これも勝つ為の戦略だ！はありだけど、例えばサッカーで力業しか無かったら色々言われるでしょ。 281 名前：デフォルトの名無しさん mailto:sage [2022/11/16(水) 07:27:38.13 ID:4to+8mNM0.net] >>262 あ～ cherry pick ってそういう意味か。意味不明な機能だなとしか思ってなかったわ。 ただそれって多分、三角マージの指定方法を洗練すればmergeに統合出来た話で、 別機能にするのは仕様の練り方が全然足りない気がするが。(まあその気すらないようだが) 282 名前：デフォルトの名無しさん mailto:sage [2022/11/16(水) 07:29:33.99 ID:iIuOsXs40.net] > ただそれって多分、三角マージの指定方法を洗練すればmergeに統合出来た話で、 できねーよ 頭悪いのか 283 名前：デフォルトの名無しさん mailto:sage [2022/11/16(水) 07:31:39.07 ID:iIuOsXs40.net] >>276 > rebaseを常用するのは、少なくとも従来スタイル(>>127)だとマネジメントが機能してない証拠でしかなく不味い。 rebaseを管理の機能だと思ってるから アホなんだよなぁｗ 284 名前：デフォルトの名無しさん mailto:sage [2022/11/16(水) 07:33:21.02 ID:iIuOsXs40.net] > rebaseは清書用だからな。コードを実際に書く人向けではない。 これも理解してないやつのセリフ 適切なタイミングでコミットするから rebaseが必要なんだが ああ、コミットをpushと勘違いしてそうだなこいつｗ 285 名前：デフォルトの名無しさん [2022/11/16(水) 08:09:55.58 ID:lN1QdtbS0.net] facebook(meta)がgit対抗ソフト出した！ https://engineering.fb.com/2022/11/15/open-source/sapling-source-control-scalable/ > 歴史的に、バージョン管理システムの使いやすさには多くの要望が残されてきました。開発者は、リポジトリの複雑なイメージを維持することが期待されており、一見単純な目標を達成するために難解なコマンドを使用することを余儀なくされることがよくあります。Saplingでそれを修正することを目指しました。 長文ガイジの言い分は正しかった！！ 286 名前：デフォルトの名無しさん [2022/11/16(水) 08:16:53.76 ID:lN1QdtbS0.net] > 多くのソース管理システムでは、コミットのスタックを操作することは特に困難です。スタックの早い段階でコミットに 1 行を追加するには、git rebase -iのような複雑なステートフル コマンドが必要です。Sapling は、最新のエンジニアでもスタック内のコミットを編集、再配置、および理解できるようにするための明示的なコマンドとワークフローを提供することで、これを簡単にします。 > > 最も基本的なことは、スタック内のコミットを編集する場合、そのコミットをsl goto COMMITでチェックアウトし、変更を加えてsl amendで修正するだけです。Sapling は、スタックの一番上を新しく修正されたコミットに自動的に移動またはリベースするため、競合をすぐに解決できます。競合を今すぐ修正しないことを選択した場合は、そのコミットの作業を続行し、後でsl restackを実行してスタックを再び元に戻すことができます。Mercurial の Evolve 拡張機能に着想を得た Sapling は、内部で各コミットのミューテーション履歴を追跡し、スタックを何度編集しても、後でアルゴリズムによってスタックを再構築できるようにします。 Sugeeeeee！！！ 287 名前：デフォルトの名無しさん mailto:sage [2022/11/16(水) 11:37:37.39 ID:4GOK4Qmg0.net] >>277 rebase自体がほぼmergeと言ってる時点でもうね… OOPの話にしてもそうだけど、彼は点でしか物事捉えられないんだろうね 288 名前：デフォルトの名無しさん mailto:sage [2022/11/16(水) 12:11:32.56 ID:KM49zAuba.net] >>280 289 名前：AI とか使って何とかするのか？ [] [ここ壊れてます] 290 名前：デフォルトの名無しさん mailto:sage [2022/11/16(水) 12:19:06.08 ID:KM49zAuba.net] 基本的なコマンドは一緒にしてあるんだね Git Cheat Sheet https://sapling-scm.com/docs/introduction/git-cheat-sheet 291 名前：デフォルトの名無しさん mailto:sage [2022/11/16(水) 12:50:32.85 ID:adH18wyIM.net] どうせ新しく作るならAndroidやiOSをサポートしてほしかった 292 名前：デフォルトの名無しさん mailto:sage [2022/11/16(水) 13:04:46.48 ID:LmJ8L4ow0.net] Sapling is a new Git-compatible source control client. だからgitリポジトリを操作するラッパーっていう感じか 293 名前：デフォルトの名無しさん mailto:sage [2022/11/16(水) 13:07:00.65 ID:cpWhvvM10.net] >>282 コンフリクトが出てもその場で直さずに放置して後で直せばいい、という阿呆な仕様でステートレスにしてるだけなので気にするな。 294 名前：デフォルトの名無しさん mailto:sage [2022/11/16(水) 13:21:48.17 ID:Y1TjeBe0a.net] >>286 凄くよく理解できました。 ありがとう。 Mercurial 使えはいいのかも。 295 名前：デフォルトの名無しさん mailto:sage [2022/11/16(水) 13:35:28.58 ID:cpWhvvM10.net] sl は git のサブコマンドは(一見では)実態を表してないように見える git rebase は万能過ぎて、最初に覚えるのがつらいので複数のコマンドに分割 って問題意識でコマンドを整理したんだろうな。histedit とかの命名に苦笑 どのみち一緒に使うことになるので最終的には手間が増えるだけな気がするけど ＃ うちでは sl ってやると蒸気機関車が走るよ 296 名前：デフォルトの名無しさん mailto:sage [2022/11/16(水) 15:13:02.96 ID:NssUpRQd0.net] 🚂🚂🚂 297 名前：デフォルトの名無しさん mailto:sage [2022/11/16(水) 15:21:07.43 ID:sEsoti0qa.net] https://github.com/mtoyoda/sl 298 名前：デフォルトの名無しさん [2022/11/16(水) 17:57:06.17 ID:lN1QdtbS0.net] でもお前ら正直Linusからの反撃（口撃）楽しみにしてるんだろ？ 299 名前：デフォルトの名無しさん [2022/11/16(水) 18:20:17.34 ID:z+sJwdsYa.net] sl ってやると蒸気機関車 世代がばれるな 300 名前：デフォルトの名無しさん mailto:sage [2022/11/16(水) 18:25:58.19 ID:LmJ8L4ow0.net] 今WSLにaptでslインストールしてみたけど蒸気機関車走ったわ 301 名前：デフォルトの名無しさん mailto:sage [2022/11/16(水) 18:31:10.60 ID:LmJ8L4ow0.net] Macでもbrewでインストールできて蒸気機関車走った 302 名前：デフォルトの名無しさん mailto:sage [2022/11/16(水) 18:35:05.10 ID:zNTc7QNW0.net] カレントブランチという概念が無くなって代わりにカレントコミットになるのね カレントコミットはブランチのヘッドである必要が無くて、そのカレントコミットにamendとかcommitができる amendするとカレントコミットからブランチヘッドまでを自動でリベースしてくれる 確かにひと手間減りそうだけど挙動を理解できてない奴が使うとリベースのコンフリクトが頻発して面倒なことになりそう コンフリクト解決を後回しにできるみたいだけど溜めるとそれはそれで大変そう 303 名前：デフォルトの名無しさん mailto:sage [2022/11/16(水) 18:35:26.56 ID:zNTc7QNW0.net] みんなと共有済みのブランチでこの途中へのamendが出来ないようにしておかないと、amendした修正をマージするのが大変そうだけど、うまくやってくれる仕組みがあるのかな？ 304 名前：デフォルトの名無しさん mailto:sage [2022/11/16(水) 18:38:18.21 ID:5yQdaCF40.net] Git の最新アップデートから考える開発手法の潮流 https://speakerdeck.com/yuukiyo/trends-in-development-methodology-from-the-latest-git-updates 305 名前：デフォルトの名無しさん mailto:sage [2022/11/16(水) 19:07:56.24 ID:zNTc7QNW0.net] ワークツリーの状態はカレントコミットが属するブランチの状態に保たれる？として、カレントコミットが複数のブランチに属してるような状態(できるのか？)ではどうなるのかな？ カレントコミットとは別にワークツリーの位置を指定するようなのは >>283 見ても見当たらないが、goto NAME と goto COMMIT でうまいことやってくれるのか 306 名前：デフォルトの名無しさん mailto:sage [2022/11/16(水) 23:51:27.30 ID:4to+8mNM0.net] >>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で無料公開してた漫画の所までしか知らないが、藤田の彼女がそうなってたような) 307 名前：デフォルトの名無しさん mailto:sage [2022/11/16(水) 23:51:46.25 ID:4to+8mNM0.net] この構造をぶち壊そうというのだから、Gitは過労死ストッパーとしては素晴らしいのかもしれんが、 俺や従来Cプログラマから見たら、「そんなコードでバグが取りきれる訳ねえだろ馬鹿かよ」でしかない。 その後の手間を考えたら、一度に直した方が楽なのに、それを選択しないのだから一緒にはやってられんよ、というわけ。 この根底には「手戻りを最小化する」という従来型アプローチの肯定がある。 対してGit教的にはこれは禁忌であり、「手戻りのコストが０ならいくら手戻りしても問題ないはずだ！」で、 Gitの場合は基本アーキだけは締めて、後は放置というわけだ。 CodingRuleやレビューはどうしても主観的だから、政治/哲学/信条が入り込む余地があって面倒なことは分かるけども、 完全に客観的なregressionテストまでやらないのは、逆方向の哲学を持ってるように見える。 つまり、従来型へのアンチテーゼだ。 まあ、従来型のアプローチにどこまで意味があったのか、という実験としては面白いだろうよ。 つき合ってられんので俺は降りるが。やり直すのが確定してる工事なんて無駄でしかない。 Gitが目指しているのは結局のところ、「ネットを介した人海戦術」でしかない。 そりゃ学術界からは相当嫌われるよ。 308 名前：デフォルトの名無しさん mailto:sage [2022/11/16(水) 23:52:15.86 ID:4to+8mNM0.net] そういえば禿曰く、「コーディングを開始する前にじっくりと設計した方が良いプログラムの規模に下限はない」で、 これが従来型での基本だよ。 「やっぱ止めた」ではなく、「やっぱ止めた、になる事は、最初からやらない」が正しいとされる。 ただ当たり前だがこれには仕様聞いたら実装をぱぱっと思いつく程度の技術レベルは必要で、 お前らには全然無理だ。 Gitは馬鹿が闇雲にやってもなんとか前進出来るようにはしたから、そりゃお前らには必要なんだろうよ。 だから従来は「プログラミングの勉強をしてない奴は、ろくにメンテできない」世界だった。 今はお前らが「Gitを勉強してない奴はGitを使うな！」と言ってて、ツールの勉強はしてるらしいが、 全くプログラミングの勉強をしてないから、糞コードを糞コードとも認識出来なくなってる。 これはGit陣営もだ。なんだかねー。 ネット人海戦術を成功させる為には、どんな馬鹿でも有効な人材として使う為のツールは重要だけども、 やっぱ本末転倒だと思うぜ。 本来の目的であるプログラミングの勉強をすべきで、ツールはあくまで補助的なものだろ。 世界一のクレクレ君には、そりゃいつか誰かがいいコードくれるのだろうけどさ。マジでなんだかねー。 309 名前：デフォルトの名無しさん mailto:sage [2022/11/17(木) 00:57:49.25 ID:PPyT+nV+0.net] コーディングを開始する前にじっくりと設計した方が良い このやり方では大きなものは作れない 310 名前：デフォルトの名無しさん mailto:sage [2022/11/17(木) 00:59:42.90 ID:SzkkMxOua.net] 一応貼っておきます。 難解なコマンドって、何言ってるんだろ。 Metaの大規模ソースコード管理システム「Sapling」がオープンソース化 https://gigazine.net/news/20221116-meta-sapling/ >「一見すると単純なゴールに到達するためには、難解なコマンドを使わざるを得ない」といった点をSaplingは解決しており、さまざまな面でシンプルに仕上がっているとMetaは述べています。 311 名前：デフォルトの名無しさん mailto:sage [2022/11/17(木) 07:02:49.14 ID:oFtgoZb10.net] Git終了のお知らせ Metaの大規模ソースコード管理システム「Sapling」がオープンソース化 - GIGAZINE https://gigazine.net/news/20221116-meta-sapling/ 312 名前：デフォルトの名無しさん [2022/11/17(木) 08:39:39.23 ID:t8CddWfYa.net] >>303 これは楽しみ でもネーミングがダメだな 一般的な単語をそのまま使うのは検索性が劣るので普及しにくくなる 313 名前：デフォルトの名無しさん [2022/11/17(木) 09:11:12.47 ID:782WqxX70.net] 大抵の環境ではslって打つと汽車走るしなぁ 314 名前：デフォルトの名無しさん [2022/11/17(木) 09:56:43.00 ID:V4QZv0Fqa.net] >>296 Git じゃなくて GitHub の話になるけど GitHub の fork はそこをうまく解決出来る手段だと思うわ 315 名前：デフォルトの名無しさん [2022/11/17(木) 10:03:55.51 ID:V4QZv0Fqa.net] >>301 判ります 316 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 4bce-IHKV) mailto:sage [2022/11/17(木) 14:30:18.96 ID:gm2HE+q+0.net] zuckerにしとけばよかったのに zucker --clone 317 名前：デフォルトの名無しさん [2022/11/17(木) 19:17:01.68 ID:782WqxX70.net] Gitオワタｗｗｗ Meta、Git互換のソースコード管理クライアント「Sapling」をオープンソース化 https://codezine.jp/article/detail/16876 > なお、インタラクティブなsmartlog Web UIも用意されており、「sl web」を実行するだけでWebブラウザが起動され、スマートログ、コミット、修正、チェックアウトなどの表示が可能となる。ほかにも、sl undo、sl redo、sl uncommit、sl unamendといったさまざまな操作を元に戻せるコマンドも用意されている。 318 名前：デフォルトの名無しさん mailto:sage [2022/11/17(木) 19:53:43.27 ID:CXVXUQuWM.net] meta の人が首切られても twitter の人みたいにならないようにしてるんかな 319 名前：デフォルトの名無しさん mailto:age [2022/11/17(木) 19:55:29.04 ID:nV36xVvO0.net] >>310 お前何回同じリンク貼ってるの？ 馬鹿なの？ >>303 >>304 320 名前：デフォルトの名無しさん [2022/11/17(木) 20:29:34.50 ID:uFwG0ab0a.net] gitおじさんイライラで草ｗ codezineのリンクは初出だがｗ涙で字が見えないらしいｗｗｗ 321 名前：デフォルトの名無しさん mailto:sage [2022/11/17(木) 20:45:14.23 ID:oYIw5RmVa.net] 200m四方までズームで追える仕様が、200cm四方までズームで追える仕様になってないと、置きかわりは無理やで。 322 名前：デフォルトの名無しさん mailto:sage [2022/11/17(木) 21:19:54.35 ID:ArWNCDPA0.net] gitを使っている人ならsaplingの方が良いと思ったら乗り換えるだろうが gitが難しいとか言ってる人に使いこなせるんだろうか 323 名前：デフォルトの名無しさん mailto:sage [2022/11/17(木) 22:08:49.01 ID:EURizIvt0.net] >>315 どうだろうね？ 逆にgitに慣れた人が乗る換える利点は全くなさそうだけど、rebase 使ったことないとかほざいてる人たちは、とっと乗り換えるのが吉かもしれない。 ま、ちゃんとソースとか公開されてから評価なので今の時点で考えても無駄だな。 324 名前：デフォルトの名無しさん mailto:sage [2022/11/17(木) 23:07:28.26 ID:S8efKX2d0.net] gitよりもできることが制限されるとしたら乗り換えるメリット全くないな 325 名前：デフォルトの名無しさん mailto:sage [2022/11/18(金) 00:06:31.69 ID:jciRgkpH0.net] ステージングがない時点で移行できる人は初心者とかに限られてる気がするんだけど…… 326 名前：デフォルトの名無しさん mailto:sage [2022/11/18(金) 03:05:52.17 ID:NJJaJqGX0.net] ごくわずかしかいないhgユーザーなら移行もありなんじゃね 知らんけど 327 名前：デフォルトの名無しさん mailto:sage [2022/11/18(金) 06:51:03.16 ID:AxmdzuHg0.net] >>302 お前らではな。それがGit以前の「最低限」だったし、その状況でGNU/Linuxは完全に動作してた。 ただまあ、Gitが何でどういう連中に崇拝されてるのかは理解出来たよ。 最終目的の「長期的メンテナンス」を、「コードの品質」でやるか「スーパークレクレ君」でやるかの違いだ。 ん～、やはり全く納得できんが、まあ見物だ。 しかし「スーパークレクレ君」にしても、最低限の選別眼は必要だと思うがなあ。Git開発陣にはこれもない。 昔から「仕事は段取り8割」と言われていて、プログラミングにもこれは当てはまるが、 「それなりの経験を積まないと、何が起こるかまるで想定出来ないので、段取りしようにも出来ない」という本質的な問題があって、 Gitはここを破壊したのだろう。だから本質的に初心者ホイホイで、初心者こそGitの恩恵にあやかれる。 道路工事やビル建設とは違い、情報だけを相手にするプログラミングだから、成立するのかもしれん。 Git開発陣見てると「段取り？何それ美味しいの？」だからね。 対して従来型は結局のところ「段取り」良くやろうとしてるだけだ。 ただGit開発陣以外はGitをツールとして段取り良くする為に使ってるし、俺はそいつらの方が正しいと思うけど。 それから、 従来： 「将来の手間の最小化」を目指し、今手間をかけて疎結合化する。(これにはリソースが限られているという大前提がある) Git： 「リソースは無限大」なのだから、今の手間を最小化し、とにかく人を集めれば、いつか誰かが良いコードを書いてくれる。 とまあ、これも正反対だ。 結局のところ、従来型における「自分達でやらねばならない」という、 当たり前すぎて前提条件とも言われない、プロジェクトに於ける潜在意識みたいな物を、 Gitはぶち壊し、「いつか誰かがやってくれるんだから良いじゃん」とまあ、 (見てないけど)ゆたぽんに対する嫌悪感と同質の物を俺は感じる。あれもネットがなければまるで成立しないのが同じ。 良く言えばネット社会に適応したとも言えるわけだが、なんだかねー。 328 名前：デフォルトの名無しさん mailto:sage [2022/11/18(金) 06:51:32.62 ID:AxmdzuHg0.net] まあそりゃプログラミングの勉強なんてキリがないし、10,000時間とか要求されるし、 これに比べれば50-100時間もすればツールの達人には成れるから、おまえらみたいな馬鹿には魅力的に映るんだろうが、 マジでプログラマってコード書けない奴はゴミとしか見てないから、そこだけは注意しておいた方がいいと思うぜ。 (個人的にはこれも行きすぎだとも思ってはいるが) ちなみに個人的にはこういう正当な苦労はしないと意味ないと思ってる。 自分にとって獲得が楽な知識は、他人にとっても楽なんだよ。 先行すれば、一時的にはちやほやされるかもしれないが、すぐに取って代わられるし、使い 329 名前：捨てられる。 プログラマなら、正当に、プログラミングの勉強をするべきだと思うぜ。 お前にとって10,000時間かかることは、後輩にとっても10,000時間かかるんだよ。 ツール屋として生きる、ってのも俺はありだとは思うけどな。(ただ多くのプログラマはそうは見てない) [] [ここ壊れてます] 330 名前：デフォルトの名無しさん mailto:sage [2022/11/18(金) 06:53:10.29 ID:AxmdzuHg0.net] >>315 その感覚が既にズレてる。 ×　使いこなす ○　コードを書くことに集中しろ 自動rebaseってのは、ユーザーがrebaseする必要なくしているわけで、つまり、 プログラマはコードを書くことに集中しろ、日々の業務フロー通りにやってれば、自動的に上手く記録されるようになってる、というだけ。 要は「本業に集中しろ」であり、至極真っ当な方策。 使いこなすのではなく、そもそも使ってる感覚すら無くすことを目指してる。これは正しい。 メールや名刺を放り投げておいたら自動的に完璧に整理されてて、「あん時のアレ！」で出てくる、みたいな話。 或いは卒アルと言えば分かりやすいか？ まあ今時の若者には逆に通じないかもしれないが、 俺らが高校生だった大昔は、今みたいに全員がカメラ持ってる状況ではなかったから、 提携業者が勝手に学校に出入りして日々の授業風景から学園祭まで色々写真を撮り溜めてた。 そして卒アルとして編集されて、勝手に出てきた。 俺らは生徒として活動してれば、そつなく記録されてた、というわけ。これを目指してる。 日々の業務フローを適切にこなしてれば、完璧に記録されてるから、本業に集中しろ、というわけ。 使いこなす必要なんて、最初から無いんだよ。業務フローを守れ、それだけ。 331 名前：デフォルトの名無しさん mailto:sage [2022/11/18(金) 07:20:39.11 ID:jciRgkpH0.net] コミット・メッセージ不要とか言ってる長文君が、重要なのは将来の手間の最小化とか言ってて草 一人でしか開発したことないやつの戯言だね

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef