24/02/15 09:51:51.51 En27mXas0.net
Git v2.43.2
3:デフォルトの名無しさん
24/02/15 09:52:26.08 En27mXas0.net
Git v2.44.0-rc1
4:デフォルトの名無しさん
24/02/16 06:57:49.65 3lLCm//O0.net
おつ
5:デフォルトの名無しさん
24/02/17 19:03:18.67 VE5laxOTr.net
detached HEAD で血の気が引いた。
元 hg 使いを殺しにきてるな。
6:デフォルトの名無しさん
24/02/18 02:02:20.81 P26dtCCm0.net
もじら関連に関わるような変人以外にそんなの使ってる奴いるのか?
7:デフォルトの名無しさん
24/03/05 17:05:16.75 c+BFiEzX0.net
TortoiseGitって、メッセージは空っぽのままで注釈付きのタグを作ることはできないですか？
8:デフォルトの名無しさん
24/04/20 12:34:00.49 GOMzeOKz0.net
Git v2.45.0-rc0
9:デフォルトの名無しさん
24/04/25 02:14:05.69 4GHeItIg0.net
Git v2.45.0-rc1
10:デフォルトの名無しさん (ﾜｯﾁｮｲ 6746-Ze2d)
24/04/30 14:07:17.09 i3NNFd3f0.net
Git v2.45.0
11:デフォルトの名無しさん
24/05/15 11:31:23.32 zu9CIopY0.net
Git v2.45.1 security fix
12:デフォルトの名無しさん
24/06/01 19:00:39.64 vNaK5R7G0.net
Git v2.45.2
13:デフォルトの名無しさん (ﾜｯﾁｮｲ b97a-2VwX)
24/07/21 11:47:12.83 uaIeFkRo0.net
Git v2.46.0-rc1
14:デフォルトの名無しさん (ﾜｯﾁｮｲ b97a-2VwX)
24/07/21 11:58:18.34 uaIeFkRo0.net
Git 2.46-rc0 Continues Preparations For Switching To SHA256 By Default WIth Git 3.0
URLﾘﾝｸ(www.phoronix.com)
15:デフォルトの名無しさん (ﾜｯﾁｮｲ b90e-VaLG)
24/07/25 08:10:54.69 zO+ibxLO0.net
Git v2.46.0-rc2
16:デフォルトの名無しさん (ﾜｯﾁｮｲ edb1-N8l3)
24/07/29 21:30:58.91 xsRUOsae0.net
すいません、質問です
とある組み込みLinuxのシステムをgit管理する事になりました
対象は/home/user1/の直下の3つのディレクトリです
この3つをディレクトリ構成を変えずに、同時にバージョン管理することは可能でしょうか？
17:デフォルトの名無しさん (JP 0H62-tcJ/)
24/07/30 06:35:24.67 Ci4KgBGjH.net
その3ディレクトリ以外は管理対象外にするような.gitignoreを書くだけでは
18:デフォルトの名無しさん (ﾜｯﾁｮｲ edb1-N8l3)
24/07/30 07:21:31.30 ObIFCuKO0.net
>>17
homeのユーザーディレクトリを丸ごとリポジトリにしてしまってもいいのでしょうか？
19:デフォルトの名無しさん (ﾜｯﾁｮｲ 55f5-awLC)
24/07/30 10:15:20.92 umN429bl0.net
Git v2.46.0
20:デフォルトの名無しさん (JP 0H62-tcJ/)
24/07/31 06:12:42.11 ZBVur2P4H.net
>>18
だってuser1直下のディレクトリ構成変えるのが嫌なんでしょ
乱暴だとは思うけど割り切ってこうするしかないよ？
21:デフォルトの名無しさん (ﾜｯﾁｮｲ edb1-N8l3)
24/07/31 18:41:12.02 YnwiDuLi0.net
>>20
ありがとうございます！
22:デフォルトの名無しさん (ﾜｯﾁｮｲ 17f4-Tlco)
24/09/15 02:31:26.93 7B8w2uuF0.net
Git v2.46.1
23:デフォルトの名無しさん
24/09/24 08:35:15.36 TlL47wZe0.net
Git v2.46.2
24:デフォルトの名無しさん (ﾜｯﾁｮｲ e310-Ptqa)
24/09/27 08:27:25.30 oB3iV6DX0.net
Git v2.47.0-rc0
25:デフォルトの名無しさん
24/10/04 12:52:23.68 uOoxCWIR0.net
Git v2.47.0-rc1
26:デフォルトの名無しさん
24/10/05 02:47:36.52 olKNfPvW0.net
Gitって、
ややこしいね…
27:デフォルトの名無しさん
24/10/06 21:10:55.65 LOiZtOL80.net
>>26
なにがややこしいの？
28:デフォルトの名無しさん
24/10/07 05:10:17.01 Sq2pzdgf0.net
>>27
gitkraken使えばいいのかな…？
29:デフォルトの名無しさん
24/10/08 09:22:58.42 tz5nAcm60.net
Git v2.47.0
30: 警備員[Lv.30] (ﾜｯﾁｮｲ e59c-7BmO)
24/10/23 15:25:36.90 ZjaTi5610.net
PCがブルスクになって再起動したら、.gitフォルダが全く認識されなくなったけど、これもう終わりかね
git initしてもダメだった
31:デフォルトの名無しさん
24/10/24 20:20:25.88 vCghfYJs0.net
なんか問題の切り分けできてなさそう
32:デフォルトの名無しさん
24/10/24 20:37:32.99 xUK0iCRk0.net
そりゃーいわね約束だべ
33:30
24/10/25 15:25:22.24 dMxrLshxr.net
もう終わった話なので大丈夫です
34:デフォルトの名無しさん
24/10/27 06:40:21.04 VfBaenuQ0.net
結局PCもgitも関係ないところのエラーだったんだろうな
35:デフォルトの名無しさん
24/10/29 16:36:54.68 XjCcoUqV0.net
今開発中の2.48は浜野氏がメンテナーをしていない模様
36:デフォルトの名無しさん
24/10/29 16:47:01.23 +tf01sQo0.net
GitHubとかのパブリックリポジトリをクローンしてログを見てみると、
ブランチを作らずに複数人がmainにばんばんコミットしてるものも多いんだけど、
ブランチを作る作らないはどういう基準で分けてるんだろうか
37:デフォルトの名無しさん
24/10/29 20:27:36.21 QsF0hADW0.net
>>36
ローカルにブランチ切ってるんじゃないの？
38:デフォルトの名無しさん
24/10/30 08:55:08.43 xBUuQciA0.net
>>37
どうやったらmainをこんな一直線にできるんでしょうか？
ローカルのブランチをmainにマージするときに、リベースとか使ってるってことですか？
39:デフォルトの名無しさん
24/10/30 09:28:31.83 AbuF7GMI0.net
>>38
当然 rebase するだろう
git なんのために使うと思ってるんだ
40:デフォルトの名無しさん
24/10/30 14:32:17.39 rt2JBnxr0.net
何より自称意識高い系対策だろ
41:デフォルトの名無しさん
24/10/31 12:54:50.89 POJr+rF8a.net
fork して branch してその branch を fork 元の main に対して pull request
merge したら main に合流
じゃないの
42:デフォルトの名無しさん
24/10/31 13:39:31.30 UBOJ2e3A0.net
>>41
直前にもう一回 pull / rebase してから pull request しろや
メンテナに余計な手間かけさせるな
43:デフォルトの名無しさん
24/11/01 19:56:16.32 TgBKHsuNa.net
>>36 がブランチ無いって言うから解説してみたんだが
44:デフォルトの名無しさん
24/11/02 19:40:13.72 5OmbLV2R0.net
gitでファイルを管理したいです
というのも、あるide上で削除したファイルは完全削除になり、ゴミ箱に移動されません
またリドゥも出来ません
だから定期的にgitに保存して、そこから復元という形になるみたいです
しかし、例えば10秒に1回ファイル削除をした場合10秒ごとにリポジトリに保存しなければいけないのでしょうか
自動化はできそうですが、凄まじく面倒です
45:デフォルトの名無しさん
24/11/02 19:55:48.59 fimlNyEi0.net
何も難しくねーんだから自動化すれば良いだろ
凄まじく面倒なんて言い訳は頭が悪いことを自白しているようなもんだ
46:デフォルトの名無しさん (ﾜｯﾁｮｲ 71b8-jwtj)
24/11/03 05:29:56.13 3rcZcbik0.net
gitの用途間違えてるよ
高頻度で削除するようなファイルを復元したがるケースがまず不明
どのIDEでどんなプロジェクトをどう運用してるか説明したほうがいい
本当に実現したいことに対して手法が間違ってる気がする
47:デフォルトの名無しさん
24/11/06 12:12:04.99 spMsN6R20.net
Gitの使い方のルールが明文化されていない職場が増えた
48:デフォルトの名無しさん
24/11/06 15:17:18.19 wtWzgVpw0.net
>>47
どんなルール？
49:デフォルトの名無しさん
24/11/06 20:07:20.18 4GufIMK30.net
職場でのルールってことでしょ
Git自体にルールはないよ
50:デフォルトの名無しさん (ﾜｯﾁｮｲ b25c-xN5v)
24/11/07 08:56:52.06 JbCijT/T0.net
そりゃそうだろ何の話してると思ったの?w
51:デフォルトの名無しさん
24/11/07 23:37:53.08 Ivqaow380.net
>>44
そんなに頻繁にファイル消すてどういうプロジェクトなんだろう？
削除せずに、ゴミ箱的なフォルダに移動するとか、ファイルをリネームするとかで
どうにかならないの？
52:デフォルトの名無しさん
24/11/08 04:47:19.41 x510xVeP0.net
git は履歴保管箱じゃねーぞ
変更点の採用/不採用や再利用や順番の入れ替えなどをする道具だぞ
履歴の保管はそのための単なる手段だぞ
ファイル保管の道具と勘違いしてるやつが多過ぎる、特に他の VCS から移ってきたやつ
53:デフォルトの名無しさん
24/11/08 16:10:07.37 9cqAhTbE0.net
またお前か
54:デフォルトの名無しさん
24/11/08 18:49:52.14 y8v+DuF60.net
>>51
彼はIDEとGitの二重管理がしたいらしいが、二重管理そのものが良くないと教えてやってよ。
55:デフォルトの名無しさん
24/11/08 18:51:25.49 y8v+DuF60.net
>>52
それはGitではなく、GitHub、GitLabなどのGitのホスティングサービスのことだ。
56:デフォルトの名無しさん
24/11/09 11:14:39.71 /e9Pqeqm0.net
チェックインチェックアウト型の方が合う職場の方が多いけどgit原理主義者がジャマをする
57:デフォルトの名無しさん (ﾜｯﾁｮｲ ad6e-xvOx)
24/11/10 23:26:27.94 7LupYrhE0.net
ファイルを弄ろうとした瞬間にダイアログが自動で開いて
お前は一体何のためにこのファイルを編集しようとしているんだ？
と意図を聞いてくるようなguiのgitクライアントやエディタってないの？
コミット時のコメントを先に書くようなの
58:デフォルトの名無しさん
24/11/13 18:08:56.60 LKqY2Vyg0.net
それ必要ある？
煩わしいだけだよね
59:デフォルトの名無しさん
24/11/14 16:08:53.18 owZ2H+n10.net
やることを明確にしてから手を動かす癖をつけるには悪くないアイデアだと思う
しかし強制力がないと結局煩わしいだけで終わりそうだから、宣言した内容から逸れるような変更をAIが検知して電気ショックを与えるような仕組みとセットだな
60:デフォルトの名無しさん
24/11/14 17:05:51.92 rZHGzr+/0.net
基本的に git はコードを書いてから、それをどのように他人に見せるか考える仕組み
最初に目的を書くとか git ではありえない
他の VCS 使え、無理して git を使う必要ないぞ
ステージが何のためにあるのか分かんない奴、ステージの便利さが分かんない奴は他のを使った方が幸せだと思うぞ
61:デフォルトの名無しさん
24/11/14 18:05:15.86 QfnZRB7z0.net
そりゃ暴論だな
Git自体は開発ワークフローではなくソースコードを管理するツールだから、UNIX的ミニマリズムの帰結でそうなってるだけの話で、
開発ワークフローとして先にコミットメッセージを決めちゃいけないわけではない
そういうワークフローをサポートする周辺ツールを作ればいいだけのことで、それを妨げるものは何もない
62:デフォルトの名無しさん
24/11/14 18:59:29.63 1DNjm3wn0.net
なんかGitと関係ない気がする
63:デフォルトの名無しさん
24/11/14 19:39:03.69 JxemxwF40.net
GitにはSVNのneeds-lockに相当するものはない
開発のスループットを上げるためにロックの考えは省いて競合解決はなるべく機械に頼る
そのあたりの思想やポリシーはリーナスが語ってたはず
彼が自分のために作ったツールだからそのあたり色濃くコマンドに現れてる
だがフロントエンドの開発を妨げるものはなにもない
必要だと思ったやつが自分で作ればいい
Git自身の思想とは別ベクトルを向いているので特殊でマイナーな用途のうちに入るから巷で誰かが公開してくれている可能性は低いかもしれないな
64:デフォルトの名無しさん (ﾜｯﾁｮｲ e378-QmVt)
24/11/14 19:59:56.31 knCj/+H40.net
急にどうした
65:デフォルトの名無しさん
24/11/14 20:17:06.85 rZHGzr+/0.net
git の思想合わないのなら git以外を使えば良いのになんで git にこだわるんだろ
git は汎用ニュートラルなツールじゃなくて思想性の強いクセがあるツール、その分はまったら手放せなくなるけど
料理で言ったらカレー粉レベル、カレー味にしたくない時に使うのはお勧めできない
66:デフォルトの名無しさん (ﾜｯﾁｮｲ e3dd-R46Z)
24/11/14 21:23:12.93 5gfdBupH0.net
GitもSubversionも使い方は自由
67:デフォルトの名無しさん
24/11/16 11:27:19.19 mDoixnK70.net
思想性にクセの無い VCS なんてあるんかいな
68:デフォルトの名無しさん
24/11/16 14:54:04.41 ahS7aS5o0.net
>>67
ないよ、だから自分たちの手法/考えにあったやつを使うべき
有名だからといって git 向いてないやつが git 使うのは不幸になるだけ
git は素晴らしいツールだけど万人向けというわけではない
69:デフォルトの名無しさん
24/11/16 16:46:21.48 l/37O0wv0.net
>>67
何にだって濃淡はあるだろ
あるなしの二択でしか考えられない1ビット脳かよ
70:デフォルトの名無しさん
24/11/16 16:51:08.62 ahS7aS5o0.net
>>69
濃淡といっても濃いやつかすごく濃いやつかの違い
薄いやつは存在しない
もちろん自分の思想にあってれば空気みたいに感じて薄いと思うかもだが、他の人にとっては猛毒という個人差
71:デフォルトの名無しさん
24/11/16 17:05:38.74 l/37O0wv0.net
>>70
うん、だから >>63 はGitはかなり濃い目の部類って言ってるんだよ
72:デフォルトの名無しさん
24/11/17 11:09:45.68 1w/WFdpP0.net
いやわかるんだけどさ、適材適所にならずにgitが一番、git使うのが正しい、gitも使えないような奴ぁ、みたいにいらぬ波風を仕事で起こす迷惑な原理主義者が実際多いのよ
73:デフォルトの名無しさん
24/11/17 11:57:45.29 XBj9RB2E0.net
たかがソースコードのバージョン管理に適材適所とか多様性とか要らん
くだらん自転車置き場の議論で時間を無駄にするだけだから問答無用でgit一択でいい
ゲーム開発で巨大なアセットを管理する必要があるように管理対象の性質によって他を選ぶのは仕方ないが、
些細なワークフローの問題で他の選択肢を検討するべきではない
74:デフォルトの名無しさん
24/11/17 12:30:40.26 4bPBMVA80.net
>>73
git 使う理由を考えろ
お前みたいな変なのがいるから、git でロックしたいだの、事前にコミット・メッセージ入れたいだの的外れなこと言い出すやつが湧いくことになる
git 使うんなら git のワークフローになるし、他のワークフローにしたいのなら他の VCS 使うべき
（全部が一緒に見えるアホはどれ使っても駄目だが）
75:デフォルトの名無しさん
24/11/17 14:21:11.61 Mcc4e1u50.net
Gitのワークフローなんてものは無い
個人の小規模開発では、手元のフォルダ上でデフォルトブランチにコミットするだけの使い方も多い
GitHub使ったクローズドな組織での開発では単一のリモードリポジトリで作業する中央集権型のワークフローが普通だ
一方で、OSSではフォークして互いにpullし合うのが一般的だろう
素のGitにはレビューやコメントもなければCI/CDもなく、マージやデプロイを承認するような機能もない
それらはあくまでGitと直行するものとしてGitHubによって自然な形で実装されたものだ
GitはLinuxカーネル開発のワークフローを前提として設計されたものではあるがGitそれ自体はワークフロー中立であり、
多様な使い方を受容することがGitがこれだけ広く普及した大きな理由だ
76:デフォルトの名無しさん
24/11/17 15:03:16.35 GO7/5tRJ0.net
svnはバイナリも差分で保存してくれることは覚えといて損はないぜ
脳死でgit一択なんてこたーない
77:73
24/11/17 15:08:32.39 Mcc4e1u50.net
>>76
よく読んでくれ
俺は管理対象の性質に応じて選択することは否定していない
78:デフォルトの名無しさん
24/11/17 18:01:53.15 hkK5KPG+0.net
>>75
もっと大きな部分を考えろ
分散して手元で開発
複数の人が同じファイルを並行して作業
ロックを取らずにマージ時に調整
ステージングでパッチを読みやすく整形
リベースでチェインを整形
個別ロックのかわりにブランチを使う
みたいなのも全部ワークフローだ
git 使ってると当たり前過ぎて空気になってるだけ、中央集権とかだけがワークフローじゃない
79:デフォルトの名無しさん
24/11/17 18:22:05.70 hkK5KPG+0.net
Q. バッティングするといやなのでロック取りたいんだが
A. ブランチ切れ、自分専用ブランチならバッティングしない
Q. 作業開始前に今からする作業の説明保存したいんだが
A. ブランチ切ってブランチの説明を追加しろ
だいたい git のワークフローに適した代替のやり方がある
個人ごとで保管すべきものが何で、全員で共有すべきものは何か？ という根幹の考え方が VCS ごとに違っている
80:デフォルトの名無しさん
24/11/17 18:43:36.44 hbhRcMl00.net
だからそういう話だろ？
なんか勘違いをしているようだが、質問者はあくまでクライアントの話をしている
自分の手元で自分以外誰も見ないし触らないブランチでやる分にはロックしようと自由だ
81:デフォルトの名無しさん
24/11/17 19:09:27.90 hkK5KPG+0.net
>>80
ロックは自由だ
LとR間違ってないか？ 何のため誰のためのロックの話？
82:デフォルトの名無しさん
24/11/17 19:28:00.48 hbhRcMl00.net
だから>>57の通り、メッセージを先に書きたいだけでしょ
そもそもロックしたいとは言っていないが、実装するなら少なくとも手元のブランチに対する排他制御は必要だろうね
83:デフォルトの名無しさん
24/11/17 19:37:35.19 hbhRcMl00.net
いやブランチじゃなくてリポジトリに対しての排他制御が必要か
コミット前だからどうせブランチは切り替えられないもんね
補足すると、自分で重複して同じクライアントを起動することによる競合を防ぐことを目的とした、同一PC上の同一のクライアント自身に対する排他制御な
84:デフォルトの名無しさん
24/11/17 19:51:48.68 odgQ051H0.net
ソースコードの履歴管理上の排他制御とリポジトリ内部の整合性を保証するための排他制御がごっちゃになってない？
85:デフォルトの名無しさん
24/11/17 20:35:32.55 Jr+9HLroM.net
なんでGitはおかしな原理主義者出てきやすいのだろう？
そりゃGitの～を使えばできます、は事実ですだろう
でも無理してなんでもかんでもGitでやる必要ないよなあ
どうも原理主義者くんはこの用途はこっちのバージョン管理ツールが合ってる、と言われるとGitにはその機能がない、と責められているように聞こえるらしい
86:デフォルトの名無しさん
24/11/17 21:12:22.55 9BT2IQwv0.net
git 以前にプログラミング向いてないやつがいるな
「ローカルでエディットしてるファイルを排他したいだけなら VCS じゃなくてエディタのロックの仕事」
って言われたら顔真っ赤にして反論するんだろうか？
87:30
24/11/17 22:38:40.72 G7eUir2J0.net
git一択と言ってる奴いて草
これが原理主義か怖いねえ😱
88:デフォルトの名無しさん
24/11/18 23:21:35.04 cZsx9Sbk0.net
日本人はやたら正解があることにしたがるが、外国人は正解が複数存在するという考えだから発展する。
89:デフォルトの名無しさん
24/11/19 07:05:59.68 8dOnv38L0.net
>>85
> なんでGitはおかしな原理主義者出てきやすいのだろう？
馬鹿がイキるのに丁度良い複雑さだから
まともな人はコードに忙しくツールなんて出来るだけ疎かにするのもあって
90:デフォルトの名無しさん
24/11/19 17:13:14.46 ADRNByYj0.net
ゴミ箱くんが帰ってきたのか？
91:デフォルトの名無しさん
24/11/19 19:37:11.73 dPz/0I6b0.net
>>90
思い出した。
専用のスレッド作ってもらっていて、2022/11/20だ。あれから2年か。
92:デフォルトの名無しさん
24/11/25 16:12:49.15 dXKNZcvG0.net
Git v2.47.1
93:デフォルトの名無しさん
24/12/02 01:10:56.87 rhvdeBiud.net
ファイルのパーミッションって保存されないの?
94:デフォルトの名無しさん
24/12/02 09:32:52.91 9ZwZTn5W0.net
>>93
実行権限以外は管理されない、git は保存ツールやバックアップツールでなくてコラボツールなので読み書き権限の管理は不要
Windows 使いとかで実行権限がうまくいかない場合は core.filemode=true 設定とか、--chmod とオプションとかを使うと良い
95:デフォルトの名無しさん
24/12/03 09:10:05.62 6hEsCuOf0.net
>>93
なんかバックアップと勘違いしてる人多いよね。
複数のPCで使う前提なのにパーミッション管理して何したいの？って思う。
96:デフォルトの名無しさん
25/03/13 11:47:43.76 AvSsTnXYq
中学生カップ儿刺殺は盆暗議員どもが教育無償化だのほざいて税金もらいまくっていながら何イチャついてやがんだふ゛ち殺してやるって
いつものロクに支援されない氷河期世代の仕業だったが石破茂も親御さんが死んだら住む場所も大変になるからリスキリングがどうたら
氷河期世代は無能とか決めつけて自宅で大人しくさせてりゃいいものをJАLだのАNΑだのクソヘリだのクソセスナだのテロリストに閑静な
住宅地まて゛騷音まみれにさせて藪の中の蛇をつつき出してんだからあれこれ事件を起こすのは当然だわな２0２5年は氷河期蛇が暴れまわる年に
なること間違いなし大企業か゛無能集団でありながら年収１千万超なのは自民行政癒着による公共事業名目の補助金に日銀にまで金もらって
優越的地位の濫用と不正と犯罪で儲けてるからだからな例えばマネシタ電器とか企業とは無関係の個人が自宅で作ったソフトウェアを
著作権侵害のGｐL違反で繋ぎ合わせて小学生レベルのポンコツUIをちょこっと挿し込んでテレビやらに搭載して儲けてるだけなのが現実
航空燃料税リッタ１万圓にして最低所得保障する以外に有効な治安対策など存在しない
(rｅf.) ｔtрs://www.Call4.jp/info.php?tｙＰe=iΤems&id=I０000062
Тtps:／/hanｅda-ρrojecТ.jimdofreе.com/ , тtps:/／flight-rouＴе.com/
ttΡs：//n-souonhigaisosyoudan.amebaownd.Сom/
97:デフォルトの名無しさん
24/12/03 12:44:13.34 yqFxGGnO0.net
>>93
されないね 600の設定ファイルとかでよく出るGitのあるあるなんだけど設計思想なんでしょうがない
他のVCSには出来るものもあるんでそっちを検討するか、毎回シェルスクリプトを叩くか、置けるならGitのフックを使うか
それこそドットファイルの管理なんかでマージとかはあんまり考慮しなく出来るなら、rsyncみたいな世代バックアップのツール使ってもいいかも
98:デフォルトの名無しさん
24/12/03 16:09:40.34 OOgT5lr40.net
perforceは出来るけどまああれだしな
後はそれこそRCSくらいしか思い浮かばないけど他になんかあったっけ
99:デフォルトの名無しさん
24/12/03 17:16:17.61 vojirIcj0.net
>>98
昔は、
新しいのは考え方や目的が違う、ファイル単位で読み書き権限の管理とかしたかったら今まで通りRCSとかCVS使い続けろ
って言うのが常識だったんだが
100:デフォルトの名無しさん
24/12/03 23:07:05.89 bTlhOqOWd.net
>>97 >>98
なるほどありがとう
そういうことならスクリプトでやるかな
101:デフォルトの名無しさん
24/12/05 01:07:05.86 PwliRaIW0.net
>>93
それはOSが管理しているのであって、ファイルそのものにそういう情報があるわけではない。
102:デフォルトの名無しさん
24/12/05 09:32:47.93 BvdDuGAN0.net
んなこと言ったらファイル名もいらないって話になっちゃうぞ。
ファイル名はinodeではなくデータだとかいうツッコミは無しな。それこそファイルシステムの実装の都合に過ぎないんだから。
Gitがパーミッションを扱わないのはLinuxカーネル開発のソース管理においてそれを必要としないからで、それ以上のこじつけは必要ない。
103:デフォルトの名無しさん
24/12/05 14:04:38.28 pujK8SSF0.net
xlsxとかxmlとしてバージョン管理できないの？しなくて良いのかもしれんが
104:デフォルトの名無しさん
24/12/05 15:31:26.26 jrS77sb50.net
>>102
git 出てくる以前から svn とか他の分散型でも実行権限しか管理しないのが常識だったから linux kernel のせいにするのは間違い
105:デフォルトの名無しさん
24/12/05 19:17:01.43 xwxGapJaF.net
>>102
プレーンテキストにこのファイルの説明書が付いているという発想はなかなか思いつかないぞw
106:デフォルトの名無しさん
24/12/05 19:17:26.14 f+d6ZP2RM.net
>>102
プレーンテキストにこのファイルの説明書が付いているという発想はなかなか思いつかないぞw
107:デフォルトの名無しさん
24/12/05 19:19:57.44 f+d6ZP2RM.net
Windowsだってファイルにアクセス制御情報があるのではない。
DOSがディスクオペレーションシステムだと知っていれば、ファイルを管理しているのはOSで、ファイルがOSに指示しているという発想が出てくるはずがない。
108:デフォルトの名無しさん
24/12/05 20:15:24.74 3xJzv6vp0.net
（この流れ早く終わらないかなあ）
109:デフォルトの名無しさん
24/12/05 20:36:07.99 +3mg3S2k0.net
必要な機能が欠けている、という事でしかないのでは。
実行権限だけ管理するというのもチグハグだし。
>>102
> それ以上のこじつけは必要ない。
完全に同意。
Git信者はGit一神教徒だから、Gitは間違ってない、間違わない、という前提で話をするからおかしくなる。
本当に間違ってないのであれば、更新する必要がない。ある意味CやHTMLがこれに近い。
Gitはツギハギだらけなんだから、パーミッションも今後は保存されるようになる、それの方が便利だから、というだけでよいのでは。
110:デフォルトの名無しさん
24/12/05 20:59:18.56 jrS77sb50.net
>>109
逆に git しか使ったことないやつがこういう戯言言うよな
最近のメジャーな VCS は実行権限しか管理しないのが普通なのに git 特有の仕様だと思い込んでる。git 以前からなのに
111:デフォルトの名無しさん
24/12/05 21:27:58.46 mSFWhExMd.net
みなさんケンカはやめよう
112:デフォルトの名無しさん
24/12/05 22:57:49.39 i4nmZT4E0.net
しかし教科書ではきれいにブランチだのフィックスだのと理想的なバージョン
管理が語られるが、会社でそれなりの規模になってくるとユーザーもいろいろだし
MSオフィスファイルや画像やとファイルの種別も多いのでほんとカオス化するなあ
もうやだ
113:デフォルトの名無しさん
24/12/05 23:18:07.05 SPvCQMZG0.net
>>107
だからその理屈だとgitが実行権限やファイル名を扱えることを説明できないでしょ
Linuxでは実行権限はメタデータだし、ファイル名はファイルではなくディレクトリのデータだ
Windowsではファイル名はアクセス権限と同等のメタデータの一つだね
114:デフォルトの名無しさん
24/12/05 23:37:35.74 PwliRaIW0.net
>>113
それはGitの話ではなく、Gitの使い方の話だぜ？
115:デフォルトの名無しさん
24/12/05 23:38:42.52 PwliRaIW0.net
>>113
ファイル名がパス名なのはUNIXの話でLinux独自の考えじゃない
116:デフォルトの名無しさん
24/12/05 23:39:42.78 PwliRaIW0.net
>>113
「メタデータ」の意味を取り違えていますけど？
117:デフォルトの名無しさん
24/12/05 23:42:05.86 PwliRaIW0.net
このスレッドはLinuxにおけるGitのスレッドじゃねえのにな
118:デフォルトの名無しさん
24/12/06 09:03:40.82 fS/z7DY00.net
>>113
不毛だと思うが続けるつもりならシンボリックリンクを突いた方がいいのでは？
Gitに整合性なんて無いし、
Linusには不要だったから付いてないが、一般人には必要だから質問されるって事にしかならないと思うが
119:デフォルトの名無しさん
24/12/07 15:04:30.30 4vDr1gw70.net
必要ならそのツールを使えばいいだけ。
GITではそんな機能はないと言うだけのこと。
120:デフォルトの名無しさん
24/12/08 01:32:04.62 69SzSHkA0.net
随分ひどいが質の低いのが回答者側に回ってきてるのは悪いことなのかそれとも良いバロメータなのか
121:デフォルトの名無しさん
24/12/08 09:44:23.06 neBRud1Z0.net
昔から専門系の板は簡単そうに見える質問が来ると極端な知識マウントで自己重要感を補おうとする人が湧くよ
今風に言うと「完全に理解した」人々ってやつ
122:デフォルトの名無しさん
24/12/08 13:11:46.15 1OHrCiTu0.net
事故重要感って言葉初めて聞いた
123:デフォルトの名無しさん
24/12/08 14:49:01.54 VtvkCH1/a.net
検索したら出てきたから使っている人いるんだね。
自尊心と何が違うのかは知らんし、どうでもいいけど
124:デフォルトの名無しさん
24/12/09 08:29:12.66 oqd+iiqc0.net
他人の作ったツールでマウント取ろうとしてる時点で頭おかしいけどな
せめて「ぼくのすごいそふとうぇあ」でやれよと
(この意味ではQiitaは正しい)
それはさておき、
・実行環境の全てを保存したい→パーミッションも全部保持して欲しい
・ソースコードの変遷が辿れればいい→パーミッションは全部755でいい
実行権限のあり/なしで動作が変わるシェルスクリプトなんて普通作らんし、
(Git以前かららしいが)実行権限だけ保存するのはどういう理由なん？
125:デフォルトの名無しさん
24/12/09 08:58:03.97 4HU/GnaT0.net
>>124
多分だけど古くからの unix 文化の影響
ファイル所有者の読み書きの権限は無制限、ファイル所有者の実行権限は個々のファイルごとによって違うという使い方をするのが普通だった
分散型だと他人とかグループとかを管理する必要はない（そもそも所有者とか所有グループを管理してないので他人と所有者の区別がない）
結論として「実行権限」だけが残った
126:デフォルトの名無しさん
24/12/09 09:59:14.74 oqd+iiqc0.net
>>125
つまりデフォの644→手動で755に変更の履歴を残すのが目的だったと
なら750とか400とか使って真面目に管理してる連中には機能が足りないのだろうね
機能が足りないのなら追加すればいいだけの話
そこでGitは間違ってない、今後ともパーミッションが保存される事はない、他VCSもそうだし、とか考えるのは頭おかしいと思うぜ
127:デフォルトの名無しさん
24/12/09 10:54:51.44 4HU/GnaT0.net
>>126
そもそもバックアップはないのでファイルの所有者とかグループとかを保存管理してない
・つまり644だろうと666だろうと600だろうと違いがない、後ろの2つの数字は意味がない
・開発において所有者自身の読み書きを禁止する意味はない
という考えなので所有者の実行ビットのみくらうしか汎用的なユースケースが存在しない
みんなが役に立つ具体的な使い方思いつけば拡張されるかもしれないが、それを思いついたやつは今までいないので現状があると理解しろ
128:デフォルトの名無しさん
24/12/09 12:05:14.30 oqd+iiqc0.net
>>127
> それを思いついたやつは今までいないので現状があると理解しろ
それはお前が知らないだけ
ソースコード管理者≠実行者なのは普通にある
例えばapache等のWebサーバーはnobodyやothers等の低権限で動かすのが一般的だ
この場合は少なくとも自分とapacheの権限は独立して記録出来てないと不便だろ
そもそも今回の質問が発生するのも、また、
> 600の設定ファイルとかでよく出るGitのあるあるなんだけど設計思想なんでしょうがない (>>97)
あるあるになるのもみんなその機能を使いたいからだろ
> そもそもバックアップはないのでファイルの所有者とかグループとかを保存管理してない
バックアップ程度で大半の人には十分だし、実際、デプロイしたらいきなり使える方が便利だろ
これを言うとデプロイツールでもないと言い出すんだろうが、
いちいちパーミッションを設定するだけのスクリプトを書いたり、手動で走らせるのは全くの無駄だろ(>>97-100参考)
Git信者にはGitは間違ってない！としか思えないのだろうが、
俺は単純にパーミッションも保存すればもっと便利になるからそうすればいいだけだと考える
まあこの点は平行線なのでもういいが
とにかく今できないのは事実としてもね
というかね、このスレのGit信者にはパヨクや意識高い系馬鹿と同じ類の勘違いを感じる
「Gitではパーミッションは保存されないのが正しいのだ！だからお前らもGitの正しい使い方を学べ！」ではなく、
大衆が望んでる機能だし、今からでもパーミッションを保存するように改善すれば終わる話だと思うのだけどな
129:デフォルトの名無しさん
24/12/09 12:09:10.99 4HU/GnaT0.net
>>128
もしそう思うなら具体的なユースケースをつけてコミットしろ
みんなの役に立つと思われば採用されるだろう
お前の役にしか立たんと思われればフォークして勝手にやれと言われるだけ
結果が全て、お前の妄想はいらない
130:デフォルトの名無しさん
24/12/09 12:21:54.83 4HU/GnaT0.net
git に限らずオープンソースというのは実際に手を動かして実物で利便性を証明したものの集大成
誰もやらないのは、やる価値がないから（コストに見合わないと思うから）
怠慢だと思うならお前がやって証明しろ
131:デフォルトの名無しさん
24/12/09 13:27:52.18 oqd+iiqc0.net
>>129-130
長期的には俺がフォークするかもだが、今はやらないよ
誰かがフォークしてパーミッションも保存するバージョンを作ったら、そっちを使うけど
(同じスタンスの奴も多いはず。そもそもGit以前のLinusも同様だし)
というかそこでムキになる理由が分からんのよ
お前がGitの基本設計をしたわけではないのだから、お前が間違った事にはならないし、
必要な機能なのだから、最終的には実装されるだろうし、なら付ければいいだけだろ
現実的には99のように自分でスクリプト等を『余分に』整備して我慢してる人が大半で、
いつか誰かがブチ切れて実装されるのを待ってるだけだろ
OSSなんてそんなに大した物でもないよ
(Gitに限らず、どれもこれも結構ポンコツ)
なお俺がGitにコミットする事はないぞ。やるなら必ずフォークする
理由はコマンドをほぼ全部リストラしたいから
132:デフォルトの名無しさん
24/12/09 13:55:32.71 4HU/GnaT0.net
「何で？ 理由は？」ってお前が問うから
・unix の伝統的に必要性が低いから
・そのせいで今まで誰もやろとうとしなかったから
という今そうなってない理由を答えてやっただけ（理由を間違えてるなら指摘しろ
それがお前の需要を満たしてないと思うのならば、それは別問題、それはお前が変えろ
変えるのは自由、そっちは議論してない
133:デフォルトの名無しさん
24/12/09 14:08:27.99 oz7HR5eE0.net
バケツ君 再来?
134:デフォルトの名無しさん
24/12/09 14:14:55.04 oqd+iiqc0.net
>>132
お前らGit信者はOSSを勘違いしてて、
× OSSは自由に改変出来るので必要な機能は全て実装されている
○ OSSに実装されている機能は全て、
誰かがブチ切れて「こんなのやり続けるくらいなら俺が実装してやる！」となった結果であって、
当たり前だが不満は常に溜まった状態にあり、爆発ない限り何も改善しない
(不満があってブチ切れたとき、プロプライエタリでは使用を止めることしかできないが、
OSSなら自分で機能を付加するという選択肢もある、程度)
つまりGitに限らずOSSは完璧でもなく、足りない機能は普通にありまくりで、
Gitの場合はパーミッションがそうだ、というだけ
お前らがそこで、ムキー！！！ならお前が実装しろ！！！ってなるのも狂ってるよ
135:デフォルトの名無しさん
24/12/09 14:26:15.08 4HU/GnaT0.net
>>134
誰も git が完璧なんて言ってないが、今頃になって長文君論法は何故？
道具なので完璧である必要なんてそもそもない、自分が満足いく性能ならそれで良し
oss なんて情熱をもってそれを作る人がいるかとそれを使いたい人がいるかの論理積
存在しないのは作る人がいないか、使いたい人がいないかのどっちか
結果が全て、満足いかないなら、文句あったらお前が変えろの世界、それこそ気に要らなければ使わなくても良い
136:デフォルトの名無しさん
24/12/09 14:31:09.65 oz7HR5eE0.net
>>134
誰かが実装するまで不満は残ったままということだろ?
だから不満があるなら自分で実装すればいいと言われている
137:デフォルトの名無しさん
24/12/09 14:47:29.93 oqd+iiqc0.net
>>135
> 変えるのは自由、そっちは議論してない(131)
> 長文君論法は何故？(134)
それはお前がフォークしろ論法に逃げたから、俺はフォークしない理由を述べたまで
というか、元の話に戻すと、パーミッションが保存されない件について、
あるある質問者： 保存して欲しい、或いは保存されるのが当然だと思ってたのに…
俺： 機能の不備で、いつか追加されるだろ
Git信者： 保存されないのが仕様だし、正しい！文句あるならGitを使うな！
或いはフォークしろ！フォークもしないのに文句言うな！
であって、これはもう平行線だからいいと既に127で言ったろ
その後お前がフォークガー論法(128-129)で論点逸らししてきたから、
俺もちょっとつき合ってみたら、逆に俺が論点逸らしした風に装うのだからGit信者は頭おかしい
論点を逸らしたのはお前だぞ
(まあお前が議論慣れしてないだけかもしれんが)
とはいえこの話題についてはもう何も生産性無いし、やめでいいが
138:デフォルトの名無しさん
24/12/09 14:54:58.40 4HU/GnaT0.net
俺は 123 の最後にある「どういう理由？」に答えようとしただけで、それ以前の議論の回答はしてないぞ？
現状が気にいらないとう方向に話が逸れたのでそっちはコミットするなり勝手にしろといってるだけ
139:デフォルトの名無しさん
24/12/09 15:04:27.86 oz7HR5eE0.net
>大衆が望んでる機能
と言いながらそれを望んでいる人がどれくらいいるかというデータは示さない
「俺が望んでいるのだから皆望んでいるに決まってる!」と言ってるだけ
140:デフォルトの名無しさん
24/12/09 15:25:10.39 oqd+iiqc0.net
>>138
> それ以前の議論の回答はしてないぞ？
お前がそう思うのならそれでいいが、俺もお前の「パーミッションを保存しなかった理由の推定」には文句言ってないぞ
俺が突っ込んだのは、127で引用したとおり、
> それを思いついたやつは今までいない
なわけあるかボケ！であってね
というかむしろ、パーミッションも保存してくれると考える方が自然だ
既に言った通り、お前らはGitが正しいという前提で考えだすから話がおかしくなる
とはいえこの辺は本当に平行線なのでもういいよ
OSSなんてどれもマグマは溜まってる状態で、ある意味これが仕様だ
> 結果が全て(134)
これでいいよ
俺： いつか誰かが追加して、パーミッションも保存出来るようになるだろ
Git信者： Gitではパーミッションは保存されないのが正しいので、未来永劫この機能は付きません
で、どっちの予想が正しいか、結果で判断するのが正しい
そしてこれを現時点で結論づけるのは不可能なので、この話は終わりでいい
141:デフォルトの名無しさん
24/12/09 15:31:54.27 4HU/GnaT0.net
OSS なんて「仕様に文句言う暇があったら修正コード書け、コード書いてない時点で困ってない」と判断する修羅の世界
「その機能がない」＝「今まではそれを入れる理由はなかった」なんだよ
未来は知らん、困ってるやつが頑張れ
142:デフォルトの名無しさん
24/12/09 15:36:35.15 oz7HR5eE0.net
>>140
この先ずっと実装されないままでも「俺は正しい」と言い続けるわけだ
143:デフォルトの名無しさん
24/12/09 15:43:57.63 oqd+iiqc0.net
>>141
× > 今まではそれを入れる理由はなかった
○ 我慢出来る範囲だったので我慢してた (130で言ったとおり)
なんだよ
というかお前のOSS最強信仰がどこから来るのか分からんが、
Gitに限らず何であれ、或いはプロプライエタリでも、
「ここもうちょっとなんとかならんかったんか」とは感じるものだと思うのだがな
ただまあ、中には、現状をひたすら受け入れるタイプも居て、君がそうだというだけなのかもしれんが
144:デフォルトの名無しさん
24/12/09 15:52:55.63 oqd+iiqc0.net
>>141
おっとすまん、見落とした
> OSS なんて「仕様に文句言う暇があったら修正コード書け
OSSは主語が大きすぎるので『Gitは』ということにして欲しいが、実際Gitではそうなのだろう
仕様を軽視しすぎだからあんなコマンドの山になる
とはいえ、これに関しては作った奴がそうなんだし、気に入らなければ使うなにしかならないが
145:デフォルトの名無しさん
24/12/09 15:52:58.51 oz7HR5eE0.net
>>143
「我慢出来る範囲」を超えたのなら実装すればいい
グダグダ言うだけで実装しない・できない奴ばかりならこの先もずっと変わらない
146:デフォルトの名無しさん
24/12/09 16:40:26.01 4HU/GnaT0.net
我慢できてる時点で困ってないんだよ
俺の git には（俺にしか役に立たない）パッチがいくつも当たってるけど、git に限らず OSS ってそういうもんだろ
他にも同じ問題で困っている人がいたら公開して共有するし、そうじゃなきゃ自分専用で使えばいい
147:デフォルトの名無しさん
24/12/09 18:04:22.56 oqd+iiqc0.net
>>146
> 我慢できてる時点で困ってないんだよ
なるほどそういう考え方か、全く同意はしないが
俺は逆に、93-99の流れの時点で駄目だと思うけどな(＝困っていると判断する)
高い確率で、欲しい機能（または、あって当然と思ってる機能）が動かないから質問してるわけだし
手間を減らす為のツールなのに、手動で別スクリプト用意して管理が必要なのは、二度手間だし、アウトだよ
そして最初に仕様を練ってれば、つまり、
「本当にパーミッションは保存する必要ないのか？保存した場合に何か問題があるのか？」を熟慮してたら、回避出来た問題だという話さ
とはいえ、仕様を軽視する連中にはこの辺の話が全く通じないのもいつも通りではあるが
まあどこまで行っても平行線だし、合意する必要もないしで、もう終わりでいいよ
結果を待てばいい
148:デフォルトの名無しさん
24/12/09 18:22:17.32 oz7HR5eE0.net
>>147
>>142
149:デフォルトの名無しさん
24/12/09 18:28:39.87 oz7HR5eE0.net
>この話は終わりでいい
>もう終わりでいいよ
そう思うなら黙っていればいいのに
150:デフォルトの名無しさん
24/12/09 19:40:56.21 /rVJ/4Ts0.net
まだやってたんだ
なんでこんなことになってるんだ?
151:デフォルトの名無しさん
24/12/09 20:11:13.66 ZPo7jPZJ0.net
久しぶりに長文君 (ｽﾚﾘﾝｸ(tech板)) が帰ってきたからさ。
152:デフォルトの名無しさん
24/12/09 21:50:22.89 RQhO7hoM0.net
>>128
＞バックアップ程度で大半の人には十分だし、実際、デプロイしたらいきなり使える方が便利だろ
だったらgitじゃなくてバックアップツールを使えばいいのでは？
誰もお前にgit使えなんて頼んでないし
153:デフォルトの名無しさん
24/12/10 00:43:59.32 LZyb1uxu0.net
パーミッションも記録するようになったらなったで今度は誰かがACLも入れてくれと言い出す
154:デフォルトの名無しさん
24/12/10 08:19:56.89 iBb8Uq0X0.net
>>153
プラグイン出来るようにすれば済む話
155:デフォルトの名無しさん
24/12/10 10:33:12.74 sGQQlBSJ0.net
昔の状態を保存したい目的に使うのはバックアップツール、アーカイバとかでも良い
長文君といい今回といい、なんで git とかのバージョン・コントロール・ツールをバックアップと勘違いするやつが定期的に湧くんだろう？（同一人物が暴れてるだけ？）
このペンチでは釘が打てないと文句を言ってるレベルの無知さらけ出してるの気づいてないんだろか
156:デフォルトの名無しさん
24/12/10 11:39:48.78 iBb8Uq0X0.net
>>155
そこが疑問になるのは、お前に一般化能力が全く足りないからだな
まあGit自体に一般化能力が皆無だから、Gitに不満がない奴等は一般化能力もかなり低めで、
この意味ではGitは一般化能力の低い連中のエコーチェンバーになってる
このスレもそう
並の一般化能力があれば、あの全く整理されてないコマンドの山を見れば発狂する、俺がそうだ
して本題だが、単純にバックアップツール/アーカイバとしても使えるからだ
例えばtgzして毎日保存して、必要ならコメントも付けて、必要ないファイルは除外して、重複してる部分は圧縮して、検索機能も付けて、…
とかやりだすとほぼVCSになる
鯖なしで単体アプリとして使えるVCSで一番目に付くのはGitになる
バックアップ＝ブランチのない一本線コミット履歴、でしかないのでどのVCSも(一般人が期待する機能の)バックアップツール/アーカイバとしては使える
「別物」としてしか捉えられないのなら一般化能力が全く足りてない
(「勘違い」ではなく、分かってて「流用/転用」しようとしてるだけなのを、一般化能力が低すぎる故に理解出来ない)
Git信者風に言えば、「ぼくはいっぱんかのうりょくがかいむです」と言ってる事に気づいていないんだろうか、となる
ただなんつうか、この手の一々イヤミを言うのもお前らが嫌われてる理由だと思うんだけどさ
最後の文なんて意味不明な選民思想の露呈であって、しかも間違ってるしで、言わない方がましだよね
(まあリアルでは絶対に言わないがここは5chなので試しに言ってみる、というのならアリだが)
157:デフォルトの名無しさん
24/12/10 12:15:22.20 6HlM5sdR0.net
こいつの言ってるは「ペンチでも頑張ったら釘を打てるんだから、もっと釘打ち能力を強化しろ」ということだな
普通の人はペンチと金槌を使い分けるし、専門家なら用途ごとに複数のペンチや金槌を準備する
一つの道具で全部やろうとしてる時点でド素人だと気付けない病気かな？
158:デフォルトの名無しさん
24/12/10 12:26:57.55 ChjTkXcv0.net
言っていることはごもっともだが、一方で、ツール選定の際には使い慣れているものや既に運用されているものを優先するバイアスがあった方が効率的なのも事実だ
些細な課題に必要以上に固執してすぐに別のツールを使おうとするのも、それはそれで生産性を低下させる原因となる典型的な悪癖
もちろん上記のバイアスが強すぎるのも良くないけどね
159:デフォルトの名無しさん
24/12/10 12:28:35.11 nRxMArw0a.net
双極性障害で、今が元気な期間で鬱に入ったら静かになるよ。
160:デフォルトの名無しさん
24/12/10 12:31:13.80 sGQQlBSJ0.net
>>156
ブランチ使わねーとか、やっぱお前長文君だろ
開発どうなったんだ？
自分のスレに帰れ、完成まで戻って来んな
161:デフォルトの名無しさん
24/12/10 12:55:13.36 maUGvQsbM.net
仮にパーミッション対応するにはどうしたらいいか、という生産的な議論はできんのか？
162:デフォルトの名無しさん
24/12/10 13:04:16.91 iBb8Uq0X0.net
>>157
> 用途ごとに複数のペンチや金槌を準備する
ペンチや金槌ほど違いはないって事
ソフトウェア界隈でよく言われる、
「気に入らないからといってオレオレフレームワーク/ライブラリを作っても
どうせ９割は同じコードになるのだから、(＝車輪の再開発でしかないので)
多少気に入らなくとも既存のフレームワーク/ライブラリを使え、その方が生産性が断然高い」が該当する
俺はGitを気に入らないが、かといって自分で作ったとしても９割は同じコードになるので、
わざわざ作り直すよりはそのまま使って、本来のアプリケーション開発に注力する方が全体的にマシ、ということ
コマンドが糞の山だが、基本コマンド以外は使わなければいいだけではあるので
その他てんこ盛りの機能も同様
まあ俺的にはタイプスタンプを保存して欲しいんですけどね
理由は一番分かりやすいから
でもLinusは何か知らんがこれは絶対に認めないんだろうしね
163:デフォルトの名無しさん
24/12/10 13:15:59.11 maUGvQsbM.net
gitも再発明だろ
お前はひたすらやらない理由を考えるタイプ
164:デフォルトの名無しさん
24/12/10 13:17:40.15 iBb8Uq0X0.net
>>161
Gitでやるなら>>93-100
Gitを改造する気なら、commit時に何かしらのメタファイル(的なもの)を自動コミットしてしまって、
その中にパーミッションを記録しておき、戻すときに使えばいいだけ
まあ、やる気になればすぐ出来る問題だから、現時点で入ってないのは、
・本気で要らないと思ってる ← Git信者の予想
・まだブチ切れた奴が居ないだけ ← 俺の予想
・何かしらの理由で、政治的に拒否している ← Linusならあり得る
最後のは、例の発言
> マジで、Cを選択する理由が「何もなかった」としてもだ、C++プログラマー避けになるというだけで、Cを使う大義名分になる。
> URLﾘﾝｸ(cpplover.blogspot.com)
なので、Git信者が喚き散らしてる「Gitをバックアップツールとして使わせない！！！」為に意図的にやってるってのは、
(半分ジョークだとしても、)Linusならあり得る
165:デフォルトの名無しさん
24/12/10 13:21:33.43 1EevVDftM.net
ファイルの中身の先頭にファイルそのものの属性情報を付けるという発想は、メインフレームなどの古い思想。
166:デフォルトの名無しさん
24/12/10 13:23:12.69 0BGH+xex0.net
>>160
同意
長文君のスレ
日常の進捗履歴記録ツールWitBucket(仮称)検討中
ｽﾚﾘﾝｸ(tech板)
167:デフォルトの名無しさん
24/12/10 13:49:10.16 yCEb4nkG0.net
ごっみばけっつ君来てるのか
ばーじょん0.1でいいから早く成果物公開してや
168:デフォルトの名無しさん
24/12/10 14:56:53.30 sGQQlBSJ0.net
長文君は問題外なので放っておくとして
unix 文化圏の KISS 原則というのは他の文化圏から来たやつには不思議でしょうがないんだろうな
Keep It Simple Stupid
「単純で馬鹿なままにしておけ ＝ 余計なことはするな」
単純なものを組み合わせて何か複雑なものを作るのは簡単だけど、複雑なものを組み合わせるのは困難
お仕着せじゃなくて自分で工夫して何とかする人には元が単純であるほど良い
169:デフォルトの名無しさん
24/12/10 15:14:11.48 r7RcD6Xd0.net
まあ使いやすくしたければ自分でツール作れば良いだけの話なのに何で作らないの？
必要なら作った方が効率がいいと思うんだけど。
170:デフォルトの名無しさん
24/12/10 16:47:08.21 IViAh4+E0.net
元の質問者だけど、質問はただ出来るのかどうか聞いてただけなんだけどなあ
こうなって欲しいとかあるべきとか別に何とも思ってないんだが、なんで勝手に仮定してそんなに膨らませるんだろw
あとバックアップがどうのって言ってる人が最初の方からちらほらいるけど、バックアップの話ってどこから出してきたんだ?
誰もそんな話しとらんよね
171:デフォルトの名無しさん
24/12/10 17:00:49.95 nRxMArw0a.net
Gitのことは嫌いでも、Linusのことは嫌いにならないでください！！
172:デフォルトの名無しさん
24/12/10 18:03:32.07 6HlM5sdR0.net
>>170
読んだら分かると思うけどこのスレには「git は初心者向けのバックアップ・ツールであるべき」というのが持論の変なやつが一人居着いていて定期的に湧くんだ
そして、ちょっとでもバックアップぽい使い方をしてるやつや初心者っぽい質問があると持論の補強に使おうとする
で、他の人がそれに反論したり予防するのが日常風景になってる
関係なければ軽く無視しても大丈夫だよ
173:デフォルトの名無しさん
24/12/10 18:45:20.68 iBb8Uq0X0.net
>>168
GitはKISSとは真逆だけどな
>>170
手動でスクリプト書いてパーミッションを保存する気なのに、自分が使いたい機能と認識出来ないのは知障だろ
>>171
いやLinusの発言内容は大体同意だし、(163に挙げた物含めて)
ズバズバ言うところも割と俺は好きだけどな
もちろん会った事も話した事もないが
ただGitはなぁ…OSSの中でもここまで仕様がグダグダなのは存在しない
仕様を詰めるのは時間の無駄だ、として嫌う奴はいるが、大体そいつらはプログラミング初心者で、
Linusがこの辺理解出来無いとも思えないので、意図的に放置してる気もする
結果的にVCS界のmulticsになってるので、いつかunixが生まれる
ただまあ、使う分にはコマンドが多すぎても大して困らないんだよ、使わなければいいだけだから
しかしメンテするとなると、本来は全部のコマンドが正しく動く事をチェックしないといけないので、肥大化すると無理になってくる
Gitはこの辺、自動テストもする気無く、動かなければ動きませんね、文句があるならお前が直せ、でやってるように見える
また、勿論OSSなのでプロプライエタリと比べれば限界点は10～100倍上であり、
行けるところまで行ってしまえ、限界点のテストだ、という風にも取れる
この辺の思想が俺には合わないね、まあ他も多々あるが
だから、俺が参戦するとしたら、Gitではなく、unixを作る側だよ
174:デフォルトの名無しさん
24/12/10 21:54:47.54 KgYOToHf0.net
そんなにGitが嫌なら使わなければいいのでは？
誰もお前にGit使えなんて言ってないでしょ
175:デフォルトの名無しさん
24/12/10 23:14:48.26 cIogiqHs0.net
ゴミバケツ君また自分でVCS作る話してる。
前のはどうなったのか。
176:デフォルトの名無しさん
24/12/11 01:32:29.88 bYjfV/I80.net
バージョン管理システムを変更履歴システムだと思い込んでいる人間は多いよなあ。
変更履歴用ならどこがどう変わったのかを表示する機能がないことに疑問を持たないのだろうか。
177:デフォルトの名無しさん
24/12/11 01:35:22.67 bYjfV/I80.net
Linuxは開発者の質が低いんだよ
カーネルに次々と新しいバグを追加する
だからLinuxを採用するとカーネルを独自に直すという作業が必要になる
178:デフォルトの名無しさん
24/12/11 01:50:58.96 Y83IEE6u0.net
このスレ痛いやつ多いのな
↑とか
179:デフォルトの名無しさん
24/12/11 08:49:43.35 bZvW/lze0.net
>>176
> 変更履歴用ならどこがどう変わったのかを表示する機能がないことに疑問を持たないのだろうか。
それはdiffで十分だし、しかもGitの場合はdiffを内包してしまってる（俺はこれにも反対)
だから不満があるとするならバイナリか？(Excel等を含む)
勿論これは対応してないだけだし、
また、対応するにしても、Gitが直接差分を出す「モノリシック」ではなく、
「プラグイン」で各社が自社アプリ用の差分出力ツールを供給出来る形態にするのが正しい
VCSから各種diffを直接出力すべきと考えるのは間違いだと思うぜ
>>177
そうだとしてもLinux以外にないわけだが、
> カーネルに次々と新しいバグを追加する
これはポリシーというか戦略が違ってて、「今より少しでも改善するなら採用」だからじゃないかと
従来型の「最低限のクオリティに達するまではreject」へのアンチテーゼでもあるから
そして(文句あるかもしれんが)カーネル開発者は元々のエンジニアの質がそこそこ高かったからそれでも何とかなったものの、
同じ事をGitでやったからあの「ぼくがおもいついたすごいこまんど」の山になったのだと思う
交通整理すらやる気無かったわけだ
とはいえ、「使われなくなったコマンドは、いつしか動かなくなった事すら認識されなくなり、死んでいく」という、
Gitコマンド内でのライフゲームをやるつもりなら、ありなんだろうさ
厳選されてるように思えるunixコマンドだって、レイヤーが1つ違うだけで同じライフゲーム状態だし
180:デフォルトの名無しさん
24/12/11 09:57:22.36 34XO7K6O0.net
お前よりAIのほうが賢いんじゃね？
URLﾘﾝｸ(i.imgur.com)
181:デフォルトの名無しさん
24/12/11 12:19:18.72 +nAxu/ku0.net
git を始めとして最近のVCSは著者(author)とか承認者(commiter)とかの由来を管理するけど、所有者(owner)とか所属グループ(group)とかの現状は管理しない
管理の粒度もファイル単位ではなくて変更点単位
「バックアップ」という言葉の使い方次第だが次元の違うものを管理してるというのは最低限の事前知識
182:デフォルトの名無しさん
24/12/11 12:25:55.27 JMogi+gN0.net
GitHubを容量無制限のファイルバックアップ置き場として紹介しているサイトもあるけどな
183:デフォルトの名無しさん
24/12/11 12:45:40.19 kPp0f2Rs0.net
>>162
タイムスタンプがそうなっている理由はプログラマならわかるかと。
makeとかのビルドシステムがファイル更新をタイムスタンプで判定しているんだから、gitが書き換えるごとにタイムスタンプが新しくなるのはビルドシステムを考慮したら当然の話。
タイムスタンプを勝手に書き戻したら再現困難なバグになるから、採用は無いだろうね。
184:デフォルトの名無しさん
24/12/11 13:21:42.72 JMogi+gN0.net
自分もタイムスタンプは戻してほしい派
その手のビルドツールって、なんで「タイムスタンプが古くなってても更新扱い」にしてくれないの？
185:デフォルトの名無しさん
24/12/11 13:29:52.53 +nAxu/ku0.net
1バイトも更新せずにタイムスタンプだけ更新したら、それも記録すんの？
そのタイムスタンプ更新の著作権は誰に所属するの？
コミッタはそれを確認して承認作業するの？
古いパッチの再利用したら日付が昔に戻るの？
ブランチ統合したらどっちの日付が採用されるの？
アホらし過ぎる議論
ファイルのバックアップは別に取れ
186:デフォルトの名無しさん
24/12/11 17:38:01.33 HXU8Fpor0.net
>>170
今話してるのは質問がGitをバックアップに使ってると勘違いしてる人たちだから無視していいよ
他の人は>>100でやりとりが終わってると分かってる
187:デフォルトの名無しさん
24/12/11 18:37:28.10 bZvW/lze0.net
>>180
それは「現時点でもGitはバックアップツールとして十分使えます」と言ってるんだがお前はそれで良いのか？
>>183-184
つ make distclean
>>185
回答を期待してるわけではないだろうが、俺が今思いついた範囲なら、
1バイトも更新せずにタイムスタンプだけ更新したら、それも記録すんの？→古い日付のファイルに戻してからcommitしろ(或いは「内容が同一のファイルは非更新扱いにする」オプションをcommitコマンドに追加するからそれを使え)
そのタイムスタンプ更新の著作権は誰に所属するの？→上記なので関係なし
コミッタはそれを確認して承認作業するの？→同上
古いパッチの再利用したら日付が昔に戻るの？→パッチを当てた日になる、つまり戻らない
ブランチ統合したらどっちの日付が採用されるの？→マージ時に変更されたファイルはマージした日付になる
これで別段大して問題ない気がするが
まあ日付を保存する事について技術的問題はないと思うけど
Linusがわざわざ外したんだから、政治的な問題はあって、採用はされないんだろうけどさ
(全世界からメール等で連絡受けてたLinusは、テメエのローカルタイムなんて知るか！！！とブチ切れ、
タイプスタンプでの連絡が出来ないように作ったと予想)
が、多分根本は、形式主義者か現実主義者か、といったところか
形式主義者： GitはVCSであり、それ以外の使い方をしてはならない
現実主義者： 機能が揃ってればラベルがどうであれ使う
つまりGitもバックアップツールとして使えるし、
GitHubは容量無制限のファイル置き場だし、
git clone GitHubのURL: が現状一番簡単なデプロイ方法であるので、Gitはデプロイツールでもある
(ただし目的外流用だから色々機能が揃ってないが、それでも他ツールよりマシなら使うだけ)
188:デフォルトの名無しさん
24/12/11 19:28:51.98 kPp0f2Rs0.net
>>187
開発者に「俺達の利便性のために、お前らはチェックアウトするごとに手動でcleanして一からビルドしろ」と言ったらさすがに傲慢かと。
gitはプログラム開発者がソースコード管理のために用意したツールだから、開発者にとって百害あって一利無しの機能が入ることは無いんじゃないんかね。
189:デフォルトの名無しさん
24/12/11 20:38:24.90 WFtEMDpk0.net
>>183
Subversionには、ファイルのタイムスタンプをコミット日時にする設定はあるけどな
もちろん、makeを使うような人には危険な機能だが、それなりの要望はあったのだろう
190:デフォルトの名無しさん
24/12/11 20:46:11.17 bZvW/lze0.net
>>188
それはお前が傲慢すぎ
元々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されるのは分かり切ってるのでやるならフォークしかない、といったところ
191:デフォルトの名無しさん
24/12/11 21:17:41.31 +nAxu/ku0.net
何も分かってないやつがいて草
タイムスタンプは過去には戻らない未来に進むだけ、という前提で多くのツールが設計されてる make もそう
この前提を壊さないように配慮することが大原則で git のみならず unix 系のツールは設計されてる
バックアップからの復元はこの前提を壊して過去に時間を戻す行為なので特別な時にのみ使うもの
192:デフォルトの名無しさん
24/12/11 21:35:45.41 bZvW/lze0.net
>>191
zipやtarは普通にタイムスタンプは保存されるだろ
その延長で考えるなら、保存された方が自然だし有用だ、というだけ
ただまあ、これも合意する必要はない
フォークしてどちらがウケるかで決するフォーク主義が正しいし、ユーザーは好きな方使えば済むだけ
(現実的にはcp -p と同様にオプションで切り替えるのが普通で、
逆に言えばオプションすら存在しないGitは何らかの「意図」をもってそうしてるとも言える
理由は今のところ不明なので思いつく人はよろしく)
まあ心配せずとも、Linuxカーネルにコミットしてくる連中で、make clean を知らない奴なんて一人もいないよ
(だから多分問題はここではない)
193:デフォルトの名無しさん
24/12/12 00:21:35.10 C7R5gozk0.net
git pull した後に make clean とか git 使ったことないのが丸わかりだな
何のための make だよ？
194:デフォルトの名無しさん
24/12/12 01:11:52.06 2Npzz1EV0.net
負け組のためのだろ
195:デフォルトの名無しさん
24/12/12 08:57:54.12 yWChnlb80.net
>>190
「俺はタイムスタンプの管理をgitでやりたいから、お前らはチェックアウトするごとにmake dustclean しろ」と言ったら、温厚になったLinusでもさすがに罵倒するかと。
gitはLinusがlinuxのソースコードを管理するために作ったツール。今もメインユーザーはLinux開発者で想定利用シーンもLinux開発なんだから、「Linux開発者の足を引っ張る機能」を追加するのはディレクターの正気を疑うレベルですな。
196:デフォルトの名無しさん
24/12/12 09:15:02.60 C7R5gozk0.net
>>195
いや linux とか Linus とかもはや関係なく全プログラマー大爆笑案件だろ
git pull で同期したら日付が過去に戻りましたとか全員が git の使用やめるレベル
197:デフォルトの名無しさん
24/12/12 09:16:55.48 OOlmzVQX0.net
URLﾘﾝｸ(stackoverflow.com)
PythonやPerlを使う人には、makeのためにタイムスタンプが失われるのはいい迷惑だと言われてるな
今さらリポジトリにメタデータを埋め込むのは難しいにしても、
gitconfigで>>189くらいさせてくれてもいいのにとは思う
198:デフォルトの名無しさん
24/12/12 15:16:51.62 d+ZuY6W00.net
>>197
当然だが既に同じことを考えてパッチしてた奴が居たか
> 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なら保存されるのか？なら俺はそれでもいいんだが
(料理の腕前で勝負してるのに、整理棚に必要以上にこだわっても本末転倒)
199:デフォルトの名無しさん
24/12/12 15:21:09.29 JM/xCx8/0.net
料理の腕前で勝負してるつもりならさっさとWitBucketとやらを作れよ
200:デフォルトの名無しさん
24/12/12 16:33:59.70 d0NKDmelM.net
>>198
ChatGPTで3行に縮めて投稿しろ
201:デフォルトの名無しさん
24/12/12 18:58:50.56 yWChnlb80.net
>>198
>Linus以外はほぼやらねえし、
「gitはLinusがLinux開発で使うために作った」という大前提を忘れるのはアルツハイマー病の一種かしらん？
202:デフォルトの名無しさん
24/12/14 10:34:37.92 mefXJp+A0.net
Gitの使い方というかSourcetreeの使い方というか質問があります
とある1コミットに複数ファイルがあって複数個所に変更がまたがってて
別ブランチにそのコミットの1ファイルの1部分だけをマージしたいです
その場合はチェリーピックは使えないので1部分のHunkをステージングに移動して
コミットするという方法が素直なマージ方法でしょうか？
203:デフォルトの名無しさん
24/12/14 11:43:48.24 kPFQFgKW0.net
>>202
採用元が push 後とか他人のコードだとそんな感じかな
私だと cherry-pick してから巻き戻し修正するけど、複数パッチなら rebase -i で edit を使う
採用元がローカルにしかない push 前なら元のコミットを分割しておくのが良い方法だろう
将来的に再利用するときにも別々に利用する可能性があるものは、今のうちに別パッチに分割しておくのが賢いと思う
204:デフォルトの名無しさん
24/12/14 11:54:03.74 mefXJp+A0.net
>>203
回答ありがとうございます
まさに他人がプッシュしたものを派生ブランチにも適用させようとしています
その中に特定ブランチの対応分も混ぜてしまっていたため
どう対応すべきか質問した次第です
コミット分割は癖にしておきたいと思います
205:デフォルトの名無しさん
24/12/14 14:22:21.70 jFwYZGRF0.net
ろくに開発経験ないやつがgitの仕様はグダグダとか言ってるのまじで面白いな
206:デフォルトの名無しさん
24/12/14 19:07:11.21 cLbKsfdN0.net
>>93の質問以降まともだったのは96、97、99、101、107くらいしかいなかった
7bは置いとくとしても100レスも使ってこの体たらくとは情けない
207:デフォルトの名無しさん
24/12/15 22:01:21.97 D9xraIFr0.net
>>179
diffでわざわざ比較するというのは時間の無駄
208:デフォルトの名無しさん
24/12/15 22:49:45.11 9FCwcKO70.net
>>207
相手にすんな
バケツ君はマニュアル読めなくて git が外部 diff に対応してることすら見つけられずに俺の望む出力じゃないと散々暴れた過去がある、今もそう思い込んでるので
209:デフォルトの名無しさん
24/12/15 23:49:43.28 UElXL8/K0.net
>>204
コミットの際にcherry-pickまで考慮するなんて不毛だからやめておいた方がいいよ
そんなことをしなければならないほど強くcherry-pickに依存したワークフローになっているならその方がよほど問題
210:デフォルトの名無しさん
24/12/16 00:02:22.98 I9YsDANU0.net
不毛っていうのも程度問題でしょ
経験の浅いメンバーだと一つのコミットに複数のバグトラッカーのissueを混ぜこぜにすることがある
hot－fixブランチが必ずしも計画的に作られるとは限らないからcherry-pickで取り出したいことは時々起こる
211:デフォルトの名無しさん
24/12/16 12:28:18.00 UeL/Eu4T0.net
cherry-pickに依存するのは不毛だと思うが、リモートへのコミットは機能単位・イシュー単位に整理した方がやり取り楽じゃない？
212:デフォルトの名無しさん
24/12/16 12:38:05.37 ZibPg38H0.net
同じプロジェクト内に並行で製品(バージョン)を維持しているような場合には cherry-pick は多用するよ
特にブランチ切るまでもない単純な修正の場合とか
要はコミット1個だけのブランチの rebase/merge の簡略形なので不毛とか言うやつは単に経験が足りないだけ
213:デフォルトの名無しさん
24/12/16 12:42:21.10 UeL/Eu4T0.net
せっかくbranch切ったのに、merge代わりにcherry-pickしたら後でトレース面倒にならん？
214:デフォルトの名無しさん
24/12/16 12:53:45.68 ZibPg38H0.net
>>213
cherry-pick はブランチ切るまでもない修正用だよ
コミット1個ならどこから cherry-pick したか分かれば良いだけだし
215:デフォルトの名無しさん
24/12/16 13:11:10.31 56LO+jCc0.net
今度はチェリーピックでやり合いか
216:デフォルトの名無しさん
24/12/16 13:17:14.68 I9YsDANU0.net
将来どのコミットが急遽hotfixに採用されるか分からないからといってあらゆる事前の修正コミットをもしものためだけにブランチ分けするのもガチガチで作業効率が落ちる
程度問題と言った通り俺はcherry-pickを多用する気もないしフローとして禁止扱いも効率が悪いと思う
hotfixが必要ない現場なら必要になる機会は少ないだろうな
217:デフォルトの名無しさん
24/12/16 13:41:54.88 ZibPg38H0.net
cherry-pick には複数の使いみちがあって別に全部の使い方しなければいけない訳ではないが色々知ってると便利
・最新版から過去リリースへのバックポート
・セキュリティなどの hotfix の適用
・テスト用の addhoc 修正版（正式なマージは今ではない
・ゴミ箱ブランチ等から拾ってコードの再利用（コードだけ拾ってコミットは再利用しない
など多数
「1つのコミットには1つの修正」という大原則を守ってさえいれば、cherry-pick に限らずあらゆる再利用や利用中止がやり易くなるといだけ
218:デフォルトの名無しさん
24/12/16 15:08:47.67 /03Ox5VG0.net
cherry-pickって言葉のニュアンスの通り
219:デフォルトの名無しさん
24/12/16 16:03:21.23 ZibPg38H0.net
git の rebase と cherry-pick は同じ概念なので rebase とか使わない派閥のやつは cherry-pick も使わないだろうなあ
cherry-pick はブランチ切って rebase してブランチを消すを一発でやってくれるコマンド
正確には rebase の方が cherry-pick を繰り返した後にブランチ位置をそっちに切り替える機能というべきだけど
要はブランチを使うか使わないかの違い
220:デフォルトの名無しさん
24/12/16 22:52:09.15 m/ncuAnJ0.net
すみません、チェリーピックに関して質問した者ですが
追加で質問よろしいでしょうか？
本流ブランチAから子ブランチBが作成されて
子ブランチBから一時的に孫ブランチCが作成されました
ブランチCで修正した一部コミットだけブランチBにチェリーピックしてマージして
他のコミットは無駄なのでブランチCがもはや不要となりました
孫ブランチCを削除してもブランチBにチェリーピックした内容は
削除される（元に戻される）ことはない認識で合っているでしょうか？
221:デフォルトの名無しさん
24/12/16 22:58:16.88 m/ncuAnJ0.net
コミットの独立性が保たれているためチェリーピック元のブランチを
削除しても問題ないと認識しています
222:デフォルトの名無しさん
24/12/17 00:55:20.81 Np7JyJBV0.net
>>220
削除されないから大丈夫
まず第一に、残ったブランチやタグのいずれかから到達可能なコミットは生存し続ける
第二に、cherry-pickによって作られたコミットはマージと違って元のコミットとは別物の複製体になるので原本がどうなろうと知ったこっちゃない
223:デフォルトの名無しさん
24/12/17 07:53:20.59 n6Rf+SXX0.net
>>222
ありがとうございます
Sourcetree独自の機能か分かりませんが
チェリーピック元のコミットIDをコメントに付与しているため
もう辿ることもないコミットならコメントから余計な情報は
省いた方がよさそうですね
224:デフォルトの名無しさん
24/12/17 09:46:53.70 Np7JyJBV0.net
>>223
それは git cherry-pick -x で付く情報だと思う
公開されないコミットへの参照は残さないほうがいいね
225:デフォルトの名無しさん
24/12/17 12:10:27.20 Mk8ZrsM80.net
残ってても邪魔にはならないだろうけど cherry-pick 元がすぐ消える予定なら、付けないのが普通ですね
226:デフォルトの名無しさん
24/12/17 13:07:22.36 bMW/7Xg20.net
チェリーピックって童貞狩りじゃねえのか？
227:デフォルトの名無しさん
24/12/17 13:48:26.81 8t1OBzHLM.net
つまんな
228:デフォルトの名無しさん
24/12/17 14:02:58.22 Mk8ZrsM80.net
cherry pick
1. 都合の良いものだけを (恣意的に) 選び出す
2. 慎重に必要なものを選別する
2. 好きなもののみを摘み食いする
4. バーゲン品から掘り出しものを漁る
5. 木から熟したサクランボだけをもぎ取る
5が本来の使われ方、1の意味で使われることが多い
229:デフォルトの名無しさん
24/12/17 22:22:58.48 uhdhcEFf0.net
コミットする内容を複数に分けたい場合、必要な部分だけステージングすると読んだのですが、
この機能を使っても作業フォルダの内容は変化しないので、
一緒にコミットするべきだったところを入れ忘れてしまい、
プルしても正しく動かない状態のものを上げてしまっていたということがあります
この一発勝負みたいなステージングの機能をみんな使いこなしているのでしょうか？
230:デフォルトの名無しさん
24/12/17 23:11:14.06 Np7JyJBV0.net
>>229
一発勝負っていう感覚はおかしいでしょう
一度ステージングした後やコミットした後でプッシュするまでもいくらでも再確認とやり直しのチャンスがある
危うい操作をしたのに十分に確認していない内容をプッシュしてしまう習慣のほうがどちらかというと諸悪の根源だと思う
SVNだってローカルの変更を部分的にコミットしようと思えば同じようなリスクがあるので、ステージングという考え方自体のリスクではない
分割してコミットはビルドの通らないコミットを作ってしまうリスクは増すから不慣れで自信のないオペレーションになったときはstashやswitchを活用して疎通確認しておくとか、要らん変更と意図的に残した変更と漏れた変更を混同しないようにassume-unchangedやskip-worktreeなんかを活用してもいい
231:デフォルトの名無しさん
24/12/17 23:14:08.08 QjcMYSDT0.net
>>229
複数のコミットで一つの修正になるならrebase してまとめたら？
232:デフォルトの名無しさん
24/12/17 23:25:32.69 Np7JyJBV0.net
>>229
問に回答してなかった
ステージングの機能を使いこなしているかはNoです
差分確認からコミットまでの流れはGUIのほうが好きなのでステージングは全然活用できてない
233:デフォルトの名無しさん
24/12/17 23:33:17.82 Mk8ZrsM80.net
>>230
git status とかを頻繁に打つくせをつけた方が良いぞ、それでコミットし忘れ防げる（ついでによく使うオプションは alias にするとさらに良いぞ）
あと正しく動かないコミットに分割するのは「必要な部分だけ」とは言わないぞ
234:デフォルトの名無しさん
24/12/17 23:34:08.72 Mk8ZrsM80.net
>>233
アンカミス >>229 あて
235:デフォルトの名無しさん
24/12/18 09:25:32.99 IhQ3pKwU0.net
Git v2.48.0-rc0
236:デフォルトの名無しさん
24/12/18 11:41:14.09 pGa0ZLUBM.net
>>229
もうでてるけど
いれないものはstashして動確してcommit
stagingの存在理由わかってくる
237:デフォルトの名無しさん
24/12/19 21:05:36.88 KU+lpcLj0.net
>>219
言うほど同じか？
rebaseを好む派閥がrebase使う最大のモチベーションはログの直線化
そういう神経質な連中がcherry-pickによる重複コミットの大量発生を許容するとは思えないのだが
238:デフォルトの名無しさん
24/12/19 21:38:31.24 QSrQ7dPA0.net
やってることの内容は似てるけど用途が全然違うからなあ
かのPro Gitもリベースの章はベタ褒めでahhとかthe bliss of rebasingなどと顔もやや恍惚気味の御様子だが
チェリーピックとなると淡々とした説明で真顔だよ
239:デフォルトの名無しさん
24/12/19 23:45:56.41 b251oEg00.net
>>237
目的じゃなくて動き(実装)の話
rebase で cherry-pick できるし
cherry-pick で rebase できる
どっちもコミットの再利用(付け先の変更)を目的とするコマンド
あと直線化にしか rebase 使わないと思ってるうちは git の実力が認識できてない
240:デフォルトの名無しさん
24/12/20 01:21:38.28 +bubGwJY0.net
リポジトリを分けるか、モノでやるか
統合度合いが微妙な場合にものすごく悩む
241:デフォルトの名無しさん
24/12/20 09:56:06.03 PANCPXf30.net
そんなところで悩んでいる段階なら分けなくていいよ。最初から細かく分けようとするのは基本的に時間の無駄。
成功している組織はだいたいクソデカリポジトリなのも事実。それについては戦略としてモノレポが優れているというよりは結果的にそうなっただけだろうけど。
242:デフォルトの名無しさん
24/12/20 11:20:48.46 Vt9p1L/d0.net
>>240
一般論にはメンバーで分けるとうまくいく事が多い
将来的に人が増えたり入れ替わっても同じ1つのグループで開発を続ける予定なら一緒にする、
対応するグループが分割されて片方だけに関わる人が出てきそう、もしくは不明なら別にしておく
243:デフォルトの名無しさん
24/12/20 12:26:56.43 PANCPXf30.net
「うまくいく」の定義によるかなあ
分かれている方が良いという前提のもとで失敗の可能性を下げるという意味では>>242に同意するが、
個人的には不適切な分割による失敗は幾度も見たことがあるが、逆に一緒であることの直接的な実害にはあまり遭遇した経験がない
巨大なモノリスへと誘導されやすいみたいなアーキテクチャに対する影響は否定しないが、そのへんは日常的なコーディング作業というより
もっと大きな視点で恣意的に判断すべきことかと思う
そして、その判断を今すべきか、そもそも可能なのかは冷静に考えた方がいい
244:デフォルトの名無しさん
24/12/20 12:53:34.97 Vt9p1L/d0.net
>>243
・分かれてるものを一緒にするのはとても簡単だが、1つのものを分割するのはかなり手間がかかる
・単純なものどうしを組合わせるのは単純作業だが、複雑なものを組合わせるのは不可能な場合がある
という一般原則による、悩んだ時は原則に従うのがたいてい正しい
245:デフォルトの名無しさん
24/12/21 08:12:17.24 /IqCjkFy0.net
>>244
同様に、下記も言える
- 共通化されているものを個別化するのは簡単だが、個別化されているものを共通化するのは難しい
世の中そんなに単純じゃないんだわ
246:デフォルトの名無しさん
24/12/21 10:33:21.60 Hifil6s+0.net
>>245
俺の書いた2つは、お前が書いた共通化の手間より断然難しいというのが一般的だと思うが、お前にとっては同レベルなんだろうなあ
まあ頑張れ
247:デフォルトの名無しさん
24/12/21 11:20:34.07 w/Sbt61U0.net
>>246
誤解させたようで申し訳ないが、単なるリポジトリの統合じゃなくてコードの共通化の話な
一般論として、集中管理は密結合を、分散管理は重複を招く
共通部分を介して密結合しているモジュール同士を切り離すには最悪共通部分をコピペすればよい
一方、分散管理され各所で個別化された重複を後から共通化する作業には、それほど自明な移行パスは存在しない
コードスタイルや設計の問題といえばそれだけだが、それはモノレポだって同じことだ
248:デフォルトの名無しさん
24/12/21 12:43:49.34 Hifil6s+0.net
>>247
一般論だけどコードの共通化は難しくない
というのは必須ではないし時間の制限がないから
バラバラのまま結合して共通化できるところから時間をかけてゆっくり丁寧に共通部品に切り替えていけば良い
linux kernel とか部品の共通化に3年とか5年とかかけてゆっくりやってることも多い、共通化しないこともある
（手間だけの問題と技術的難易度の問題という本質的な部分の優先度を分けて考えると理解できると思うよ）
249:デフォルトの名無しさん
24/12/21 14:07:45.37 w/Sbt61U0.net
うーん、難しいと感じるかどうかはあなたの感性の問題だから、比較対象と根拠を示してね
250:デフォルトの名無しさん
24/12/21 17:31:11.06 Hifil6s+0.net
>>249
感性の議論はしてないよ、お前がそう思ってるだけ
技術的にすぐに必要なものもと、条件によって無くてもすむし後回しにもできるものとを同次元で語るなって指摘なだけ
（後回しにして良いなら簡単、やらなくて済むのが一番簡単、という当たり前の指摘、感性の余地とかない）
251:デフォルトの名無しさん
24/12/21 18:23:30.51 Bjr5M2i00.net
>>250
読み返してみたけど>>245のツッコミがまとも
お前は自分の意見が一般的と言い張ってるだけ
252:デフォルトの名無しさん
24/12/22 11:25:46.33 KQFeVRO70.net
>>230-236
みなさんご意見どうもです
SVNを使っていた頃や、ステージングを使ってみる前は、
変更ファイルをいったんどこかに逃がして、作業フォルダを綺麗な状態に戻して、
今回コミットしたいところだけくっつけ直して、動作確認できたらそれらをすべてコミットして、
逃がしておいたものを元の場所に戻して作業再開、みたいな操作をしてました
結局プッシュする前にステージングし忘れなどを確認する必要があるとなると、
コミット時に確実に確認できる上記の方法もそんなに悪くはないってことですかね
253:デフォルトの名無しさん
24/12/22 14:58:34.96 1vLY5nWA0.net
>>252
それで良いんじゃないかな？
私だと2つに分けたのを両方先にコミットしておいて、両方別々にチェックアウトしてテストを走らせるけど
問題があれば巻き戻してやり直し
問題がなけば push
push 前ならローカルでいくらでもやり直しが効くのが git の利点なので個人的に分かりやすいやり方でやれば良い
慣れたらテストの自動化とか検討すると捗る
254:デフォルトの名無しさん
25/01/01 05:03:32.91 RPjVgyjf0.net
Git v2.48.0-rc1
255:デフォルトの名無しさん
25/01/07 09:45:36.95 DbV6+6Xe0.net
Git v2.48.0-rc2
256:デフォルトの名無しさん
25/01/11 11:00:17.95 tzzUwbv+0.net
Git v2.48.0
257:デフォルトの名無しさん
25/01/12 11:20:09.87 L3maUoeD0.net
サル先生でGitの学習を始めました
そこで質問です！
下記コマンドの中に dewfr という記述が存在するのですが、これは何を意味するのでしょうか？
> git config --global core.editor "\"[使用するエディタのパス]\""dewfr
参照：URLﾘﾝｸ(backlog.com)
258:デフォルトの名無しさん
25/01/12 12:11:34.88 hjmuezNa0.net
先生が個人的に使っているエディタのファイル名なのでは？
直前がパス区切り文字で終わってるし
259:デフォルトの名無しさん
25/01/12 12:24:19.20 L3maUoeD0.net
あ～なるほど！謎が解けました！
ありがとうございます！
260:デフォルトの名無しさん
25/01/12 17:53:29.03 6ooBodrm0.net
Git用GUIがなまじっか日本語化されていると、
求めているコマンドを探すときに面倒くさい
261:デフォルトの名無しさん
25/01/12 18:29:09.15 ORJFqn4Yd.net
>>260
わかる
262:デフォルトの名無しさん
25/01/12 18:29:16.18 ORJFqn4Yd.net
>>260
わかる
263:デフォルトの名無しさん
25/01/15 09:29:23.33 3C2APGzS0.net
Git v2.48.1
264:デフォルトの名無しさん
25/01/15 14:32:20.61 gq5bJ2fy0.net
Git for Windows 2.47.1(2)Latest
265:デフォルトの名無しさん
25/01/15 14:42:56.61 gq5bJ2fy0.net
Git Credential Managerの脆弱性で
Git for Windows 2.47.1、2.46.2、2.45.2の各バージョンで差し替え
（日本時間2025-01-15 03:11）
266:デフォルトの名無しさん
25/01/23 09:18:49.62 vFJWSuXb0.net
ローカル上の作業ブランチで複数回コミットして、まだマージやプッシュをしたくない状態のとき、
ここでPCやSSDが壊れたら痛いのでローカルの内容をバックアップしておきたいとなったら、
どうやるのが常套手段なんでしょうか
267:デフォルトの名無しさん
25/01/23 09:22:23.44 5LAJlDxM0.net
個人作業用のブランチにpushすりゃいいじゃん
268:デフォルトの名無しさん
25/01/23 10:01:54.42 RFmrvYtC0.net
常套手段は知らんけど壊れることまで心配するならクラウドバックアップとRAIDじゃないの
手軽な手段ならpushとpush -fだな
-fで困る人いないでしょ
269:デフォルトの名無しさん
25/01/23 10:05:22.41 RFmrvYtC0.net
汚すことができないやむを得ない事情があるなら自由になる別のリモートを増やしてブランチをミラーリングしておく
270:デフォルトの名無しさん
25/01/23 10:42:03.41 JYmON0LL0.net
>>266
・ディスクをレイドとかにして耐障害性を上げる
・ディスク／ファイルシステムのバックアップを取る
・バックアップ用の別のリモート・リポジトリにプッシュする
・共用リポジトリに別のブランチ名でプッシュしておく
どれでも好きなのをどうぞ
全部やれば完璧
（最後のなら簡単、運用ルール的にかぶらないブランチ名の付け方決めとくだけでOK、個人名_ブランチ名 とか
271:デフォルトの名無しさん
25/01/23 12:27:44.30 vFJWSuXb0.net
>>267-270
参考になりました、ありがとうございます
.gitフォルダだけを圧縮して逃がしたりしていましたが、
自分しか使わない前提のブランチなら、リモートにプッシュしてしまってもよいものなのですね