Git 20 (530ﾚｽ)
Git 20 http://mevius.5ch.net/test/read.cgi/tech/1707958209/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
187: デフォルトの名無しさん (ﾜｯﾁｮｲ 875c-QLAB) [sage] 2024/12/11(水) 19:28:51.98 ID:kPp0f2Rs0 >>186 開発者に「俺達の利便性のために、お前らはチェックアウトするごとに手動でcleanして一からビルドしろ」と言ったらさすがに傲慢かと。 gitはプログラム開発者がソースコード管理のために用意したツールだから、開発者にとって百害あって一利無しの機能が入ることは無いんじゃないんかね。 http://mevius.5ch.net/test/read.cgi/tech/1707958209/187
188: デフォルトの名無しさん (ﾜｯﾁｮｲ 47dd-s3+3) [sage] 2024/12/11(水) 20:38:24.90 ID:WFtEMDpk0 >>182 Subversionには、ファイルのタイムスタンプをコミット日時にする設定はあるけどな もちろん、makeを使うような人には危険な機能だが、それなりの要望はあったのだろう http://mevius.5ch.net/test/read.cgi/tech/1707958209/188
189: デフォルトの名無しさん (ﾜｯﾁｮｲ e77b-BDa8) [sage] 2024/12/11(水) 20:46:11.17 ID:bZvW/lze0 >>187 それはお前が傲慢すぎ 元々makeはインクリメンタルビルドの為のツールで、 Git以前からC界隈ではほぼ100%使われてたし、勿論Linusも使ってたはず make clean; make distclean; は常識であり、知らない奴は死ねレベル ただし通常はそもそも clean する必要がない clean はだいたい rm *o だが、そもそも中間ファイル(*.o)は tar ボールには入ってないので、自分で make しない限り存在しない だから「同一ディレクトリで『再度』makeし
なおす」前に make clean であって、初回はやる必要がない つまり「何度もビルドし直す」実際の開発者向けの機能であり 「ソースをダウンロードして一回ビルド成功したら終わり」のユーザーはどのみち clean なんてやる必要がないし、知らなくていい これがGitの普及で毎回全部リビルドがデフォになっており、 君のように勘違いしてたり、あるいは makefile 内の clean が機能しなくなってる(メンテされてない)、という可能性はある 或いは、この辺の行き違いがLinuxで相当数発生し、『常に全部リビルド』するようにLinusが作った、という可能性もあ
る (Linus発言見てる限りは「タイムスタンプじゃなくてちゃんとコメント書けやボケ！」のように感じるが) ただまあ、どのみちお前らのような、現状のGitに満足してる連中にはどうでもいい事だし、 俺ならタイプスタンプは戻すし、Gitにはコミットせずにフォークして勝手に作る 勿論気に入らなければ使うな、タイムスタンプ戻したければ勝手に使えだし ただお前ら、繰り返すが > それを思いついたやつは今までいない (126) とか考えるのがとにかく傲慢すぎるんだよ 自分以外は超絶馬鹿としか思ってない奴しかこんな発言はできない 実際には、考え
た上で、違う選択になってる 「タイムスタンプも保存した方がいいのでは」という提案を、これまで世界で誰も思いつかなかった、なんて事はあり得ない Linus自身も最初から分かってて、敢えて落としてるんだよ で、本来は、その落とした理由が分からないと地雷を踏むだけなので確認すべきなんだけども、 Git信者共はポジショントークを繰り返すだけでクソ使えねえ、 まあどのみちrejectされるのは分かり切ってるのでやるならフォークしかない、といったところ http://mevius.5ch.net/test/read.cgi/tech/1707958209/189
190: デフォルトの名無しさん (ﾜｯﾁｮｲ 7fbb-rdwU) [sage] 2024/12/11(水) 21:17:41.31 ID:+nAxu/ku0 何も分かってないやつがいて草 タイムスタンプは過去には戻らない未来に進むだけ、という前提で多くのツールが設計されてる make もそう この前提を壊さないように配慮することが大原則で git のみならず unix 系のツールは設計されてる バックアップからの復元はこの前提を壊して過去に時間を戻す行為なので特別な時にのみ使うもの http://mevius.5ch.net/test/read.cgi/tech/1707958209/190
191: デフォルトの名無しさん (ﾜｯﾁｮｲ e77b-BDa8) [sage] 2024/12/11(水) 21:35:45.41 ID:bZvW/lze0 >>190 zipやtarは普通にタイムスタンプは保存されるだろ その延長で考えるなら、保存された方が自然だし有用だ、というだけ ただまあ、これも合意する必要はない フォークしてどちらがウケるかで決するフォーク主義が正しいし、ユーザーは好きな方使えば済むだけ (現実的にはcp -p と同様にオプションで切り替えるのが普通で、 逆に言えばオプションすら存在しないGitは何らかの「意図」をもってそうしてるとも言える 理由は今のところ不明な
ので思いつく人はよろしく) まあ心配せずとも、Linuxカーネルにコミットしてくる連中で、make clean を知らない奴なんて一人もいないよ (だから多分問題はここではない) http://mevius.5ch.net/test/read.cgi/tech/1707958209/191
192: デフォルトの名無しさん (ﾜｯﾁｮｲ 7fbb-rdwU) [sage] 2024/12/12(木) 00:21:35.10 ID:C7R5gozk0 git pull した後に make clean とか git 使ったことないのが丸わかりだな 何のための make だよ？ http://mevius.5ch.net/test/read.cgi/tech/1707958209/192
193: デフォルトの名無しさん (ﾜｯﾁｮｲ 4768-u/4x) [] 2024/12/12(木) 01:11:52.06 ID:2Npzz1EV0 負け組のためのだろ http://mevius.5ch.net/test/read.cgi/tech/1707958209/193
194: デフォルトの名無しさん (ﾜｯﾁｮｲ 5f8e-QLAB) [sage] 2024/12/12(木) 08:57:54.12 ID:yWChnlb80 >>189 「俺はタイムスタンプの管理をgitでやりたいから、お前らはチェックアウトするごとにmake dustclean しろ」と言ったら、温厚になったLinusでもさすがに罵倒するかと。 gitはLinusがlinuxのソースコードを管理するために作ったツール。今もメインユーザーはLinux開発者で想定利用シーンもLinux開発なんだから、「Linux開発者の足を引っ張る機能」を追加するのはディレクターの正気を疑うレベルですな。 http://mevius.5ch.net/test/read
.cgi/tech/1707958209/194
195: デフォルトの名無しさん (ﾜｯﾁｮｲ 7fbb-rdwU) [sage] 2024/12/12(木) 09:15:02.60 ID:C7R5gozk0 >>194 いや linux とか Linus とかもはや関係なく全プログラマー大爆笑案件だろ git pull で同期したら日付が過去に戻りましたとか全員が git の使用やめるレベル http://mevius.5ch.net/test/read.cgi/tech/1707958209/195
196: デフォルトの名無しさん (ﾜｯﾁｮｲ 67e6-s3+3) [sage] 2024/12/12(木) 09:16:55.48 ID:OOlmzVQX0 https://stackoverflow.com/questions/1964470/whats-the-equivalent-of-subversions-use-commit-times-for-git PythonやPerlを使う人には、makeのためにタイムスタンプが失われるのはいい迷惑だと言われてるな 今さらリポジトリにメタデータを埋め込むのは難しいにしても、 gitconfigで>>188くらいさせてくれてもいいのにとは思う http://mevius.5ch.net/test/read.cgi/tech/1707958209/196
197: デフォルトの名無しさん (ﾜｯﾁｮｲ e7c8-iSwO) [sage] 2024/12/12(木) 15:16:51.62 ID:d+ZuY6W00 >>196 当然だが既に同じことを考えてパッチしてた奴が居たか > Linus' rationale of timestamps being harmful just because it "confuses make" is lame: 189に書いたようにこれはないと思ってたが、マジだったとは makeで問題になる場合って、 makeした同じディレクトリでより古いバージョンでソースを上書きしてcleanせずにmakeした場合、 に限られるのでLinus以外はほぼやらねえし、Linusがmakeの使い方知らんわけねえし、ね
えわと思ってたが、 自分専用ツールだからカスタマイズ済みの感じか とはいえ謎の地雷があるわけではなさそうというのは分かった、ありがとう 普通に考えれば、保存した上で戻す際にオプションで選べるようにしておけばいいだけなのだがな この辺Gitは無駄に押し付けがましいのが意識高い系と被るし、 だからこそ連中とも親和性が高く、このスレにもそういう奴が多いのだろうけど 用途は考え方の違いで、(俺がそういう使い方をするわけではないが) cron に commit させとけば、VCSはバックアップツールとしても使えて、 偶に過去バージョンにパッチ
当てる際は branch すればいいのだから、 一本線しか許されないバックアップツールよりはソースコードのバックアップには向いているというだけ ただHgなら保存されるのか？なら俺はそれでもいいんだが (料理の腕前で勝負してるのに、整理棚に必要以上にこだわっても本末転倒) http://mevius.5ch.net/test/read.cgi/tech/1707958209/197
198: デフォルトの名無しさん (ﾜｯﾁｮｲ 27bb-s3+3) [sage] 2024/12/12(木) 15:21:09.29 ID:JM/xCx8/0 料理の腕前で勝負してるつもりならさっさとWitBucketとやらを作れよ http://mevius.5ch.net/test/read.cgi/tech/1707958209/198
199: デフォルトの名無しさん (ﾌﾞｰｲﾓ MM8b-dt5O) [sage] 2024/12/12(木) 16:33:59.70 ID:d0NKDmelM >>197 ChatGPTで3行に縮めて投稿しろ http://mevius.5ch.net/test/read.cgi/tech/1707958209/199
200: デフォルトの名無しさん (ﾜｯﾁｮｲ 5f8e-QLAB) [sage] 2024/12/12(木) 18:58:50.56 ID:yWChnlb80 >>197 >Linus以外はほぼやらねえし、 「gitはLinusがLinux開発で使うために作った」という大前提を忘れるのはアルツハイマー病の一種かしらん？ http://mevius.5ch.net/test/read.cgi/tech/1707958209/200
201: デフォルトの名無しさん (ﾜｯﾁｮｲ 7f10-f5HH) [sage] 2024/12/14(土) 10:34:37.92 ID:mefXJp+A0 Gitの使い方というかSourcetreeの使い方というか質問があります とある1コミットに複数ファイルがあって複数個所に変更がまたがってて 別ブランチにそのコミットの1ファイルの1部分だけをマージしたいです その場合はチェリーピックは使えないので1部分のHunkをステージングに移動して コミットするという方法が素直なマージ方法でしょうか？ http://mevius.5ch.net/test/read.cgi/tech/1707958209/201
202: デフォルトの名無しさん (ﾜｯﾁｮｲ 7fbb-rdwU) [sage] 2024/12/14(土) 11:43:48.24 ID:kPFQFgKW0 >>201 採用元が push 後とか他人のコードだとそんな感じかな 私だと cherry-pick してから巻き戻し修正するけど、複数パッチなら rebase -i で edit を使う 採用元がローカルにしかない push 前なら元のコミットを分割しておくのが良い方法だろう 将来的に再利用するときにも別々に利用する可能性があるものは、今のうちに別パッチに分割しておくのが賢いと思う http://mevius.5ch.net/test/read.cgi/tech/1707958209/202
203: デフォルトの名無しさん (ﾜｯﾁｮｲ 7f10-f5HH) [sage] 2024/12/14(土) 11:54:03.74 ID:mefXJp+A0 >>202 回答ありがとうございます まさに他人がプッシュしたものを派生ブランチにも適用させようとしています その中に特定ブランチの対応分も混ぜてしまっていたため どう対応すべきか質問した次第です コミット分割は癖にしておきたいと思います http://mevius.5ch.net/test/read.cgi/tech/1707958209/203
204: デフォルトの名無しさん (ﾜｯﾁｮｲ 87f0-gWKG) [sage] 2024/12/14(土) 14:22:21.70 ID:jFwYZGRF0 ろくに開発経験ないやつがgitの仕様はグダグダとか言ってるのまじで面白いな http://mevius.5ch.net/test/read.cgi/tech/1707958209/204
205: デフォルトの名無しさん (ﾜｯﾁｮｲ dffd-thkz) [] 2024/12/14(土) 19:07:11.21 ID:cLbKsfdN0 >>93の質問以降まともだったのは96、97、99、101、107くらいしかいなかった 7bは置いとくとしても100レスも使ってこの体たらくとは情けない http://mevius.5ch.net/test/read.cgi/tech/1707958209/205
206: デフォルトの名無しさん (ﾜｯﾁｮｲ 4a97-66FK) [] 2024/12/15(日) 22:01:21.97 ID:D9xraIFr0 >>178 diffでわざわざ比較するというのは時間の無駄 http://mevius.5ch.net/test/read.cgi/tech/1707958209/206
207: デフォルトの名無しさん (ﾜｯﾁｮｲ 3ebb-f1VN) [sage] 2024/12/15(日) 22:49:45.11 ID:9FCwcKO70 >>206 相手にすんな バケツ君はマニュアル読めなくて git が外部 diff に対応してることすら見つけられずに俺の望む出力じゃないと散々暴れた過去がある、今もそう思い込んでるので http://mevius.5ch.net/test/read.cgi/tech/1707958209/207
208: デフォルトの名無しさん (ﾜｯﾁｮｲ fb50-Nme3) [sage] 2024/12/15(日) 23:49:43.28 ID:UElXL8/K0 >>203 コミットの際にcherry-pickまで考慮するなんて不毛だからやめておいた方がいいよ そんなことをしなければならないほど強くcherry-pickに依存したワークフローになっているならその方がよほど問題 http://mevius.5ch.net/test/read.cgi/tech/1707958209/208
209: デフォルトの名無しさん (ﾜｯﾁｮｲ eac0-Hfw5) [sage] 2024/12/16(月) 00:02:22.98 ID:I9YsDANU0 不毛っていうのも程度問題でしょ 経験の浅いメンバーだと一つのコミットに複数のバグトラッカーのissueを混ぜこぜにすることがある hot−fixブランチが必ずしも計画的に作られるとは限らないからcherry-pickで取り出したいことは時々起こる http://mevius.5ch.net/test/read.cgi/tech/1707958209/209
210: デフォルトの名無しさん (ﾜｯﾁｮｲ 8fd6-NWjc) [sage] 2024/12/16(月) 12:28:18.00 ID:UeL/Eu4T0 cherry-pickに依存するのは不毛だと思うが、リモートへのコミットは機能単位・イシュー単位に整理した方がやり取り楽じゃない？ http://mevius.5ch.net/test/read.cgi/tech/1707958209/210
211: デフォルトの名無しさん (ﾜｯﾁｮｲ 3ebb-f1VN) [sage] 2024/12/16(月) 12:38:05.37 ID:ZibPg38H0 同じプロジェクト内に並行で製品(バージョン)を維持しているような場合には cherry-pick は多用するよ 特にブランチ切るまでもない単純な修正の場合とか 要はコミット1個だけのブランチの rebase/merge の簡略形なので不毛とか言うやつは単に経験が足りないだけ http://mevius.5ch.net/test/read.cgi/tech/1707958209/211
212: デフォルトの名無しさん (ﾜｯﾁｮｲ 8fd6-NWjc) [sage] 2024/12/16(月) 12:42:21.10 ID:UeL/Eu4T0 せっかくbranch切ったのに、merge代わりにcherry-pickしたら後でトレース面倒にならん？ http://mevius.5ch.net/test/read.cgi/tech/1707958209/212
213: デフォルトの名無しさん (ﾜｯﾁｮｲ 3ebb-f1VN) [sage] 2024/12/16(月) 12:53:45.68 ID:ZibPg38H0 >>212 cherry-pick はブランチ切るまでもない修正用だよ コミット1個ならどこから cherry-pick したか分かれば良いだけだし http://mevius.5ch.net/test/read.cgi/tech/1707958209/213
214: デフォルトの名無しさん (ﾜｯﾁｮｲ 4a6b-O1Z7) [] 2024/12/16(月) 13:11:10.31 ID:56LO+jCc0 今度はチェリーピックでやり合いか http://mevius.5ch.net/test/read.cgi/tech/1707958209/214
215: デフォルトの名無しさん (ﾜｯﾁｮｲ eaa0-Hfw5) [sage] 2024/12/16(月) 13:17:14.68 ID:I9YsDANU0 将来どのコミットが急遽hotfixに採用されるか分からないからといってあらゆる事前の修正コミットをもしものためだけにブランチ分けするのもガチガチで作業効率が落ちる 程度問題と言った通り俺はcherry-pickを多用する気もないしフローとして禁止扱いも効率が悪いと思う hotfixが必要ない現場なら必要になる機会は少ないだろうな http://mevius.5ch.net/test/read.cgi/tech/1707958209/215
216: デフォルトの名無しさん (ﾜｯﾁｮｲ 3ebb-f1VN) [sage] 2024/12/16(月) 13:41:54.88 ID:ZibPg38H0 cherry-pick には複数の使いみちがあって別に全部の使い方しなければいけない訳ではないが色々知ってると便利 ・最新版から過去リリースへのバックポート ・セキュリティなどの hotfix の適用 ・テスト用の addhoc 修正版（正式なマージは今ではない ・ゴミ箱ブランチ等から拾ってコードの再利用（コードだけ拾ってコミットは再利用しない など多数 「1つのコミットには1つの修正」という大原則を守ってさえいれば、cherry-pick に限らずあらゆる再
利用や利用中止がやり易くなるといだけ http://mevius.5ch.net/test/read.cgi/tech/1707958209/216
ﾒﾓ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 314 ﾚｽあります
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.011s