Git 20

2024/02/15(木) 09:50:09.07

ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。

Git
http://git-scm.com/

◆関連サイト
Pro Git - Table of Contents
http://git-scm.com/book/ja
Git入門
http://www8.atwiki.jp/git_jp/

◆前スレ
Git 17
https://mevius.5ch.net/test/read.cgi/tech/1599016710/
Git 18
http://mevius.5ch.net/test/read.cgi/tech/1650651945/
Git 19
https://mevius.5ch.net/test/read.cgi/tech/1667720427/

VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

2024/11/18(月) 23:21:35.04

日本人はやたら正解があることにしたがるが、外国人は正解が複数存在するという考えだから発展する。

2024/11/19(火) 07:05:59.68

>>85
> なんでGitはおかしな原理主義者出てきやすいのだろう？
馬鹿がイキるのに丁度良い複雑さだから
まともな人はコードに忙しくツールなんて出来るだけ疎かにするのもあって

2024/11/19(火) 17:13:14.46

ゴミ箱くんが帰ってきたのか？

2024/11/19(火) 19:37:11.73

>>90
思い出した。
専用のスレッド作ってもらっていて、2022/11/20だ。あれから2年か。

2024/11/25(月) 16:12:49.15

Git v2.47.1

2024/12/02(月) 01:10:56.87

ファイルのパーミッションって保存されないの?

2024/12/02(月) 09:32:52.91

>>93
実行権限以外は管理されない、git は保存ツールやバックアップツールでなくてコラボツールなので読み書き権限の管理は不要
Windows 使いとかで実行権限がうまくいかない場合は core.filemode=true 設定とか、--chmod とオプションとかを使うと良い

2024/12/03(火) 09:10:05.62

>>93
なんかバックアップと勘違いしてる人多いよね。
複数のPCで使う前提なのにパーミッション管理して何したいの？って思う。

2024/12/03(火) 12:44:13.34

>>93
されないね 600の設定ファイルとかでよく出るGitのあるあるなんだけど設計思想なんでしょうがない
他のVCSには出来るものもあるんでそっちを検討するか、毎回シェルスクリプトを叩くか、置けるならGitのフックを使うか
それこそドットファイルの管理なんかでマージとかはあんまり考慮しなく出来るなら、rsyncみたいな世代バックアップのツール使ってもいいかも

2024/12/03(火) 16:09:40.34

perforceは出来るけどまああれだしな
後はそれこそRCSくらいしか思い浮かばないけど他になんかあったっけ

2024/12/03(火) 17:16:17.61

>>97
昔は、
新しいのは考え方や目的が違う、ファイル単位で読み書き権限の管理とかしたかったら今まで通りRCSとかCVS使い続けろ
って言うのが常識だったんだが

2024/12/03(火) 23:07:05.89

>>96 >>97
なるほどありがとう
そういうことならスクリプトでやるかな

2024/12/05(木) 01:07:05.86

>>93
それはOSが管理しているのであって、ファイルそのものにそういう情報があるわけではない。

2024/12/05(木) 09:32:47.93

んなこと言ったらファイル名もいらないって話になっちゃうぞ。
ファイル名はinodeではなくデータだとかいうツッコミは無しな。それこそファイルシステムの実装の都合に過ぎないんだから。
Gitがパーミッションを扱わないのはLinuxカーネル開発のソース管理においてそれを必要としないからで、それ以上のこじつけは必要ない。

2024/12/05(木) 14:04:38.28

xlsxとかxmlとしてバージョン管理できないの？しなくて良いのかもしれんが

2024/12/05(木) 15:31:26.26

>>101
git 出てくる以前から svn とか他の分散型でも実行権限しか管理しないのが常識だったから linux kernel のせいにするのは間違い

2024/12/05(木) 19:17:01.43

>>101
プレーンテキストにこのファイルの説明書が付いているという発想はなかなか思いつかないぞw

2024/12/05(木) 19:17:26.14

>>101
プレーンテキストにこのファイルの説明書が付いているという発想はなかなか思いつかないぞw

2024/12/05(木) 19:19:57.44

Windowsだってファイルにアクセス制御情報があるのではない。

DOSがディスクオペレーションシステムだと知っていれば、ファイルを管理しているのはOSで、ファイルがOSに指示しているという発想が出てくるはずがない。

2024/12/05(木) 20:15:24.74

（この流れ早く終わらないかなあ）

2024/12/05(木) 20:36:07.99

必要な機能が欠けている、という事でしかないのでは。
実行権限だけ管理するというのもチグハグだし。

>>101
> それ以上のこじつけは必要ない。
完全に同意。
Git信者はGit一神教徒だから、Gitは間違ってない、間違わない、という前提で話をするからおかしくなる。
本当に間違ってないのであれば、更新する必要がない。ある意味CやHTMLがこれに近い。
Gitはツギハギだらけなんだから、パーミッションも今後は保存されるようになる、それの方が便利だから、というだけでよいのでは。

2024/12/05(木) 20:59:18.56

>>108
逆に git しか使ったことないやつがこういう戯言言うよな
最近のメジャーな VCS は実行権限しか管理しないのが普通なのに git 特有の仕様だと思い込んでる。git 以前からなのに

2024/12/05(木) 21:27:58.46

みなさんケンカはやめよう

2024/12/05(木) 22:57:49.39

しかし教科書ではきれいにブランチだのフィックスだのと理想的なバージョン
管理が語られるが、会社でそれなりの規模になってくるとユーザーもいろいろだし
MSオフィスファイルや画像やとファイルの種別も多いのでほんとカオス化するなあ
もうやだ

2024/12/05(木) 23:18:07.05

>>106
だからその理屈だとgitが実行権限やファイル名を扱えることを説明できないでしょ
Linuxでは実行権限はメタデータだし、ファイル名はファイルではなくディレクトリのデータだ
Windowsではファイル名はアクセス権限と同等のメタデータの一つだね

2024/12/05(木) 23:37:35.74

>>112
それはGitの話ではなく、Gitの使い方の話だぜ？

2024/12/05(木) 23:38:42.52

>>112
ファイル名がパス名なのはUNIXの話でLinux独自の考えじゃない

2024/12/05(木) 23:39:42.78

>>112
「メタデータ」の意味を取り違えていますけど？

2024/12/05(木) 23:42:05.86

このスレッドはLinuxにおけるGitのスレッドじゃねえのにな

2024/12/06(金) 09:03:40.82

>>112
不毛だと思うが続けるつもりならシンボリックリンクを突いた方がいいのでは？
Gitに整合性なんて無いし、
Linusには不要だったから付いてないが、一般人には必要だから質問されるって事にしかならないと思うが

2024/12/07(土) 15:04:30.30

必要ならそのツールを使えばいいだけ。
GITではそんな機能はないと言うだけのこと。

2024/12/08(日) 01:32:04.62

随分ひどいが質の低いのが回答者側に回ってきてるのは悪いことなのかそれとも良いバロメータなのか

2024/12/08(日) 09:44:23.06

昔から専門系の板は簡単そうに見える質問が来ると極端な知識マウントで自己重要感を補おうとする人が湧くよ
今風に言うと「完全に理解した」人々ってやつ

2024/12/08(日) 13:11:46.15

事故重要感って言葉初めて聞いた

2024/12/08(日) 14:49:01.54

検索したら出てきたから使っている人いるんだね。
自尊心と何が違うのかは知らんし、どうでもいいけど

2024/12/09(月) 08:29:12.66

他人の作ったツールでマウント取ろうとしてる時点で頭おかしいけどな
せめて「ぼくのすごいそふとうぇあ」でやれよと
(この意味ではQiitaは正しい)

それはさておき、
・実行環境の全てを保存したい→パーミッションも全部保持して欲しい
・ソースコードの変遷が辿れればいい→パーミッションは全部755でいい
実行権限のあり/なしで動作が変わるシェルスクリプトなんて普通作らんし、
(Git以前かららしいが)実行権限だけ保存するのはどういう理由なん？

2024/12/09(月) 08:58:03.97

>>123
多分だけど古くからの unix 文化の影響
ファイル所有者の読み書きの権限は無制限、ファイル所有者の実行権限は個々のファイルごとによって違うという使い方をするのが普通だった
分散型だと他人とかグループとかを管理する必要はない（そもそも所有者とか所有グループを管理してないので他人と所有者の区別がない）
結論として「実行権限」だけが残った

2024/12/09(月) 09:59:14.74

>>124
つまりデフォの644→手動で755に変更の履歴を残すのが目的だったと
なら750とか400とか使って真面目に管理してる連中には機能が足りないのだろうね

機能が足りないのなら追加すればいいだけの話
そこでGitは間違ってない、今後ともパーミッションが保存される事はない、他VCSもそうだし、とか考えるのは頭おかしいと思うぜ

2024/12/09(月) 10:54:51.44

>>125
そもそもバックアップはないのでファイルの所有者とかグループとかを保存管理してない

・つまり644だろうと666だろうと600だろうと違いがない、後ろの2つの数字は意味がない
・開発において所有者自身の読み書きを禁止する意味はない

という考えなので所有者の実行ビットのみくらうしか汎用的なユースケースが存在しない

みんなが役に立つ具体的な使い方思いつけば拡張されるかもしれないが、それを思いついたやつは今までいないので現状があると理解しろ

2024/12/09(月) 12:05:14.30

>>126
> それを思いついたやつは今までいないので現状があると理解しろ
それはお前が知らないだけ
ソースコード管理者≠実行者なのは普通にある
例えばapache等のWebサーバーはnobodyやothers等の低権限で動かすのが一般的だ
この場合は少なくとも自分とapacheの権限は独立して記録出来てないと不便だろ

そもそも今回の質問が発生するのも、また、
> 600の設定ファイルとかでよく出るGitのあるあるなんだけど設計思想なんでしょうがない (>>96)
あるあるになるのもみんなその機能を使いたいからだろ

> そもそもバックアップはないのでファイルの所有者とかグループとかを保存管理してない
バックアップ程度で大半の人には十分だし、実際、デプロイしたらいきなり使える方が便利だろ
これを言うとデプロイツールでもないと言い出すんだろうが、
いちいちパーミッションを設定するだけのスクリプトを書いたり、手動で走らせるのは全くの無駄だろ(>>96-99参考)

Git信者にはGitは間違ってない！としか思えないのだろうが、
俺は単純にパーミッションも保存すればもっと便利になるからそうすればいいだけだと考える
まあこの点は平行線なのでもういいが
とにかく今できないのは事実としてもね

というかね、このスレのGit信者にはパヨクや意識高い系馬鹿と同じ類の勘違いを感じる
「Gitではパーミッションは保存されないのが正しいのだ！だからお前らもGitの正しい使い方を学べ！」ではなく、
大衆が望んでる機能だし、今からでもパーミッションを保存するように改善すれば終わる話だと思うのだけどな

2024/12/09(月) 12:09:10.99

>>127
もしそう思うなら具体的なユースケースをつけてコミットしろ

みんなの役に立つと思われば採用されるだろう
お前の役にしか立たんと思われればフォークして勝手にやれと言われるだけ

結果が全て、お前の妄想はいらない

2024/12/09(月) 12:21:54.83

git に限らずオープンソースというのは実際に手を動かして実物で利便性を証明したものの集大成
誰もやらないのは、やる価値がないから（コストに見合わないと思うから）
怠慢だと思うならお前がやって証明しろ

2024/12/09(月) 13:27:52.18

>>128-129
長期的には俺がフォークするかもだが、今はやらないよ
誰かがフォークしてパーミッションも保存するバージョンを作ったら、そっちを使うけど
(同じスタンスの奴も多いはず。そもそもGit以前のLinusも同様だし)

というかそこでムキになる理由が分からんのよ
お前がGitの基本設計をしたわけではないのだから、お前が間違った事にはならないし、
必要な機能なのだから、最終的には実装されるだろうし、なら付ければいいだけだろ

現実的には99のように自分でスクリプト等を『余分に』整備して我慢してる人が大半で、
いつか誰かがブチ切れて実装されるのを待ってるだけだろ
OSSなんてそんなに大した物でもないよ
(Gitに限らず、どれもこれも結構ポンコツ)

なお俺がGitにコミットする事はないぞ。やるなら必ずフォークする
理由はコマンドをほぼ全部リストラしたいから

2024/12/09(月) 13:55:32.71

「何で？理由は？」ってお前が問うから
・unix の伝統的に必要性が低いから
・そのせいで今まで誰もやろとうとしなかったから
という今そうなってない理由を答えてやっただけ（理由を間違えてるなら指摘しろ

それがお前の需要を満たしてないと思うのならば、それは別問題、それはお前が変えろ
変えるのは自由、そっちは議論してない

2024/12/09(月) 14:08:27.99

バケツ君再来?

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を使うような人には危険な機能だが、それなりの要望はあったのだろう