Git 20 (530ﾚｽ)
上下前次1-新
187(1): (ﾜｯﾁｮｲ 875c-QLAB) 2024/12/11(水)19:28 ID:kPp0f2Rs0(2/2) AAS
>>186
開発者に「俺達の利便性のために、お前らはチェックアウトするごとに手動でcleanして一からビルドしろ」と言ったらさすがに傲慢かと。
gitはプログラム開発者がソースコード管理のために用意したツールだから、開発者にとって百害あって一利無しの機能が入ることは無いんじゃないんかね。
188(1): (ﾜｯﾁｮｲ 47dd-s3+3) 2024/12/11(水)20:38 ID:WFtEMDpk0(1) AAS
>>182
Subversionには、ファイルのタイムスタンプをコミット日時にする設定はあるけどな
もちろん、makeを使うような人には危険な機能だが、それなりの要望はあったのだろう
189(1): (ﾜｯﾁｮｲ e77b-BDa8) 2024/12/11(水)20:46 ID:bZvW/lze0(3/4) AAS
>>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されるのは分かり切ってるのでやるならフォークしかない、といったところ
190(1): (ﾜｯﾁｮｲ 7fbb-rdwU) 2024/12/11(水)21:17 ID:+nAxu/ku0(3/3) AAS
何も分かってないやつがいて草
タイムスタンプは過去には戻らない未来に進むだけ、という前提で多くのツールが設計されてる make もそう
この前提を壊さないように配慮することが大原則で git のみならず unix 系のツールは設計されてる
バックアップからの復元はこの前提を壊して過去に時間を戻す行為なので特別な時にのみ使うもの
191: (ﾜｯﾁｮｲ e77b-BDa8) 2024/12/11(水)21:35 ID:bZvW/lze0(4/4) AAS
>>190
zipやtarは普通にタイムスタンプは保存されるだろ
その延長で考えるなら、保存された方が自然だし有用だ、というだけ
ただまあ、これも合意する必要はない
フォークしてどちらがウケるかで決するフォーク主義が正しいし、ユーザーは好きな方使えば済むだけ
(現実的にはcp -p と同様にオプションで切り替えるのが普通で、
逆に言えばオプションすら存在しないGitは何らかの「意図」をもってそうしてるとも言える
理由は今のところ不明なので思いつく人はよろしく)
まあ心配せずとも、Linuxカーネルにコミットしてくる連中で、make clean を知らない奴なんて一人もいないよ
(だから多分問題はここではない)
192: (ﾜｯﾁｮｲ 7fbb-rdwU) 2024/12/12(木)00:21 ID:C7R5gozk0(1/2) AAS
git pull した後に make clean とか git 使ったことないのが丸わかりだな
何のための make だよ？
193: (ﾜｯﾁｮｲ 4768-u/4x) 2024/12/12(木)01:11 ID:2Npzz1EV0(1) AAS
負け組のためのだろ
194(1): (ﾜｯﾁｮｲ 5f8e-QLAB) 2024/12/12(木)08:57 ID:yWChnlb80(1/2) AAS
>>189
「俺はタイムスタンプの管理をgitでやりたいから、お前らはチェックアウトするごとにmake dustclean しろ」と言ったら、温厚になったLinusでもさすがに罵倒するかと。
gitはLinusがlinuxのソースコードを管理するために作ったツール。今もメインユーザーはLinux開発者で想定利用シーンもLinux開発なんだから、「Linux開発者の足を引っ張る機能」を追加するのはディレクターの正気を疑うレベルですな。
195: (ﾜｯﾁｮｲ 7fbb-rdwU) 2024/12/12(木)09:15 ID:C7R5gozk0(2/2) AAS
>>194
いや linux とか Linus とかもはや関係なく全プログラマー大爆笑案件だろ
git pull で同期したら日付が過去に戻りましたとか全員が git の使用やめるレベル
196(1): (ﾜｯﾁｮｲ 67e6-s3+3) 2024/12/12(木)09:16 ID:OOlmzVQX0(1) AAS
外部ﾘﾝｸ:stackoverflow.com
PythonやPerlを使う人には、makeのためにタイムスタンプが失われるのはいい迷惑だと言われてるな
今さらリポジトリにメタデータを埋め込むのは難しいにしても、
gitconfigで>>188くらいさせてくれてもいいのにとは思う
197(2): (ﾜｯﾁｮｲ e7c8-iSwO) 2024/12/12(木)15:16 ID:d+ZuY6W00(1) AAS
>>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なら保存されるのか？なら俺はそれでもいいんだが
(料理の腕前で勝負してるのに、整理棚に必要以上にこだわっても本末転倒)
198: (ﾜｯﾁｮｲ 27bb-s3+3) 2024/12/12(木)15:21 ID:JM/xCx8/0(1) AAS
料理の腕前で勝負してるつもりならさっさとWitBucketとやらを作れよ
199: (ﾌﾞｰｲﾓ MM8b-dt5O) 2024/12/12(木)16:33 ID:d0NKDmelM(1) AAS
>>197
ChatGPTで3行に縮めて投稿しろ
200: (ﾜｯﾁｮｲ 5f8e-QLAB) 2024/12/12(木)18:58 ID:yWChnlb80(2/2) AAS
>>197
>Linus以外はほぼやらねえし、
「gitはLinusがLinux開発で使うために作った」という大前提を忘れるのはアルツハイマー病の一種かしらん？
201(1): (ﾜｯﾁｮｲ 7f10-f5HH) 2024/12/14(土)10:34 ID:mefXJp+A0(1/2) AAS
Gitの使い方というかSourcetreeの使い方というか質問があります
とある1コミットに複数ファイルがあって複数個所に変更がまたがってて
別ブランチにそのコミットの1ファイルの1部分だけをマージしたいです
その場合はチェリーピックは使えないので1部分のHunkをステージングに移動して
コミットするという方法が素直なマージ方法でしょうか？
202(1): (ﾜｯﾁｮｲ 7fbb-rdwU) 2024/12/14(土)11:43 ID:kPFQFgKW0(1) AAS
>>201
採用元が push 後とか他人のコードだとそんな感じかな
私だと cherry-pick してから巻き戻し修正するけど、複数パッチなら rebase -i で edit を使う
採用元がローカルにしかない push 前なら元のコミットを分割しておくのが良い方法だろう
将来的に再利用するときにも別々に利用する可能性があるものは、今のうちに別パッチに分割しておくのが賢いと思う
203(1): (ﾜｯﾁｮｲ 7f10-f5HH) 2024/12/14(土)11:54 ID:mefXJp+A0(2/2) AAS
>>202
回答ありがとうございます
まさに他人がプッシュしたものを派生ブランチにも適用させようとしています
その中に特定ブランチの対応分も混ぜてしまっていたため
どう対応すべきか質問した次第です
コミット分割は癖にしておきたいと思います
204: (ﾜｯﾁｮｲ 87f0-gWKG) 2024/12/14(土)14:22 ID:jFwYZGRF0(1) AAS
ろくに開発経験ないやつがgitの仕様はグダグダとか言ってるのまじで面白いな
205: (ﾜｯﾁｮｲ dffd-thkz) 2024/12/14(土)19:07 ID:cLbKsfdN0(1) AAS
>>93の質問以降まともだったのは96、97、99、101、107くらいしかいなかった
7bは置いとくとしても100レスも使ってこの体たらくとは情けない
206(1): (ﾜｯﾁｮｲ 4a97-66FK) 2024/12/15(日)22:01 ID:D9xraIFr0(1) AAS
>>178
diffでわざわざ比較するというのは時間の無駄
207: (ﾜｯﾁｮｲ 3ebb-f1VN) 2024/12/15(日)22:49 ID:9FCwcKO70(1) AAS
>>206
相手にすんな
バケツ君はマニュアル読めなくて git が外部 diff に対応してることすら見つけられずに俺の望む出力じゃないと散々暴れた過去がある、今もそう思い込んでるので
208: (ﾜｯﾁｮｲ fb50-Nme3) 2024/12/15(日)23:49 ID:UElXL8/K0(1) AAS
>>203
コミットの際にcherry-pickまで考慮するなんて不毛だからやめておいた方がいいよ
そんなことをしなければならないほど強くcherry-pickに依存したワークフローになっているならその方がよほど問題
209: (ﾜｯﾁｮｲ eac0-Hfw5) 2024/12/16(月)00:02 ID:I9YsDANU0(1/2) AAS
不毛っていうのも程度問題でしょ
経験の浅いメンバーだと一つのコミットに複数のバグトラッカーのissueを混ぜこぜにすることがある
hot−fixブランチが必ずしも計画的に作られるとは限らないからcherry-pickで取り出したいことは時々起こる
210: (ﾜｯﾁｮｲ 8fd6-NWjc) 2024/12/16(月)12:28 ID:UeL/Eu4T0(1/2) AAS
cherry-pickに依存するのは不毛だと思うが、リモートへのコミットは機能単位・イシュー単位に整理した方がやり取り楽じゃない？
211: (ﾜｯﾁｮｲ 3ebb-f1VN) 2024/12/16(月)12:38 ID:ZibPg38H0(1/4) AAS
同じプロジェクト内に並行で製品(バージョン)を維持しているような場合には cherry-pick は多用するよ
特にブランチ切るまでもない単純な修正の場合とか
要はコミット1個だけのブランチの rebase/merge の簡略形なので不毛とか言うやつは単に経験が足りないだけ
212(1): (ﾜｯﾁｮｲ 8fd6-NWjc) 2024/12/16(月)12:42 ID:UeL/Eu4T0(2/2) AAS
せっかくbranch切ったのに、merge代わりにcherry-pickしたら後でトレース面倒にならん？
213: (ﾜｯﾁｮｲ 3ebb-f1VN) 2024/12/16(月)12:53 ID:ZibPg38H0(2/4) AAS
>>212
cherry-pick はブランチ切るまでもない修正用だよ
コミット1個ならどこから cherry-pick したか分かれば良いだけだし
214: (ﾜｯﾁｮｲ 4a6b-O1Z7) 2024/12/16(月)13:11 ID:56LO+jCc0(1) AAS
今度はチェリーピックでやり合いか
215: (ﾜｯﾁｮｲ eaa0-Hfw5) 2024/12/16(月)13:17 ID:I9YsDANU0(2/2) AAS
将来どのコミットが急遽hotfixに採用されるか分からないからといってあらゆる事前の修正コミットをもしものためだけにブランチ分けするのもガチガチで作業効率が落ちる
程度問題と言った通り俺はcherry-pickを多用する気もないしフローとして禁止扱いも効率が悪いと思う
hotfixが必要ない現場なら必要になる機会は少ないだろうな
216: (ﾜｯﾁｮｲ 3ebb-f1VN) 2024/12/16(月)13:41 ID:ZibPg38H0(3/4) AAS
cherry-pick には複数の使いみちがあって別に全部の使い方しなければいけない訳ではないが色々知ってると便利
・最新版から過去リリースへのバックポート
・セキュリティなどの hotfix の適用
・テスト用の addhoc 修正版（正式なマージは今ではない
・ゴミ箱ブランチ等から拾ってコードの再利用（コードだけ拾ってコミットは再利用しない
など多数
「1つのコミットには1つの修正」という大原則を守ってさえいれば、cherry-pick に限らずあらゆる再利用や利用中止がやり易くなるといだけ
上下前次1-新書関写板覧索設栞歴
あと 314 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.020s