Git 20

ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡

34: (ﾜｯﾁｮｲ 0b38-VVnD) 2024/10/27(日)06:40:21.04 ID:VfBaenuQ0(1) AAS
結局PCもgitも関係ないところのエラーだったんだろうな

88: (ﾜｯﾁｮｲ 42d2-YlA6) 2024/11/18(月)23:21:35.04 ID:cZsx9Sbk0(1) AAS
日本人はやたら正解があることにしたがるが、外国人は正解が複数存在するという考えだから発展する。

133(2): (ﾜｯﾁｮｲ e77b-BDa8) 2024/12/09(月)14:14:55.04 ID:oqd+iiqc0(5/10) AAS
>>131
お前らGit信者はOSSを勘違いしてて、

×　OSSは自由に改変出来るので必要な機能は全て実装されている
○　OSSに実装されている機能は全て、
　誰かがブチ切れて「こんなのやり続けるくらいなら俺が実装してやる！」となった結果であって、
　当たり前だが不満は常に溜まった状態にあり、爆発ない限り何も改善しない
　(不満があってブチ切れたとき、プロプライエタリでは使用を止めることしかできないが、
　OSSなら自分で機能を付加するという選択肢もある、程度)

つまりGitに限らずOSSは完璧でもなく、足りない機能は普通にありまくりで、
Gitの場合はパーミッションがそうだ、というだけ
お前らがそこで、ムキー！！！ならお前が実装しろ！！！ってなるのも狂ってるよ

286: (ﾜｯﾁｮｲ 7a86-Uu4E) 01/27(月)23:35:25.04 ID:5zVfH4ct0(1) AAS
>>284
40歳以上なら知っている

314(1): (ﾜｯﾁｮｲ cebb-ncSF) 01/30(木)17:25:50.04 ID:5L7oVd850(3/3) AAS
>>309
>>311
github は分散リポジトリを念頭にサーバ上の統合作業の用語を選択した
gitlab は共用リポジトリを念頭にサーバ上の統合作業の用語を選択した

これは本来の git の意図とはズレてるのでリーナスが切れた（サーバ上では統合作業 merge/pull しない、それらは手元のローカル・リポジトリでやるのが git 本来の流儀）

git で pull request はもともと相手のローカル・リポジトリへの pull を要求するというそのままの意味（github は用語を変に流用しただけ、本来の使い方ではない

linux kernel だと subsystem maintainer とかが subsystem の開発リポジトリから完成した分をリーナスの個人リポジトリに取り込んでリリースに含めるよう最終的な要求するのが pull request の意味
コードのレビューとかはもっとずっと前に ML とかで多くの人が議論し尽くしてる、そういうのが全部終わって次のバージョンのリリースに含めて良くなったら pull request 出す

327(1): (ﾜｯﾁｮｲ 9ebb-yVXq) 02/14(金)12:41:44.04 ID:cflAAi0P0(1) AAS
>>326
みんなの集まる会議の席上で天気の質問とか始めたら、「さっさと始めろ、他人の時間を無駄にするな」って怒られるだろ
個人の雑談と、多数が集まる場所での発言は違うんじゃないかな？
他人の時間を無駄にしないために自分で調べられることは調べた上で、分からない部分があったら質問するのが人としての礼儀

371: (ﾜｯﾁｮｲ 536a-t7h7) 03/07(金)02:01:32.04 ID:hA31zhIA0(1) AAS
GUIでポトペタばっかしとる奴らの前提が空で覚えるの前提なん草
そもそもTerminalもGitbashもインテリセンス効くことを知らんの無知すぎてクソワロタ

386(1): (ﾜｯﾁｮｲ 7b57-fnNf) 03/07(金)14:16:08.04 ID:hv4T53nE0(2/3) AAS
>>385
マウスの持ち替え気にするくせにハッシュを目視で確認して打ち込む非効率さは目をつぶる
インタフェースやビジュアライズの大切さを無視するエンジニアとは仕事したくないね
ちなデバッガももしかしてCLIかい？w

490: (ﾜｯﾁｮｲ 2303-FL2f) 06/23(月)19:49:45.04 ID:Z8z+4HFt0(1) AAS
といっても元のコミットがある程度ちゃんと作られてることが前提じゃない？
単に作業のチェックポイントとして気軽にコミットしてると、いざコードレビュー前に整理しようとしたときには元のコミットを無理に再利用するより
resetして作り直した方が早いことが個人的には多い
書いてて思ったけど、元のコミットがすでに整理されている上で修正を入れる状況としては、コードレビューの中での修正があるね
もしチームのポリシーとして瑣末な指摘反映をログに残さないことにしているなら、レビュー後マージ前にrebase -iするのは便利かもしれない

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

ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ

ぬこの手ぬこTOP 0.028s