Git 20

2024/12/09(月) 14:14:55.04

>>131
お前らGit信者はOSSを勘違いしてて、

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

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

2024/12/09(月) 14:26:15.08

>>133
誰も git が完璧なんて言ってないが、今頃になって長文君論法は何故？

道具なので完璧である必要なんてそもそもない、自分が満足いく性能ならそれで良し
oss なんて情熱をもってそれを作る人がいるかとそれを使いたい人がいるかの論理積
存在しないのは作る人がいないか、使いたい人がいないかのどっちか

結果が全て、満足いかないなら、文句あったらお前が変えろの世界、それこそ気に要らなければ使わなくても良い

2024/12/09(月) 14:31:09.65

>>133
誰かが実装するまで不満は残ったままということだろ?
だから不満があるなら自分で実装すればいいと言われている

2024/12/09(月) 14:47:29.93

>>134
> 変えるのは自由、そっちは議論してない(131)
> 長文君論法は何故？(134)
それはお前がフォークしろ論法に逃げたから、俺はフォークしない理由を述べたまで

というか、元の話に戻すと、パーミッションが保存されない件について、

あるある質問者：保存して欲しい、或いは保存されるのが当然だと思ってたのに…
俺：機能の不備で、いつか追加されるだろ
Git信者：保存されないのが仕様だし、正しい！文句あるならGitを使うな！
　或いはフォークしろ！フォークもしないのに文句言うな！

であって、これはもう平行線だからいいと既に127で言ったろ
その後お前がフォークガー論法(128-129)で論点逸らししてきたから、
俺もちょっとつき合ってみたら、逆に俺が論点逸らしした風に装うのだからGit信者は頭おかしい
論点を逸らしたのはお前だぞ
(まあお前が議論慣れしてないだけかもしれんが)

とはいえこの話題についてはもう何も生産性無いし、やめでいいが

2024/12/09(月) 14:54:58.40

俺は 123 の最後にある「どういう理由？」に答えようとしただけで、それ以前の議論の回答はしてないぞ？

現状が気にいらないとう方向に話が逸れたのでそっちはコミットするなり勝手にしろといってるだけ

2024/12/09(月) 15:04:27.86

>大衆が望んでる機能

と言いながらそれを望んでいる人がどれくらいいるかというデータは示さない
「俺が望んでいるのだから皆望んでいるに決まってる!」と言ってるだけ

2024/12/09(月) 15:25:10.39

>>137
> それ以前の議論の回答はしてないぞ？
お前がそう思うのならそれでいいが、俺もお前の「パーミッションを保存しなかった理由の推定」には文句言ってないぞ

俺が突っ込んだのは、127で引用したとおり、
> それを思いついたやつは今までいない
なわけあるかボケ！であってね
というかむしろ、パーミッションも保存してくれると考える方が自然だ
既に言った通り、お前らはGitが正しいという前提で考えだすから話がおかしくなる

とはいえこの辺は本当に平行線なのでもういいよ
OSSなんてどれもマグマは溜まってる状態で、ある意味これが仕様だ

> 結果が全て(134)
これでいいよ

俺：いつか誰かが追加して、パーミッションも保存出来るようになるだろ
Git信者： Gitではパーミッションは保存されないのが正しいので、未来永劫この機能は付きません

で、どっちの予想が正しいか、結果で判断するのが正しい
そしてこれを現時点で結論づけるのは不可能なので、この話は終わりでいい

2024/12/09(月) 15:31:54.27

OSS なんて「仕様に文句言う暇があったら修正コード書け、コード書いてない時点で困ってない」と判断する修羅の世界
「その機能がない」＝「今まではそれを入れる理由はなかった」なんだよ
未来は知らん、困ってるやつが頑張れ

2024/12/09(月) 15:36:35.15

>>139
この先ずっと実装されないままでも「俺は正しい」と言い続けるわけだ

2024/12/09(月) 15:43:57.63

>>140
× > 今まではそれを入れる理由はなかった
○ 我慢出来る範囲だったので我慢してた (130で言ったとおり)

なんだよ
というかお前のOSS最強信仰がどこから来るのか分からんが、
Gitに限らず何であれ、或いはプロプライエタリでも、
「ここもうちょっとなんとかならんかったんか」とは感じるものだと思うのだがな

ただまあ、中には、現状をひたすら受け入れるタイプも居て、君がそうだというだけなのかもしれんが

2024/12/09(月) 15:52:55.63

>>140
おっとすまん、見落とした

> OSS なんて「仕様に文句言う暇があったら修正コード書け
OSSは主語が大きすぎるので『Gitは』ということにして欲しいが、実際Gitではそうなのだろう
仕様を軽視しすぎだからあんなコマンドの山になる
とはいえ、これに関しては作った奴がそうなんだし、気に入らなければ使うなにしかならないが

2024/12/09(月) 15:52:58.51

>>142
「我慢出来る範囲」を超えたのなら実装すればいい
グダグダ言うだけで実装しない・できない奴ばかりならこの先もずっと変わらない

2024/12/09(月) 16:40:26.01

我慢できてる時点で困ってないんだよ

俺の git には（俺にしか役に立たない）パッチがいくつも当たってるけど、git に限らず OSS ってそういうもんだろ
他にも同じ問題で困っている人がいたら公開して共有するし、そうじゃなきゃ自分専用で使えばいい

2024/12/09(月) 18:04:22.56

>>145
> 我慢できてる時点で困ってないんだよ
なるほどそういう考え方か、全く同意はしないが

俺は逆に、93-99の流れの時点で駄目だと思うけどな(＝困っていると判断する)
高い確率で、欲しい機能（または、あって当然と思ってる機能）が動かないから質問してるわけだし
手間を減らす為のツールなのに、手動で別スクリプト用意して管理が必要なのは、二度手間だし、アウトだよ
そして最初に仕様を練ってれば、つまり、
「本当にパーミッションは保存する必要ないのか？保存した場合に何か問題があるのか？」を熟慮してたら、回避出来た問題だという話さ
とはいえ、仕様を軽視する連中にはこの辺の話が全く通じないのもいつも通りではあるが

まあどこまで行っても平行線だし、合意する必要もないしで、もう終わりでいいよ
結果を待てばいい

2024/12/09(月) 18:22:17.32

>>146
>>141

2024/12/09(月) 18:28:39.87

>この話は終わりでいい
>もう終わりでいいよ

そう思うなら黙っていればいいのに

2024/12/09(月) 19:40:56.21

まだやってたんだ
なんでこんなことになってるんだ?

2024/12/09(月) 20:11:13.66

久しぶりに長文君 (https://mevius.5ch.net/test/read.cgi/tech/1668901194/) が帰ってきたからさ。

2024/12/09(月) 21:50:22.89

>>127
＞バックアップ程度で大半の人には十分だし、実際、デプロイしたらいきなり使える方が便利だろ

だったらgitじゃなくてバックアップツールを使えばいいのでは？
誰もお前にgit使えなんて頼んでないし

2024/12/10(火) 00:43:59.32

パーミッションも記録するようになったらなったで今度は誰かがACLも入れてくれと言い出す

2024/12/10(火) 08:19:56.89

>>152
プラグイン出来るようにすれば済む話

2024/12/10(火) 10:33:12.74

昔の状態を保存したい目的に使うのはバックアップツール、アーカイバとかでも良い

長文君といい今回といい、なんで git とかのバージョン・コントロール・ツールをバックアップと勘違いするやつが定期的に湧くんだろう？（同一人物が暴れてるだけ？）

このペンチでは釘が打てないと文句を言ってるレベルの無知さらけ出してるの気づいてないんだろか

2024/12/10(火) 11:39:48.78

>>154
そこが疑問になるのは、お前に一般化能力が全く足りないからだな

まあGit自体に一般化能力が皆無だから、Gitに不満がない奴等は一般化能力もかなり低めで、
この意味ではGitは一般化能力の低い連中のエコーチェンバーになってる
このスレもそう
並の一般化能力があれば、あの全く整理されてないコマンドの山を見れば発狂する、俺がそうだ

して本題だが、単純にバックアップツール/アーカイバとしても使えるからだ
例えばtgzして毎日保存して、必要ならコメントも付けて、必要ないファイルは除外して、重複してる部分は圧縮して、検索機能も付けて、…
とかやりだすとほぼVCSになる
鯖なしで単体アプリとして使えるVCSで一番目に付くのはGitになる
バックアップ＝ブランチのない一本線コミット履歴、でしかないのでどのVCSも(一般人が期待する機能の)バックアップツール/アーカイバとしては使える
「別物」としてしか捉えられないのなら一般化能力が全く足りてない
(「勘違い」ではなく、分かってて「流用/転用」しようとしてるだけなのを、一般化能力が低すぎる故に理解出来ない)

Git信者風に言えば、「ぼくはいっぱんかのうりょくがかいむです」と言ってる事に気づいていないんだろうか、となる
ただなんつうか、この手の一々イヤミを言うのもお前らが嫌われてる理由だと思うんだけどさ
最後の文なんて意味不明な選民思想の露呈であって、しかも間違ってるしで、言わない方がましだよね
(まあリアルでは絶対に言わないがここは5chなので試しに言ってみる、というのならアリだが)

2024/12/10(火) 12:15:22.20

こいつの言ってるは「ペンチでも頑張ったら釘を打てるんだから、もっと釘打ち能力を強化しろ」ということだな
普通の人はペンチと金槌を使い分けるし、専門家なら用途ごとに複数のペンチや金槌を準備する
一つの道具で全部やろうとしてる時点でド素人だと気付けない病気かな？

2024/12/10(火) 12:26:57.55

言っていることはごもっともだが、一方で、ツール選定の際には使い慣れているものや既に運用されているものを優先するバイアスがあった方が効率的なのも事実だ
些細な課題に必要以上に固執してすぐに別のツールを使おうとするのも、それはそれで生産性を低下させる原因となる典型的な悪癖
もちろん上記のバイアスが強すぎるのも良くないけどね

2024/12/10(火) 12:28:35.11

双極性障害で、今が元気な期間で鬱に入ったら静かになるよ。

2024/12/10(火) 12:31:13.80

>>155
ブランチ使わねーとか、やっぱお前長文君だろ
開発どうなったんだ？
自分のスレに帰れ、完成まで戻って来んな

2024/12/10(火) 12:55:13.36

仮にパーミッション対応するにはどうしたらいいか、という生産的な議論はできんのか？

2024/12/10(火) 13:04:16.91

>>156
> 用途ごとに複数のペンチや金槌を準備する
ペンチや金槌ほど違いはないって事

ソフトウェア界隈でよく言われる、
「気に入らないからといってオレオレフレームワーク/ライブラリを作っても
どうせ９割は同じコードになるのだから、(＝車輪の再開発でしかないので)
多少気に入らなくとも既存のフレームワーク/ライブラリを使え、その方が生産性が断然高い」が該当する
俺はGitを気に入らないが、かといって自分で作ったとしても９割は同じコードになるので、
わざわざ作り直すよりはそのまま使って、本来のアプリケーション開発に注力する方が全体的にマシ、ということ
コマンドが糞の山だが、基本コマンド以外は使わなければいいだけではあるので
その他てんこ盛りの機能も同様

まあ俺的にはタイプスタンプを保存して欲しいんですけどね
理由は一番分かりやすいから
でもLinusは何か知らんがこれは絶対に認めないんだろうしね

2024/12/10(火) 13:15:59.11

gitも再発明だろ
お前はひたすらやらない理由を考えるタイプ

2024/12/10(火) 13:17:40.15

>>160
Gitでやるなら>>93-99
Gitを改造する気なら、commit時に何かしらのメタファイル(的なもの)を自動コミットしてしまって、
その中にパーミッションを記録しておき、戻すときに使えばいいだけ
まあ、やる気になればすぐ出来る問題だから、現時点で入ってないのは、

・本気で要らないと思ってる ← Git信者の予想
・まだブチ切れた奴が居ないだけ ← 俺の予想
・何かしらの理由で、政治的に拒否している ← Linusならあり得る

最後のは、例の発言
> マジで、Cを選択する理由が「何もなかった」としてもだ、C++プログラマー避けになるというだけで、Cを使う大義名分になる。
> https://cpplover.blogspot.com/2013/05/linus-torvalsc.html
なので、Git信者が喚き散らしてる「Gitをバックアップツールとして使わせない！！！」為に意図的にやってるってのは、
(半分ジョークだとしても、)Linusならあり得る

2024/12/10(火) 13:21:33.43

ファイルの中身の先頭にファイルそのものの属性情報を付けるという発想は、メインフレームなどの古い思想。

2024/12/10(火) 13:23:12.69

>>159
同意

長文君のスレ
日常の進捗履歴記録ツールWitBucket(仮称)検討中
https://mevius.5ch.net/test/read.cgi/tech/1668901194/

2024/12/10(火) 13:49:10.16

ごっみばけっつ君来てるのか
ばーじょん0.1でいいから早く成果物公開してや

2024/12/10(火) 14:56:53.30

長文君は問題外なので放っておくとして

unix 文化圏の KISS 原則というのは他の文化圏から来たやつには不思議でしょうがないんだろうな
Keep It Simple Stupid
「単純で馬鹿なままにしておけ＝余計なことはするな」

単純なものを組み合わせて何か複雑なものを作るのは簡単だけど、複雑なものを組み合わせるのは困難
お仕着せじゃなくて自分で工夫して何とかする人には元が単純であるほど良い

2024/12/10(火) 15:14:11.48

まあ使いやすくしたければ自分でツール作れば良いだけの話なのに何で作らないの？
必要なら作った方が効率がいいと思うんだけど。

2024/12/10(火) 16:47:08.21

元の質問者だけど、質問はただ出来るのかどうか聞いてただけなんだけどなあ
こうなって欲しいとかあるべきとか別に何とも思ってないんだが、なんで勝手に仮定してそんなに膨らませるんだろw
あとバックアップがどうのって言ってる人が最初の方からちらほらいるけど、バックアップの話ってどこから出してきたんだ?
誰もそんな話しとらんよね

2024/12/10(火) 17:00:49.95

Gitのことは嫌いでも、Linusのことは嫌いにならないでください！！

2024/12/10(火) 18:03:32.07

>>169
読んだら分かると思うけどこのスレには「git は初心者向けのバックアップ・ツールであるべき」というのが持論の変なやつが一人居着いていて定期的に湧くんだ
そして、ちょっとでもバックアップぽい使い方をしてるやつや初心者っぽい質問があると持論の補強に使おうとする

で、他の人がそれに反論したり予防するのが日常風景になってる
関係なければ軽く無視しても大丈夫だよ

2024/12/10(火) 18:45:20.68

>>167
GitはKISSとは真逆だけどな

>>169
手動でスクリプト書いてパーミッションを保存する気なのに、自分が使いたい機能と認識出来ないのは知障だろ

>>170
いやLinusの発言内容は大体同意だし、(163に挙げた物含めて)
ズバズバ言うところも割と俺は好きだけどな
もちろん会った事も話した事もないが

ただGitはなぁ…OSSの中でもここまで仕様がグダグダなのは存在しない
仕様を詰めるのは時間の無駄だ、として嫌う奴はいるが、大体そいつらはプログラミング初心者で、
Linusがこの辺理解出来無いとも思えないので、意図的に放置してる気もする
結果的にVCS界のmulticsになってるので、いつかunixが生まれる

ただまあ、使う分にはコマンドが多すぎても大して困らないんだよ、使わなければいいだけだから
しかしメンテするとなると、本来は全部のコマンドが正しく動く事をチェックしないといけないので、肥大化すると無理になってくる
Gitはこの辺、自動テストもする気無く、動かなければ動きませんね、文句があるならお前が直せ、でやってるように見える
また、勿論OSSなのでプロプライエタリと比べれば限界点は10～100倍上であり、
行けるところまで行ってしまえ、限界点のテストだ、という風にも取れる
この辺の思想が俺には合わないね、まあ他も多々あるが
だから、俺が参戦するとしたら、Gitではなく、unixを作る側だよ

2024/12/10(火) 21:54:47.54

そんなにGitが嫌なら使わなければいいのでは？
誰もお前にGit使えなんて言ってないでしょ

2024/12/10(火) 23:14:48.26

ゴミバケツ君また自分でVCS作る話してる。
前のはどうなったのか。

2024/12/11(水) 01:32:29.88

バージョン管理システムを変更履歴システムだと思い込んでいる人間は多いよなあ。

変更履歴用ならどこがどう変わったのかを表示する機能がないことに疑問を持たないのだろうか。

2024/12/11(水) 01:35:22.67

Linuxは開発者の質が低いんだよ
カーネルに次々と新しいバグを追加する

だからLinuxを採用するとカーネルを独自に直すという作業が必要になる

2024/12/11(水) 01:50:58.96

このスレ痛いやつ多いのな
↑とか

2024/12/11(水) 08:49:43.35

>>175
> 変更履歴用ならどこがどう変わったのかを表示する機能がないことに疑問を持たないのだろうか。
それはdiffで十分だし、しかもGitの場合はdiffを内包してしまってる（俺はこれにも反対)

だから不満があるとするならバイナリか？(Excel等を含む)
勿論これは対応してないだけだし、
また、対応するにしても、Gitが直接差分を出す「モノリシック」ではなく、
「プラグイン」で各社が自社アプリ用の差分出力ツールを供給出来る形態にするのが正しい

VCSから各種diffを直接出力すべきと考えるのは間違いだと思うぜ

>>176
そうだとしてもLinux以外にないわけだが、

> カーネルに次々と新しいバグを追加する
これはポリシーというか戦略が違ってて、「今より少しでも改善するなら採用」だからじゃないかと
従来型の「最低限のクオリティに達するまではreject」へのアンチテーゼでもあるから
そして(文句あるかもしれんが)カーネル開発者は元々のエンジニアの質がそこそこ高かったからそれでも何とかなったものの、
同じ事をGitでやったからあの「ぼくがおもいついたすごいこまんど」の山になったのだと思う
交通整理すらやる気無かったわけだ

とはいえ、「使われなくなったコマンドは、いつしか動かなくなった事すら認識されなくなり、死んでいく」という、
Gitコマンド内でのライフゲームをやるつもりなら、ありなんだろうさ
厳選されてるように思えるunixコマンドだって、レイヤーが1つ違うだけで同じライフゲーム状態だし

2024/12/11(水) 09:57:22.36

お前よりAIのほうが賢いんじゃね？
https://i.imgur.com/V1cME8T.png

2024/12/11(水) 12:19:18.72

git を始めとして最近のVCSは著者(author)とか承認者(commiter)とかの由来を管理するけど、所有者(owner)とか所属グループ(group)とかの現状は管理しない

管理の粒度もファイル単位ではなくて変更点単位

「バックアップ」という言葉の使い方次第だが次元の違うものを管理してるというのは最低限の事前知識

2024/12/11(水) 12:25:55.27

GitHubを容量無制限のファイルバックアップ置き場として紹介しているサイトもあるけどな

2024/12/11(水) 12:45:40.19

>>161
タイムスタンプがそうなっている理由はプログラマならわかるかと。

makeとかのビルドシステムがファイル更新をタイムスタンプで判定しているんだから、gitが書き換えるごとにタイムスタンプが新しくなるのはビルドシステムを考慮したら当然の話。
タイムスタンプを勝手に書き戻したら再現困難なバグになるから、採用は無いだろうね。

2024/12/11(水) 13:21:42.72

自分もタイムスタンプは戻してほしい派
その手のビルドツールって、なんで「タイムスタンプが古くなってても更新扱い」にしてくれないの？

2024/12/11(水) 13:29:52.53

1バイトも更新せずにタイムスタンプだけ更新したら、それも記録すんの？
そのタイムスタンプ更新の著作権は誰に所属するの？
コミッタはそれを確認して承認作業するの？
古いパッチの再利用したら日付が昔に戻るの？
ブランチ統合したらどっちの日付が採用されるの？

アホらし過ぎる議論
ファイルのバックアップは別に取れ

2024/12/11(水) 17:38:01.33

>>169
今話してるのは質問がGitをバックアップに使ってると勘違いしてる人たちだから無視していいよ
他の人は>>99でやりとりが終わってると分かってる

2024/12/11(水) 18:37:28.10

>>179
それは「現時点でもGitはバックアップツールとして十分使えます」と言ってるんだがお前はそれで良いのか？

>>182-183
つ make distclean

>>184
回答を期待してるわけではないだろうが、俺が今思いついた範囲なら、

1バイトも更新せずにタイムスタンプだけ更新したら、それも記録すんの？→古い日付のファイルに戻してからcommitしろ(或いは「内容が同一のファイルは非更新扱いにする」オプションをcommitコマンドに追加するからそれを使え)
そのタイムスタンプ更新の著作権は誰に所属するの？→上記なので関係なし
コミッタはそれを確認して承認作業するの？→同上
古いパッチの再利用したら日付が昔に戻るの？→パッチを当てた日になる、つまり戻らない
ブランチ統合したらどっちの日付が採用されるの？→マージ時に変更されたファイルはマージした日付になる

これで別段大して問題ない気がするが

まあ日付を保存する事について技術的問題はないと思うけど
Linusがわざわざ外したんだから、政治的な問題はあって、採用はされないんだろうけどさ
(全世界からメール等で連絡受けてたLinusは、テメエのローカルタイムなんて知るか！！！とブチ切れ、
タイプスタンプでの連絡が出来ないように作ったと予想)

が、多分根本は、形式主義者か現実主義者か、といったところか
形式主義者： GitはVCSであり、それ以外の使い方をしてはならない
現実主義者：機能が揃ってればラベルがどうであれ使う
　つまりGitもバックアップツールとして使えるし、
　GitHubは容量無制限のファイル置き場だし、
　git clone GitHubのURL: が現状一番簡単なデプロイ方法であるので、Gitはデプロイツールでもある
　(ただし目的外流用だから色々機能が揃ってないが、それでも他ツールよりマシなら使うだけ)

2024/12/11(水) 19:28:51.98

>>186
開発者に「俺達の利便性のために、お前らはチェックアウトするごとに手動でcleanして一からビルドしろ」と言ったらさすがに傲慢かと。

gitはプログラム開発者がソースコード管理のために用意したツールだから、開発者にとって百害あって一利無しの機能が入ることは無いんじゃないんかね。

2024/12/11(水) 20:38:24.90

>>182
Subversionには、ファイルのタイムスタンプをコミット日時にする設定はあるけどな
もちろん、makeを使うような人には危険な機能だが、それなりの要望はあったのだろう

2024/12/11(水) 20:46:11.17

>>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されるのは分かり切ってるのでやるならフォークしかない、といったところ

2024/12/11(水) 21:17:41.31

何も分かってないやつがいて草

タイムスタンプは過去には戻らない未来に進むだけ、という前提で多くのツールが設計されてる make もそう
この前提を壊さないように配慮することが大原則で git のみならず unix 系のツールは設計されてる
バックアップからの復元はこの前提を壊して過去に時間を戻す行為なので特別な時にのみ使うもの

2024/12/11(水) 21:35:45.41

>>190
zipやtarは普通にタイムスタンプは保存されるだろ
その延長で考えるなら、保存された方が自然だし有用だ、というだけ

ただまあ、これも合意する必要はない
フォークしてどちらがウケるかで決するフォーク主義が正しいし、ユーザーは好きな方使えば済むだけ
(現実的にはcp -p と同様にオプションで切り替えるのが普通で、
逆に言えばオプションすら存在しないGitは何らかの「意図」をもってそうしてるとも言える
理由は今のところ不明なので思いつく人はよろしく)

まあ心配せずとも、Linuxカーネルにコミットしてくる連中で、make clean を知らない奴なんて一人もいないよ
(だから多分問題はここではない)

2024/12/12(木) 00:21:35.10

git pull した後に make clean とか git 使ったことないのが丸わかりだな
何のための make だよ？

2024/12/12(木) 01:11:52.06

負け組のためのだろ

2024/12/12(木) 08:57:54.12

>>189
「俺はタイムスタンプの管理をgitでやりたいから、お前らはチェックアウトするごとにmake dustclean しろ」と言ったら、温厚になったLinusでもさすがに罵倒するかと。

gitはLinusがlinuxのソースコードを管理するために作ったツール。今もメインユーザーはLinux開発者で想定利用シーンもLinux開発なんだから、「Linux開発者の足を引っ張る機能」を追加するのはディレクターの正気を疑うレベルですな。

2024/12/12(木) 09:15:02.60

>>194
いや linux とか Linus とかもはや関係なく全プログラマー大爆笑案件だろ
git pull で同期したら日付が過去に戻りましたとか全員が git の使用やめるレベル

2024/12/12(木) 09:16:55.48

https://stackoverflow.com/questions/1964470/whats-the-equivalent-of-subversions-use-commit-times-for-git
PythonやPerlを使う人には、makeのためにタイムスタンプが失われるのはいい迷惑だと言われてるな

今さらリポジトリにメタデータを埋め込むのは難しいにしても、
gitconfigで>>188くらいさせてくれてもいいのにとは思う

2024/12/12(木) 15:16:51.62

>>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なら保存されるのか？なら俺はそれでもいいんだが
(料理の腕前で勝負してるのに、整理棚に必要以上にこだわっても本末転倒)

2024/12/12(木) 15:21:09.29

料理の腕前で勝負してるつもりならさっさとWitBucketとやらを作れよ

2024/12/12(木) 16:33:59.70

>>197
ChatGPTで3行に縮めて投稿しろ

2024/12/12(木) 18:58:50.56

>>197
>Linus以外はほぼやらねえし、

「gitはLinusがLinux開発で使うために作った」という大前提を忘れるのはアルツハイマー病の一種かしらん？

2024/12/14(土) 10:34:37.92

Gitの使い方というかSourcetreeの使い方というか質問があります

とある1コミットに複数ファイルがあって複数個所に変更がまたがってて
別ブランチにそのコミットの1ファイルの1部分だけをマージしたいです
その場合はチェリーピックは使えないので1部分のHunkをステージングに移動して
コミットするという方法が素直なマージ方法でしょうか？

2024/12/14(土) 11:43:48.24

>>201
採用元が push 後とか他人のコードだとそんな感じかな
私だと cherry-pick してから巻き戻し修正するけど、複数パッチなら rebase -i で edit を使う

採用元がローカルにしかない push 前なら元のコミットを分割しておくのが良い方法だろう
将来的に再利用するときにも別々に利用する可能性があるものは、今のうちに別パッチに分割しておくのが賢いと思う

2024/12/14(土) 11:54:03.74

>>202
回答ありがとうございます
まさに他人がプッシュしたものを派生ブランチにも適用させようとしています
その中に特定ブランチの対応分も混ぜてしまっていたため
どう対応すべきか質問した次第です
コミット分割は癖にしておきたいと思います

2024/12/14(土) 14:22:21.70

ろくに開発経験ないやつがgitの仕様はグダグダとか言ってるのまじで面白いな

2024/12/14(土) 19:07:11.21

>>93の質問以降まともだったのは96、97、99、101、107くらいしかいなかった
7bは置いとくとしても100レスも使ってこの体たらくとは情けない

2024/12/15(日) 22:01:21.97

>>178
diffでわざわざ比較するというのは時間の無駄

2024/12/15(日) 22:49:45.11

>>206
相手にすんな
バケツ君はマニュアル読めなくて git が外部 diff に対応してることすら見つけられずに俺の望む出力じゃないと散々暴れた過去がある、今もそう思い込んでるので

2024/12/15(日) 23:49:43.28

>>203
コミットの際にcherry-pickまで考慮するなんて不毛だからやめておいた方がいいよ
そんなことをしなければならないほど強くcherry-pickに依存したワークフローになっているならその方がよほど問題

2024/12/16(月) 00:02:22.98

不毛っていうのも程度問題でしょ
経験の浅いメンバーだと一つのコミットに複数のバグトラッカーのissueを混ぜこぜにすることがある
hot－fixブランチが必ずしも計画的に作られるとは限らないからcherry-pickで取り出したいことは時々起こる

2024/12/16(月) 12:28:18.00

cherry-pickに依存するのは不毛だと思うが、リモートへのコミットは機能単位・イシュー単位に整理した方がやり取り楽じゃない？

2024/12/16(月) 12:38:05.37

同じプロジェクト内に並行で製品(バージョン)を維持しているような場合には cherry-pick は多用するよ
特にブランチ切るまでもない単純な修正の場合とか

要はコミット1個だけのブランチの rebase/merge の簡略形なので不毛とか言うやつは単に経験が足りないだけ

2024/12/16(月) 12:42:21.10

せっかくbranch切ったのに、merge代わりにcherry-pickしたら後でトレース面倒にならん？

2024/12/16(月) 12:53:45.68

>>212
cherry-pick はブランチ切るまでもない修正用だよ
コミット1個ならどこから cherry-pick したか分かれば良いだけだし

2024/12/16(月) 13:11:10.31

今度はチェリーピックでやり合いか

2024/12/16(月) 13:17:14.68

将来どのコミットが急遽hotfixに採用されるか分からないからといってあらゆる事前の修正コミットをもしものためだけにブランチ分けするのもガチガチで作業効率が落ちる
程度問題と言った通り俺はcherry-pickを多用する気もないしフローとして禁止扱いも効率が悪いと思う
hotfixが必要ない現場なら必要になる機会は少ないだろうな

2024/12/16(月) 13:41:54.88

cherry-pick には複数の使いみちがあって別に全部の使い方しなければいけない訳ではないが色々知ってると便利

・最新版から過去リリースへのバックポート
・セキュリティなどの hotfix の適用
・テスト用の addhoc 修正版（正式なマージは今ではない
・ゴミ箱ブランチ等から拾ってコードの再利用（コードだけ拾ってコミットは再利用しない
など多数

「1つのコミットには1つの修正」という大原則を守ってさえいれば、cherry-pick に限らずあらゆる再利用や利用中止がやり易くなるといだけ

2024/12/16(月) 15:08:47.67

cherry-pickって言葉のニュアンスの通り

2024/12/16(月) 16:03:21.23

git の rebase と cherry-pick は同じ概念なので rebase とか使わない派閥のやつは cherry-pick も使わないだろうなあ
cherry-pick はブランチ切って rebase してブランチを消すを一発でやってくれるコマンド

正確には rebase の方が cherry-pick を繰り返した後にブランチ位置をそっちに切り替える機能というべきだけど

要はブランチを使うか使わないかの違い

2024/12/16(月) 22:52:09.15

すみません、チェリーピックに関して質問した者ですが
追加で質問よろしいでしょうか？

本流ブランチAから子ブランチBが作成されて
子ブランチBから一時的に孫ブランチCが作成されました
ブランチCで修正した一部コミットだけブランチBにチェリーピックしてマージして
他のコミットは無駄なのでブランチCがもはや不要となりました
孫ブランチCを削除してもブランチBにチェリーピックした内容は
削除される（元に戻される）ことはない認識で合っているでしょうか？

2024/12/16(月) 22:58:16.88

コミットの独立性が保たれているためチェリーピック元のブランチを
削除しても問題ないと認識しています

2024/12/17(火) 00:55:20.81

>>219
削除されないから大丈夫
まず第一に、残ったブランチやタグのいずれかから到達可能なコミットは生存し続ける
第二に、cherry-pickによって作られたコミットはマージと違って元のコミットとは別物の複製体になるので原本がどうなろうと知ったこっちゃない

2024/12/17(火) 07:53:20.59

>>221
ありがとうございます
Sourcetree独自の機能か分かりませんが
チェリーピック元のコミットIDをコメントに付与しているため
もう辿ることもないコミットならコメントから余計な情報は
省いた方がよさそうですね

2024/12/17(火) 09:46:53.70

>>222
それは git cherry-pick -x で付く情報だと思う
公開されないコミットへの参照は残さないほうがいいね

2024/12/17(火) 12:10:27.20

残ってても邪魔にはならないだろうけど cherry-pick 元がすぐ消える予定なら、付けないのが普通ですね

2024/12/17(火) 13:07:22.36

チェリーピックって童貞狩りじゃねえのか？

2024/12/17(火) 13:48:26.81

つまんな

2024/12/17(火) 14:02:58.22

cherry pick
1. 都合の良いものだけを (恣意的に) 選び出す
2. 慎重に必要なものを選別する
2. 好きなもののみを摘み食いする
4. バーゲン品から掘り出しものを漁る
5. 木から熟したサクランボだけをもぎ取る

5が本来の使われ方、1の意味で使われることが多い

2024/12/17(火) 22:22:58.48

コミットする内容を複数に分けたい場合、必要な部分だけステージングすると読んだのですが、
この機能を使っても作業フォルダの内容は変化しないので、
一緒にコミットするべきだったところを入れ忘れてしまい、
プルしても正しく動かない状態のものを上げてしまっていたということがあります

この一発勝負みたいなステージングの機能をみんな使いこなしているのでしょうか？

2024/12/17(火) 23:11:14.06

>>228
一発勝負っていう感覚はおかしいでしょう
一度ステージングした後やコミットした後でプッシュするまでもいくらでも再確認とやり直しのチャンスがある
危うい操作をしたのに十分に確認していない内容をプッシュしてしまう習慣のほうがどちらかというと諸悪の根源だと思う
SVNだってローカルの変更を部分的にコミットしようと思えば同じようなリスクがあるので、ステージングという考え方自体のリスクではない
分割してコミットはビルドの通らないコミットを作ってしまうリスクは増すから不慣れで自信のないオペレーションになったときはstashやswitchを活用して疎通確認しておくとか、要らん変更と意図的に残した変更と漏れた変更を混同しないようにassume-unchangedやskip-worktreeなんかを活用してもいい

2024/12/17(火) 23:14:08.08

>>228
複数のコミットで一つの修正になるならrebase してまとめたら？

2024/12/17(火) 23:25:32.69

>>228
問に回答してなかった
ステージングの機能を使いこなしているかはNoです
差分確認からコミットまでの流れはGUIのほうが好きなのでステージングは全然活用できてない

2024/12/17(火) 23:33:17.82

>>229
git status とかを頻繁に打つくせをつけた方が良いぞ、それでコミットし忘れ防げる（ついでによく使うオプションは alias にするとさらに良いぞ）
あと正しく動かないコミットに分割するのは「必要な部分だけ」とは言わないぞ

2024/12/17(火) 23:34:08.72

>>232
アンカミス >>228 あて

2024/12/18(水) 09:25:32.99

Git v2.48.0-rc0

2024/12/18(水) 11:41:14.09

>>228
もうでてるけど
いれないものはstashして動確してcommit
stagingの存在理由わかってくる

2024/12/19(木) 21:05:36.88

>>218
言うほど同じか？
rebaseを好む派閥がrebase使う最大のモチベーションはログの直線化
そういう神経質な連中がcherry-pickによる重複コミットの大量発生を許容するとは思えないのだが

2024/12/19(木) 21:38:31.24

やってることの内容は似てるけど用途が全然違うからなあ
かのPro Gitもリベースの章はベタ褒めでahhとかthe bliss of rebasingなどと顔もやや恍惚気味の御様子だが
チェリーピックとなると淡々とした説明で真顔だよ

2024/12/19(木) 23:45:56.41

>>236
目的じゃなくて動き(実装)の話
rebase で cherry-pick できるし
cherry-pick で rebase できる
どっちもコミットの再利用(付け先の変更)を目的とするコマンド
あと直線化にしか rebase 使わないと思ってるうちは git の実力が認識できてない

2024/12/20(金) 01:21:38.28

リポジトリを分けるか、モノでやるか
統合度合いが微妙な場合にものすごく悩む

2024/12/20(金) 09:56:06.03

そんなところで悩んでいる段階なら分けなくていいよ。最初から細かく分けようとするのは基本的に時間の無駄。
成功している組織はだいたいクソデカリポジトリなのも事実。それについては戦略としてモノレポが優れているというよりは結果的にそうなっただけだろうけど。

2024/12/20(金) 11:20:48.46

>>239
一般論にはメンバーで分けるとうまくいく事が多い
将来的に人が増えたり入れ替わっても同じ1つのグループで開発を続ける予定なら一緒にする、
対応するグループが分割されて片方だけに関わる人が出てきそう、もしくは不明なら別にしておく

2024/12/20(金) 12:26:56.43

「うまくいく」の定義によるかなあ
分かれている方が良いという前提のもとで失敗の可能性を下げるという意味では>>241に同意するが、
個人的には不適切な分割による失敗は幾度も見たことがあるが、逆に一緒であることの直接的な実害にはあまり遭遇した経験がない
巨大なモノリスへと誘導されやすいみたいなアーキテクチャに対する影響は否定しないが、そのへんは日常的なコーディング作業というより
もっと大きな視点で恣意的に判断すべきことかと思う
そして、その判断を今すべきか、そもそも可能なのかは冷静に考えた方がいい

2024/12/20(金) 12:53:34.97

>>242
・分かれてるものを一緒にするのはとても簡単だが、1つのものを分割するのはかなり手間がかかる
・単純なものどうしを組合わせるのは単純作業だが、複雑なものを組合わせるのは不可能な場合がある

という一般原則による、悩んだ時は原則に従うのがたいてい正しい

2024/12/21(土) 08:12:17.24

>>243
同様に、下記も言える
- 共通化されているものを個別化するのは簡単だが、個別化されているものを共通化するのは難しい
世の中そんなに単純じゃないんだわ

2024/12/21(土) 10:33:21.60

>>244
俺の書いた2つは、お前が書いた共通化の手間より断然難しいというのが一般的だと思うが、お前にとっては同レベルなんだろうなあ
まあ頑張れ

2024/12/21(土) 11:20:34.07

>>245
誤解させたようで申し訳ないが、単なるリポジトリの統合じゃなくてコードの共通化の話な
一般論として、集中管理は密結合を、分散管理は重複を招く
共通部分を介して密結合しているモジュール同士を切り離すには最悪共通部分をコピペすればよい
一方、分散管理され各所で個別化された重複を後から共通化する作業には、それほど自明な移行パスは存在しない
コードスタイルや設計の問題といえばそれだけだが、それはモノレポだって同じことだ

2024/12/21(土) 12:43:49.34

>>246
一般論だけどコードの共通化は難しくない
というのは必須ではないし時間の制限がないから
バラバラのまま結合して共通化できるところから時間をかけてゆっくり丁寧に共通部品に切り替えていけば良い

linux kernel とか部品の共通化に3年とか5年とかかけてゆっくりやってることも多い、共通化しないこともある
（手間だけの問題と技術的難易度の問題という本質的な部分の優先度を分けて考えると理解できると思うよ）

2024/12/21(土) 14:07:45.37

うーん、難しいと感じるかどうかはあなたの感性の問題だから、比較対象と根拠を示してね

2024/12/21(土) 17:31:11.06

>>248
感性の議論はしてないよ、お前がそう思ってるだけ

技術的にすぐに必要なものもと、条件によって無くてもすむし後回しにもできるものとを同次元で語るなって指摘なだけ
（後回しにして良いなら簡単、やらなくて済むのが一番簡単、という当たり前の指摘、感性の余地とかない）

2024/12/21(土) 18:23:30.51

>>249
読み返してみたけど>>244のツッコミがまとも
お前は自分の意見が一般的と言い張ってるだけ

2024/12/22(日) 11:25:46.33

>>229-235
みなさんご意見どうもです

SVNを使っていた頃や、ステージングを使ってみる前は、
変更ファイルをいったんどこかに逃がして、作業フォルダを綺麗な状態に戻して、
今回コミットしたいところだけくっつけ直して、動作確認できたらそれらをすべてコミットして、
逃がしておいたものを元の場所に戻して作業再開、みたいな操作をしてました

結局プッシュする前にステージングし忘れなどを確認する必要があるとなると、
コミット時に確実に確認できる上記の方法もそんなに悪くはないってことですかね

2024/12/22(日) 14:58:34.96

>>251
それで良いんじゃないかな？
私だと2つに分けたのを両方先にコミットしておいて、両方別々にチェックアウトしてテストを走らせるけど
問題があれば巻き戻してやり直し
問題がなけば push

push 前ならローカルでいくらでもやり直しが効くのが git の利点なので個人的に分かりやすいやり方でやれば良い
慣れたらテストの自動化とか検討すると捗る

2025/01/01(水) 05:03:32.91

Git v2.48.0-rc1

2025/01/07(火) 09:45:36.95

Git v2.48.0-rc2

2025/01/11(土) 11:00:17.95

Git v2.48.0

2025/01/12(日) 11:20:09.87

サル先生でGitの学習を始めました
そこで質問です！
下記コマンドの中に dewfr という記述が存在するのですが、これは何を意味するのでしょうか？

> git config --global core.editor "\"[使用するエディタのパス]\""dewfr

参照：https://backlog.com/ja/git-tutorial/intro/06/

2025/01/12(日) 12:11:34.88

先生が個人的に使っているエディタのファイル名なのでは？
直前がパス区切り文字で終わってるし

2025/01/12(日) 12:24:19.20

あ～なるほど！謎が解けました！
ありがとうございます！

2025/01/12(日) 17:53:29.03

Git用GUIがなまじっか日本語化されていると、
求めているコマンドを探すときに面倒くさい

2025/01/12(日) 18:29:09.15

>>259
わかる

2025/01/12(日) 18:29:16.18

>>259
わかる

2025/01/15(水) 09:29:23.33

Git v2.48.1

2025/01/15(水) 14:32:20.61

Git for Windows 2.47.1(2)Latest

2025/01/15(水) 14:42:56.61

Git Credential Managerの脆弱性で
Git for Windows 2.47.1、2.46.2、2.45.2の各バージョンで差し替え
（日本時間2025-01-15 03:11）

2025/01/23(木) 09:18:49.62

ローカル上の作業ブランチで複数回コミットして、まだマージやプッシュをしたくない状態のとき、
ここでPCやSSDが壊れたら痛いのでローカルの内容をバックアップしておきたいとなったら、
どうやるのが常套手段なんでしょうか

2025/01/23(木) 09:22:23.44

個人作業用のブランチにpushすりゃいいじゃん

2025/01/23(木) 10:01:54.42

常套手段は知らんけど壊れることまで心配するならクラウドバックアップとRAIDじゃないの
手軽な手段ならpushとpush -fだな
-fで困る人いないでしょ

2025/01/23(木) 10:05:22.41

汚すことができないやむを得ない事情があるなら自由になる別のリモートを増やしてブランチをミラーリングしておく

2025/01/23(木) 10:42:03.41

>>265
・ディスクをレイドとかにして耐障害性を上げる
・ディスク／ファイルシステムのバックアップを取る
・バックアップ用の別のリモート・リポジトリにプッシュする
・共用リポジトリに別のブランチ名でプッシュしておく
どれでも好きなのをどうぞ
全部やれば完璧

（最後のなら簡単、運用ルール的にかぶらないブランチ名の付け方決めとくだけでOK、個人名_ブランチ名とか

2025/01/23(木) 12:27:44.30

>>266-269
参考になりました、ありがとうございます
.gitフォルダだけを圧縮して逃がしたりしていましたが、
自分しか使わない前提のブランチなら、リモートにプッシュしてしまってもよいものなのですね

2025/01/23(木) 12:36:39.07

>>270
チームでやってるならチームのルールを確認

2025/01/23(木) 12:54:07.03

>>270
git のブランチなんていくら push しても容量がそんなに増えるようなもんじゃないし、邪魔にもならないんで駄目って言われることはほぼないよ
フィルターしやすくしたり、名前かぶるの避けるためにブランチの命名規則だけは決めておくと良い
（方針によってはバックアップは別のリポジトリがあるからそっち使えって言われることはあるかもしれない

2025/01/23(木) 18:26:22.96

>>265
ローカルにスタッシュする or 専用ブランにコミットした上で、.git以下を適当にバックアップするんじゃないの？

リモートに個人的なブランチをpushするのは抵抗感があるなぁ。

2025/01/23(木) 18:36:02.43

>>273
>>270で書いたような、今自分がやっている方法と同じですね
Gitの使い方としてどうかと思っていたのですが、それも間違いではないのですか

2025/01/23(木) 19:41:26.62

>>274
大丈夫じゃない？
https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain

2025/01/24(金) 14:03:41.62

仕事でやってるならそれは個人的な作業ではないのだから堂々とリモートにpushすればよい
OSSならそもそもforkしてるだろうからリモートは元々自分専用

2025/01/25(土) 15:00:31.31

道具として異常

知恵遅れがしがみつく道具がgit

30 (ﾜｯﾁｮｲ d315-+m+E) · 2025/01/25(土) 17:08:54.33

じゃあ天才は何使ってんの

2025/01/25(土) 17:22:25.79

未だにsvnから移行できないじじいはいたな

2025/01/25(土) 17:57:50.21

better cvs として使ってます。本当にすみません。ブランチとか良く使わないです

**デフォルトの名無しさん** (JP 0Hb6-dNed) · 2025/01/26(日) 13:26:52.01

やっぱりVisual Source Safeが一番わかりやすくていいよね

2025/01/26(日) 16:30:13.37

Better CVSではないGitならではのやり方と言えるのなんて、
複数のリモートリポジトリ間でpullし合うような真に分散管理された伝統的なOSS開発スタイルくらいだろ
基本的に大半の人の使い方はBetter CVSの域を出ない
ローカルリポジトリがリモートリポジトリへの反映前のバッファとして使えて便利だな、という程度

2025/01/26(日) 16:51:43.41

↑中途半端にわかった気になってるじじい

2025/01/26(日) 17:14:21.11

>>282
もうちょっと上手に煽んないと乗れないぞ

そもそもこのスレに cvs 使ったことあるやつがどれだけいると思ってんだ
30年前のアプリ比較に出しても自分が年寄りと表明することにしか
まちもに cvs 使ってたやつなら、恥ずかしくこの書き込みできないんで、きちんと使ったことないのまでは分かるけど

30 (ﾜｯﾁｮｲ 7f3d-ImQ9) · 2025/01/26(日) 22:56:56.08

CVSなら知ってるよ
コンビニのことでしょ

2025/01/27(月) 23:35:25.04

>>284
40歳以上なら知っている

2025/01/28(火) 00:30:38.67

RCSの話をしたくなるね

2025/01/28(火) 06:16:26.21

VSSもかなりあとまで使っていたけどな
35歳以上なら知っていることが多い

2025/01/28(火) 12:37:10.14

いまでもVisualStudioのソースコード管理はVSSライクなのあるよね。
Gitも使えるけど。

開発の中心じゃないメンバーも使う仕様書管理とかだとそっちの方が
評判高いというか、Gitは使わないよなw

2025/01/28(火) 13:19:48.30

SVNも忘れないで

2025/01/28(火) 20:38:47.97

Gitを知ろう！昔のソース管理とGit

の絵を見るとGitって難しい事してるな、って思う。
逆に古いツールは複雑なマージ出来るんだっけ？と不安になる。

2025/01/29(水) 13:05:47.15

Gitはオープンソースのプロジェクトを分散管理するのが目的だろうから、
社内のソース管理とかに使うと、なんか前より面倒くさくなったなと感じる

2025/01/29(水) 13:38:14.63

>>292
git は world wide にユニークな名前で管理して無限（おおげさな表現）にスケールすることが利点の1つなので
少人数のプロジェクトだとこの利点は感じ難いのは仕方ない、あらゆる利点は逆からみれば欠点なわけだし

2025/01/29(水) 13:41:47.19

git の他の利点、例えばブランチを切ったり繋いだりするのが早くて操作も簡単
みたいなのに慣れてくると個人利用のみでも手放せなくなる

2025/01/29(水) 15:51:35.40

正直、ローカルリポジトリを持たずに直接GitHubにコミットできるオプションがあったら便利だと思う
クライアントとサーバーが等価なのがアーキテクチャとして美しいのはわかるけど、
安定したネットワーク環境とリモートへの反映が前提なら実用的にはあまり意味ないのよね
余計な手間が増えるだけだし、作業者マインドの人(情シスとか情シスとか)に理解させるのに苦労する

2025/01/29(水) 16:45:51.30

なるほど、必要なら作ってくれ

2025/01/29(水) 17:08:05.77

最近のGitHubはweb上で編集してプルリク投げまで完結できたよね？
あんまし使ったことないけど

2025/01/29(水) 17:26:33.12

会社ではプッシュばっかり使っててプルリクの概念がいまだによくわかってない

このブランチをプルしてマージしてくださいってお願いするのがプルリクなんだよね？
会社でこれをやるなら、ソース管理者みたいな人を立ててその人に依頼すんの？

2025/01/29(水) 18:19:19.91

君のチームのワークフローに合わせればいい。Gitだからどうとかじゃなく。
考え方は簡単、他者の承認またはレビューを必要とするときに pull request を作る、承認したらマージする、これだけ。
例えばタスク毎にメイン開発者AとレビュワーBがアサインされていて、リリースにオーナーCの承認を必要とするなら、下記が考えられる。
開発タスクのクローズ : AがタスクのブランチからmainブランチへのPRを作成し、Bにレビューを依頼。BがPRを承認し、AまたはBがマージ。
リリース : 開発チームの誰かが main から production ブランチへのPRを作成し、Cがマージ。その後GitHub Actions等のCI/CDツールが本番環境へデプロイする。
上記はよくある流れではあるが、GitやGitHubだからこうするというわけではないことに留意せよ。
開発フローはそれらとは独立に決められるべきであり、それをGitHubの機能を使って実装するだけだ。

2025/01/29(水) 19:20:58.17

>>298
ワークフロー次第だが、もともと想定されてるのは
個人用公開リポジトリ ←push― 個人用ローカルリポジトリ ←commit― 作業ディレクトリ
という環境を全員が持ってる前提で

プルリクエストというのは、「俺の公開リポジトリに push したので、そこからお前のリポジトリに pull してくれ」という要求

これを責任者宛に出せば
チームリーダーとかリリース・マネージャーとかの責任者がチェックして問題なければ、それを彼の個人ローカル・リポジトリでマージする（その後に彼の公開リポジトリに push して公開する）

2025/01/29(水) 21:57:23.24

企業での開発においては共通のリポジトリを皆で触るのが一般的であり、”pull” requestは実際には同一リポジトリ内でのマージのみに使用する
forkはガバナンスを困難にし情報漏洩につながるリスクがあるため、そもそもorganizationまたはenterpriseのポリシーで一律禁止するのがベストプラクティス

2025/01/30(木) 01:09:50.68

GitLabだとマージリクエストって名前なんだけど、個人的にはこっちの名の方がしっくり来るんだよなあ

2025/01/30(木) 01:12:38.22

プルだと向こうが主語だもんな
引っ張ってぇ、的な

2025/01/30(木) 08:03:04.92

リクエストだから向こうが主語だよ
何いってんのさ

どちらも依頼だけど取り込む段階に着目するかマージする段階に着目するかの違いだよ

2025/01/30(木) 08:48:49.49

pull ってのは「fetch して merge 」の省略形なので当然 merge もリクエストしてる
分散リポジトリなら先に merge の前に fetch してもらう必要があるので pull リクエストを出す
共用リポジトリとかなら fetch する必要がないので単なる merge リクエストを出す

この違いが分かって使い分けできないやつが git 使ってるの爆笑ものなんだが
ここは分かってないやつ多そうだな

2025/01/30(木) 10:31:13.18

企業内での開発の場合、pull(merge) requestは要請というよりレビューと承認を求める意味合いが強い。
結局マージを行うのも同じ人(別の人間かもしれないが基本的には同一の責任主体と見做せる)であることがほとんどだから。
その意味ではシンプルに review request

2025/01/30(木) 10:47:11.99

企業内での開発の場合、pull(merge) requestはコードレビューと承認を得ることを目的に作成され、その上でマージを誰が行うかは重要ではないんだよね。
というか多くのチームでは作成した本人がマージしている。
このへんの用語は実際初心者に教えてると理解しづらいようで、pullじゃなくてmergeにしたら解決というものでもない。
まあ、だからってもっと良い呼称は俺は思いつかないが。

**307** (ﾍﾞｰｲﾓ MM06-zT4W) · 2025/01/30(木) 10:52:20.88

すまん、>>306は誤って書き込んだ。

2025/01/30(木) 11:21:31.02

>>305
じゃあなんでGitLabはプルリクエストじゃなくてマージリクエストなの？
GitLabユーザーはfetchなんてしないのかしら？

2025/01/30(木) 15:36:37.44

しない。したとしても極めて稀。
OSS開発者のためのソーシャルコーディングサービスとして開発されたGitHubと異なり、
GitLabは当初からエンタープライズでのクローズドな開発を前提としており、>>301の通り基本的に共有リポジトリを使うから。

2025/01/30(木) 16:07:15.77

>>307
それはちょっと違う
本来は review とかが全部終わった完成したものについて出すのが merge/pull リクエスト
review する人と merge する人が一緒の時に手抜きで一回で済ますだけでワークフロー上は完全に別物

2025/01/30(木) 16:38:36.48

>>311
使ったことがあるとは思えん
pull requestに対するレビュー結果の追加とマージの実行は別の操作だぞ

2025/01/30(木) 16:53:48.01

盛り上がってまいりました

2025/01/30(木) 17:25:50.04

>>309
>>311
github は分散リポジトリを念頭にサーバ上の統合作業の用語を選択した
gitlab は共用リポジトリを念頭にサーバ上の統合作業の用語を選択した

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

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

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

2025/01/30(木) 21:25:55.92

fetchしないってかなり語弊があるよな

2025/01/31(金) 09:01:26.86

>>314
で、あんたは>>298が会社でGitHubのpull requestを活用するにあたってLinuxカーネルと同様のMLベースのプロセスを導入すべきだと言いたいのか？
でないならその情報は質問者にとってたんなるのいずだ

2025/01/31(金) 09:31:32.44

>>316
ここは GitHub スレではなくて git スレだ
git 本来の用法と用語があるんだ
GitHub の勝手用語を前提にしていない

2025/01/31(金) 10:15:03.05

>>316
> あんたはGitHubのpull requestを活用するにあって

俺に聞いてる？俺のアドバイスなら
git 本来の pull request は業務フローによって必要だったり不要だったりする、参考に知っておくと良い
Github の pull request は使う必要も学ぶ必要もないゴミ、そのまま忘れてしまって良い、周りで使おうとするやついたら全力で止めるレベル

2025/02/05(水) 14:37:49.09

fork して勝手に成長させて fork 側が立派に育ったら
pull request なんてしなくても勝手に pull してくれるのが理想

2025/02/06(木) 01:42:29.43

>>319
いつ、誰が、何のために、どこから、どこへ pull すべきか指定するのが pull request なんだが
超絶AIでも開発してタイミングや理由を説明するのか？誰がはどうする？人間が AI から命令を受け取るのか？責任者不明のコミットができる GitHub状態なのか？

楽し過ぎるな。それやるくらいなら多分AIに全部のプログラム書かせた方が早いと思うぞ

2025/02/08(土) 21:27:04.90

また説教おじさん

2025/02/12(水) 02:05:12.31

git stashで、新規のファイルも一時退避したいのですが、デフォだと無視されるようですね
何か方法はないでしょうか
ま、新規ファイルはgitに未登録だから放置プレイせよ、ということなのかもしれませんが
なんとなくスッキリしないというか

2025/02/12(水) 02:14:56.55

git add -A してから git stash

2025/02/12(水) 02:20:20.50

-u
こんなとこ書き込む暇あったらググるかAIに聞け

2025/02/13(木) 23:46:41.27

スレ過疎ってるんだからええやん別に

2025/02/14(金) 12:09:29.98

2月寒いなあ、まだ冬型続くのかな？
みたいな質問するのは挨拶、話題作り、ネタ提供で雑談のきっかけにしたいだけなのに
「そんなのはググって気象庁のサイトを調べろ」とか言われちゃう感じだよねw

2025/02/14(金) 12:41:44.04

>>326
みんなの集まる会議の席上で天気の質問とか始めたら、「さっさと始めろ、他人の時間を無駄にするな」って怒られるだろ
個人の雑談と、多数が集まる場所での発言は違うんじゃないかな？
他人の時間を無駄にしないために自分で調べられることは調べた上で、分からない部分があったら質問するのが人としての礼儀

2025/02/14(金) 12:57:41.89

はたから見た感想
質問者の「ま、～というか」っていう余計なくだりを書かなければ余計な苦言も返されなかったかもと思った

2025/02/15(土) 00:32:15.20

>>327
このスレに多数の人が集まってるって言えるの？

2025/02/15(土) 01:49:01.01

>>329
俺とお前の二人きりでないのは確実だ

2025/02/15(土) 05:04:09.56

>>330
俺とお前と大五郎

2025/02/16(日) 12:05:30.15

点呼始めると急に人減るからな