22/10/08 00:36:23.18 5sXOif570.net
以前作ったリポジトリのmasterブランチの名前をmainに変えようとしてます 以下の手順であってますか?
リモートリポジトリは自分がSSHでログイン出来るノードにあってベアリポジトリにも入れる状態です
1. (ローカルで) git clone <リモートリポジトリ> <ローカルリポジトリ> # リポジトリを取得
2. (ローカルリポジトリで) git branch --move master main && git push origin main # ローカルでmasterをmainにリネームしてプッシュ
3. (リモートのベアリポジトリで) git symbolic-ref HEAD refs/heads/main # HEADをmainに設定
4. (ローカルリポジトリで) git push origin :master # リモートリポジトリのmasterを削除
おかしいようであれば、新しいリポジトリを作って2.でそっちにpushして古いリポジトリは退避、以後は新しいのを使うことも考えてますがどうでしょうか
634:デフォルトの名無しさん
22/10/08 05:07:17.54 qNYwj5bN0.net
>>610
大学には頭おかしいのがおらんとでも？
大学全体の何割が使ってるか言ってみ。
635:デフォルトの名無しさん
22/10/08 07:49:17.82 fwLI4Y/XM.net
どうせ安全じゃないだろw
>fatal: detected dubious ownership in repository at
こんなものつけるなよカス
636:デフォルトの名無しさん
22/10/08 09:15:42.49 vxPAcYo70.net
>>613
大学だけじゃないぞ
プログラマならシェルスクリプトマガジンぐらい知っておろう
そこに長期連載されているほど、普及しておる
頭がおかしいなら、こんなに長く連載されるはずがないな
637:デフォルトの名無しさん
22/10/08 13:26:00.09 HbWzH6SVM.net
>>615
シェルスクリプトなぁ……簡単な作業の自動化用途だな。
なんでgitスレでこんな話題が？
NG指定したほうがいい？
638:デフォルトの名無しさん
22/10/08 14:00:29.88 x9F/jCO70.net
>>612set-headサブコマンドが使えるみたい
639:デフォルトの名無しさん
22/10/08 14:11:03.99 vxPAcYo70.net
>>616
愚か者め。シェルスクリプトは何でも出来る。CGIも作れた。
この間はUNIX哲学に基づいてリアルタイムカーネルなしに
シェルスクリプトだけでリアルタイム処理を実現してみせたわ
URLﾘﾝｸ(www.sea.jp)
640:デフォルトの名無しさん
22/10/08 14:23:26.42 vxPAcYo70.net
>>616
gitのような目的を見失ったバージョン管理ソフトを使っているからだ
バージョン管理ソフトはライブラリよりも長く行き続けなければならんものだが
リポジトリでわけのわからんバイナリ形式を使っておるから
バージョン管理ソフトが滅んだら復元は不可能になる。一体何を考えておるのか。
「データはテキスト形式で保存しろ」とはUNIX哲学でも言われている。
641:デフォルトの名無しさん
22/10/08 14:47:58.03 TKlSmRLn0.net
容れ物が古くなったら新しい容れ物に中身を移すだけ。
642:デフォルトの名無しさん
22/10/08 14:51:46.02 vxPAcYo70.net
>>620
よくもまあ懲りもせずにといったところだな
そうやって古くなったソフトを捨て新しいものに入れ替え
せっかく覚えた知識は無駄になり移行作業で苦しむ
POSIX原理主義なら一度覚えた知識は一生使うことが出来る
新しいことを覚える必要はない
643:デフォルトの名無しさん (ﾜｯﾁｮｲ deb0-zauZ)
[ここ壊れてます] .net
啓蒙したいんだろうけど
>新しいことを覚える必要はない
これ読んで「そんなメリットがあるなら俺もPOSIX原理主義に入信しよう」と考えるエンジニアがいるもんかね。
644:デフォルトの名無しさん
22/10/08 15:30:37.98 5sXOif570.net
>>617
git remote set-headだとリモートトラッキングブランチのHEADが変わっただけでベアリポジトリ側のHEADは変わらず、
HEADが指してるブランチ(master)も削除操作が利かないままだったんですが、もうちょっと教えてもらえませんか
645:デフォルトの名無しさん
22/10/08 17:26:15.60 qNYwj5bN0.net
>>621
いいから、お前は黙ってシェルスクリプトでOSカーネルでも書いとけ。完成するまで戻って来るな。
646:デフォルトの名無しさん
22/10/08 17:39:03.44 88/OpuEG0.net
啓蒙したいんじゃなくて単に荒らしたいだけだから
だいたいオープンソースなのにソフトウェアが滅ぶとか意味がわからん
647:デフォルトの名無しさん
22/10/10 11:28:58.21 JuIf0a+H0.net
シェルスクリプトのヤツは釣りだろ？
マジでいってんだったら頭おかしいだろw
(基地外を釣るエサ投下)
648:デフォルトの名無しさん
22/10/10 17:13:47.79 +gDGPUis0.net
URLﾘﾝｸ(megalodon.jp)
私の場合は「POSIX原理主義者」という名の人格者として名を知られるようになってきたが、「原理主義」を名乗るだけあって、
649:デフォルトの名無しさん
22/10/10 17:25:23.67 PTVZRYxu0.net
>>627
いいからお前はシェルスクリプトでカーネル書く作業に戻れ。シェルスクリプトがあれば何でもできるんだろ。
650:デフォルトの名無しさん
22/10/10 17:30:56.62 +gDGPUis0.net
>>628
勘違いしてるぞ。俺は人格者（笑）って書き込んだだけだぞ
651:デフォルトの名無しさん
22/10/16 04:54:37.57 kNlIrq3k0.net
Shelling at Russian power plant leaves Belgorod without electricity
URLﾘﾝｸ(www.youtube.com)
652:デフォルトの名無しさん
22/10/16 04:55:55.59 kNlIrq3k0.net
間違えた、すまん
653:デフォルトの名無しさん
22/10/19 13:19:13.07 1sfAoeRGa.net
Git v2.38.1
654:デフォルトの名無しさん
22/10/27 07:22:57.17 TnOoNEjS0.net
Git初心者でGit練習中の者だが、質問いい？
関数の履歴を見るコマンド
Git log -L '/function myfunction/',/},/:myFile
があり得ないほどメモリを食うのだが、これって今のところ仕様？
それとも俺の使い方がまずい？
2MB程度のファイルを2800回程度コミットしたリポジトリがあって、git gc して12MBになってる。
これに対して上記コマンドが9.4GBメモリを食う。
おかげでMINGW32bit環境では全然駄目で、MINGW64bit環境だと上記の通り。
Linux64bit環境でもスワップを増やさないとコケたので4GB以上は食ってるはず。
(windowsでの結果をふまえ、スワップを9GBに増やした環境では動作した)
Gitのバージョンは、Windowsは最新(2.38.1)で、Unixは2.20.1。
なお出力された内容には不満はない。
ただ、10-20行程度の関数が15個履歴として表示されるだけで、このメモリはあり得ない。
シェルスクリプトでも同じ物は得られるが、1GBすら行かないはず。
最初から最後までfreeしないでやってるとしか思えないが、何かそうなる理由ある？
あと、オプション等で回避する方法があれば教えて。
655:デフォルトの名無しさん
22/10/28 00:23:09.45 yz6FOYrM0.net
LooseCompressionの全展開用の領域 2MB*2800=5.6GB
git logは内部でlessにパイプでデータを渡してるから
パイプバッファも含めて約2倍だろうか
Packしなけりゃ少しはマシかもしれない(未確認)
656:デフォルトの名無しさん
22/10/28 07:15:31.79 HlXde3ci0.net
>Pack
git gcのことか？
なら実は当初はしてなくて1.2GBあったが、その時からコケてた。少なくとも2GBは食ってる。
その後gc出来ると知り、やってみたが、実際は自動で何回かやってるようだし、多分大勢は変わりない。
(実は全部新たにコミットし直すのも試してる)
なお愚直にgit show -> 切り出し -> diff を繰り返すだけのスクリプトを作って試してみた。
メモリは普段の使用と変わりなかった。
ただ問題は時間で、12分程度かかる。これでは気軽には使えない。
MINGW64だと2分程度で済む。
時間がかかるのは一々ファイルにしてるから？だから、
/dev/fd/3等で全部でパイプに出来れば短縮出来るかも？、というところ。
(システムキャッシュに完全に載るサイズだから関係ないかも？だし、
そもそも2回ずつ使うのでパイプにフィットしないが)
ただ現在でも初期画面は数分で出るし、出なければ大昔のコミットなのでどうせ問題なく、
実際の運用としては及第点ではある。でも速ければ速いに越した事はない。
Gitはおそらく速度重視なのだろう。
自動増加スワップのMINGW64環境なら現実的には大した問題にはならない。
ただ、全部メモリ上に展開する意味もメリットもないはずなので、
途中で一回もfreeしてないであろうこのコードは、コードとしては大問題だとは思うよ。
(ジョークで言われてる、Javaしか知らない奴が書いた、freeが一つもないコード、になってる)
657:デフォルトの名無しさん
22/10/28 07:18:13.37 RikIMzkC0.net
報告してあげるといい事案だと感じる
658:デフォルトの名無しさん
22/10/29 06:39:27.49 J4pkDf7Q0.net
パイプへの変更は厳しいので、一時ファイルをRAMDISK上に配置してみたが所要時間は変化無し。
よってシステムキャッシュは効いてて、パイプにしても高速化予算はほぼ無いと分かった。
diffを切ったら8分、さらに切り出しを切っても8分(変化無し)、git showをgit --version に変更したら2分で終了した。
よって時間予算は gitプロセス起動が1/6(2分)、git show が1/2(6分)、切り出しはほぼ0、diffが1/3(4分)と判明。
git showを高速化する為には出来るだけ纏めて取り出すのがよく、
メモリ無限大なら全展開が一番速いのも事実だが、せめてコア数程度にして欲しい。
見てる限り特に先頭も末尾も異常に速くはならない為、
動画と同様に途中にスナップショットを適度に挟んでいるように見え、なら、全展開する必然性/妥当性はない。
(やってもそんなに速くはならないのにメモリを異常に消費する＝スワップする分余計に遅くなる)
>>636
これは開発者マシンなら最低でもRAM16GBでSSDだよね！というノリなら方針は間違ってない。
ただ、-n 100 とかで直近100コミットに絞れればいいだけなのだが、これが出来ないのが問題。
どうやってもいきなり9GB超掴みに行くのは使用勝手が悪い。そもそも最初の方の履歴なんてほぼ要らんし。
659:デフォルトの名無しさん
22/10/29 08:37:46.51 e5vmfD+T0.net
>>637
HEAD~100 とかじゃ駄目なの？
660:デフォルトの名無しさん
22/10/29 08:44:53.54 +5EirK6r0.net
いやバグレポートすればいいと思う
661:デフォルトの名無しさん
22/10/29 09:15:13.77 J4pkDf7Q0.net
>>638
実はそこは初心者過ぎてよく知らないんだわ。
git log HEAD~100
では制限出来なかったけど、どう書くべきなの？
とりあえず公式マニュアルでは -n が最初に載ってるので、-n が一番お手軽なのだと思う。
これが効かないのは、多分実装忘れじゃないかと。
> URLﾘﾝｸ(www.git-scm.com)
>>639
多分、メモリ大量使用は仕様で、-n が効かないのはバグだね。
662:デフォルトの名無しさん
22/10/29 09:25:26.30 +5EirK6r0.net
合理性のないメモリ使用があるなら実害があるユーザーが改善のリクエストをバグレポートで出せばいい
そういうもん
レアケース扱いされることもあれば皆が困ってるようなら優先的にチューニングされる
仕様なのでは！？と空気読んで黙ってるのは奥ゆかしいニンジャ精神
663:デフォルトの名無しさん
22/10/29 09:38:02.85 J4pkDf7Q0.net
>>641
なるほどその通りだ。
ガイドラインが糞長げえ…orz が、数日のうちにレポートする方向でやります。
> URLﾘﾝｸ(www.chiark.greenend.org.uk)
> URLﾘﾝｸ(www.git-scm.com) 内の this guide が上記
664:デフォルトの名無しさん
22/10/29 11:09:21.06 +W9Ulup+0.net
>>640
手練れのエンジニアとお見受けするが、どのジャンルで仕事されているので？
665:デフォルトの名無しさん
22/10/29 15:16:52.52 e5vmfD+T0.net
>>640
HEAD~100..HEAD みたいなのを最後につけてレンジを制限する話だけど効かない？
666:デフォルトの名無しさん
22/10/29 21:10:22.54 YQqcaKMe0.net
git log -100 じゃなくて？
667:デフォルトの名無しさん
22/10/29 23:05:25.26 e5vmfD+T0.net
>>645
-100 と -n 100 と --max-count=100 は同じ意味で表示するログの数を制限する
A..B はログを検索する対象を制限する。(Bには存在するけどAには存在しないコミットという意味になる）
668:デフォルトの名無しさん
22/10/30 02:06:46.88 IOU525bY0.net
>>644
効いた！ありがとう。
何ぞそれ？と思いきや git log のdocumentの頭に書いてあるのな。
> URLﾘﾝｸ(www.git-scm.com)
gitは機能が多すぎてドキュメントがやたら長いので端折っていたのが敗因だ。
やはり最初は一通り読まないと駄目だな。
これなら回せばいいので、組んでみたら32bit環境で43秒で終了した。
これだと高速化チューニングではなく単にfree忘れっぽいのでレポートしておいた。
再現用のスクリプトも同梱してるから気になる人はどうぞ。
URLﾘﾝｸ(lore.kernel.org)
669:デフォルトの名無しさん
22/10/30 09:36:57.12 b5HYhcbp0.net
>>647
おつかれ。
慣れてくると git log とかは全ログ対象にはしなくて、素でレンジ指定するので、この手のリソース問題は見つけ難いんだよな。
670:デフォルトの名無しさん
22/10/30 12:37:33.31 IOU525bY0.net
>>648
初心者は意味不明な使い方を無自覚でやるから、どうしてもマイナーバグに当たりやすい。
なるほどタグを付けてgit logでは範囲指定がデフォか…
ってそのままtutorialに書いてあったわ。やっぱちゃんと読まなきゃ駄目だったorz
> URLﾘﾝｸ(www.git-scm.com)
つまるところ、今までこんな馬鹿げた使い方をした奴は居なかっただけだな。
671:デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4)
22/10/30 18:58:14.60 IOU525bY0.net
git diff の出力はデフォでpatchになってるのだが、これどうやったら切れるんだ？
> URLﾘﾝｸ(www.git-scm.com)
既にフォーマッタを持っているので、
unixコマンドのdiffのデフォルト出力と同じ物が
672:欲しい。 切るオプションも無いし、下の方のCONFIGURATIONにもそれらしい設定が見つからない。 diff.externalでdiffごと入れ替えないと駄目とかいうクソ仕様？ -s や --no-patchでは出力そのものが出なくなる。ただし > or to cancel the effect of --patch. と書いてあるから、かつては--no-patchではdiffのデフォ出力で、-sで出力無しだった気配はあるが。
673:デフォルトの名無しさん (ﾜｯﾁｮｲ 8bbb-VzUj)
22/10/30 21:37:56.23 b5HYhcbp0.net
>>650
git diff は git diff 形式 (unified diff 形式の変形) で出力される。それ以外の形式が欲しい場合は外部コマンド使うしかない。
674:デフォルトの名無しさん
22/10/30 22:10:12.22 IOU525bY0.net
>>651
マジかー。クソ過ぎ。仕様考えた奴馬鹿すぎ。
スクリプトに食わす為に先頭の+-の文字を変更するオプションとかあるのだけど、
これでいいと思った奴は死ねだな。
675:デフォルトの名無しさん
22/10/30 22:14:38.98 b5HYhcbp0.net
>>652
git はパッチ管理システムなんだから、それ以外が考慮されてると思う方が贅沢。
676:デフォルトの名無しさん
22/10/30 22:34:52.61 IOU525bY0.net
>>653
いやそうじゃねえ。というかこれはソフトウェアの構成を間違ってるよ。
diffだってバグはあるのだから、内製は止めて、普通にdiffのdllをコールすべきなんだよ。
GitはLinusが1日で作ったらしいし、最初はどう考えてもそうなっていたはず。
だから俺は config の中にデフォで diff -u みたいなエイリアスがあるのかと思ってた。
diffを内包する事に、何のメリットもない。
この名残がexternal driverで、それが使えればいいという事なのだろうけど、
ご丁寧にこれを禁止するオプションまである。(-no-ext-diff)
多人数の開発では、同じ画面を見ていた方が何かと楽だから、揃える方向で努力するのはごもっともだが、
禁止するのは違う。どこかでおかしな思想が混入しているよ。
そもそも、それ以外を考慮しない＝外部コマンドで十分出来る事はdllを呼ぶ、であって、
この構成だとGitがdiffも構成してるから、君は認識を間違ってる。
Gitは明らかにおかしい方向で無駄な事をやってしまっている。
そしてそれは君の価値観的にもNGなはずだよ。
677:デフォルトの名無しさん
22/10/30 23:37:53.37 b5HYhcbp0.net
>>654
Linus のこと知ってるのなら長文書く前に調べろ。
git 作る以前から、みんなが勝手なフォーマットでパッチ送って来るのは非常に困るので推奨のパッチ形式を決めてあったんだよ。
で git 作る時に強制的にその形式に統一されるようにした。どうしても他の形式で出したい場合はひと手間かかるのが設計意図どおり。
678:デフォルトの名無しさん
22/10/30 23:53:15.06 LXgcbV870.net
Linusも言ってたような気がするけど、気に食わなければ自分で作れ
以上
679:デフォルトの名無しさん
22/10/30 23:58:47.31 IOU525bY0.net
>>655
Linusはデフォを -u にして、patch送るならオプション無しで送れ、としただけでしょ。
これは間違ってない。
問題は、元のdiffの形式の出力が出来なくなってる事だよ。
オプションで出来るよ、でよかっただけ。
オプションすら禁止なら、今のgit diff に各種出力オプションがあること自体が君的に矛盾するだろ。
何故君がそんな意味不明なポジショントークをするのか分からないが、
Gitが方針を間違ってるのは事実だよ。
オプション禁止なら、git diff にオプションを何一つ付けてはいけない。
(仮にこれであれば、賛同はしないが理解はする）
ただまあ、ドキュメントの雰囲気だと、
おそらく昔は --no-patch で元のdiff形式が出せたのではないかと推測される。
君がどこまで知っているのか知らないけど、多分君の歴史理解も間違ってると思うよ。
680:デフォルトの名無しさん
22/10/31 00:04:41.05 h5Hfu9WR0.net
>>657
お前以外は誰もオプションとか必要ないから作ってないだけだよ。むしろ邪魔。どうしてもやりたければ外部コマンド指定でできるんだからオプションとかでやるよりよっぽど汎用性がある。
オープンソースなんだからオプション必要ならお前が自分でつくればいい。
681:デフォルトの名無しさん
22/10/31 00:08:19.51 h5Hfu9WR0.net
あと －－no-patch には昔からパッチ出さない機能しかないぞ。頭悪い推測とかする暇があったら過去のソース確認してこい。
それこそ git で調べればすぐだぞ
682:デフォルトの名無しさん
22/10/31 00:21:01.40 J+3pjzxx0.net
>>859
そうか？ならマニュアルの
> to cancel the effect of --patch
の部分は明らかに不要だから削除要請出しといてくれ。
というか君の「昔」がどれ位か知らんが、Linusの言ってた？フォーマットが統一されてないってのは、
diffの各種オプションではなく、edやsharに対してだと思うぞ。
683:デフォルトの名無しさん
22/10/31 00:43:54.22 h5Hfu9WR0.net
>>660
不要だと思ってるのはお前だけ。その思い込みが勘違いの原因だろ。
684:デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4)
22/10/31 07:08:10.92 J+3pjzxx0.net
色々確認したが、Gitの現状認識としては651であってるっぽい。
そして外部ツール使うしかないが、これは環境設定無しでコマンドだけで出来る。（動作確認済み)
git difftool --extcmd=/usr/bin/diff <commit> <commit>
> URLﾘﾝｸ(qastack.jp)
ついでにその中、
> Gitについて学ぶほど、それは1人の人、つまり元のプログラマーのために作られたものだと感じます。
これもよく言われてるようだが、俺も今回の件で同意だ。
合理性に欠ける判断をしているのだから色々文句言われるのも当然だ。
ただLinusは自分用に作った物を公開したら勝手に使われてるだけだから、知ったこっちゃ無いってのも分かる。
ただそれならそうと、いつもの調子でドキュメントにも書いててくれないと困るね。
合理的な構成を推定すると迷子になってしまう。
俺は絶対に diff -u 以外のフォーマットを許さない！絶対にだ！
とか書いてあれば、最初から諦めるので無駄に探す必要はなかった。
俺はLinusのこういった感情的な部分はわりと好きなのだが、まあ昨今の code of conduct では書いても消されるんだろうけども。
685:デフォルトの名無しさん
22/10/31 10:11:41.92 J+3pjzxx0.net
てかGitってまさかのモノリシックかよ！
こりゃ文句言われるのも分かるわ。完全に方向を間違ってる。
結果的に肥大化していったのだろうけど、現在の状況でこれは駄目だよ。
つかこれシェル化する方向のプロジェクトはないの？
子コマンド群のバイナリだけ貰いたいんだけどさ。
686:デフォルトの名無しさん
22/10/31 10:39:47.64 sko8U7ef0.net
>>663 好きに fork しなよ。
687:デフォルトの名無しさん
22/10/31 12:23:13.35 h5Hfu9WR0.net
自分でやってみればいいよ。
自分で多数の人が参加する巨大なプロジェクトを管理するようになれば、形式が統一されていることがどれだけ重要かわかる。
仕様を強制されているようでも、これこそが git の使い易さ、戦闘証明済の実力だと気付くよ。空想と現場は違う。
688:デフォルトの名無しさん
22/10/31 13:21:07.66 J+3pjzxx0.net
>>665
それが従来形式のdiffの出力をさせない理由なら、
現在のGitプロジェクトの思想は俺とまるで合わない。
今時モノリシックとか、多分じきにこのプロジェクトは頓挫するよ。
multicsの再来だね。(俺は使ったこと無いけど)
自覚症状もあるみたいだし。
> Git is a fast, scalabl
689:e, distributed revision control system with an unusually rich command set > unusually > https://www.git-scm.com/docs/git ただまあ本当にdiffも内製しているようで、ちょっと驚きだよ。 ただwikiによると当初はローレベルエンジン＋シェルスクリプトで、これは俺の思想と合致してる。 windowsに移植する際にシェルスクリプトをCに書き換え、そこでモノリシック化したようだ。 それで環境変数を見るとか、完全に開発の方向性を間違ってる。 当初のシェルスクリプト方式ならdiffを呼ぶだけだから、シンボリックリンクで好きなのと簡単に交換出来た。 この場合、Git側にコードは全く必要ないし、ユーザー側に予備知識も必要ない。 それをモノリシックにしてしまったから、環境変数を読むコードを必要とし、 ユーザーはマニュアルを読むことを強制させられる。 お互いに完全に無駄だ。 このメンテナは、ソフトウェアアーキテクチャはどうあるべきか、全く理解出来てない。 今ですらGitは難しすぎると文句言われてるだろ。 コードを書く為にコード管理システムの勉強が必要とか、完全に本末転倒だし。 じきに巨大な躯体を支えきれなくなって、分割プロジェクトが発生すると思うぜ。 それが多分Next-gitになるのだろうよ。 つか、何でGitはモノリシックを選択してんの？全く意味ねえと思うぞマジで。 本当にdiffとかを絶対に交換させない為？ならマジで死ねでしかないね。
690:デフォルトの名無しさん
22/10/31 14:15:23.19 Yrczlr02M.net
Simple is not easy
Gitは後者を選択することでSIerのドカタまで幅広く受け入れられたということだ
691:デフォルトの名無しさん
22/10/31 14:29:14.51 Pk1WyFqz0.net
(だからgit difftoolが用意されてんだろと言いたいけど、linux原理主義者みたいだし黙っとこう)
692:デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4)
22/10/31 15:04:18.65 J+3pjzxx0.net
>>667
他よりましなだけだろ。
ただ俺が思うに、Gitはもっと簡単に出来て、
・勉強しないといけないGit(今)
・勉強しなくてもなんとなく使えちゃうGit(次世代)
に分離すると思うよ。次世代版の需要圧力はもう既に十分あるし。
実のところ、今のgitにラッパシェルスクリプト群を被せれば次世代版出来ちゃうし、
(勿論見た目だけだがそれが重要)
俺はそれ作って使おうかとも思案中。
Gitは業務プロセス名のコマンドだから、実際何が起こっているのか分かりにくいのが一番の問題だよ。
コマンド名変えるだけでも相当変わる。
693:デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4)
22/10/31 15:05:02.85 J+3pjzxx0.net
>>668
それに辿り着くのにググったりマニュアルを読まないといけないのが問題なんだよ。
今のGitは世界中のプログラマに努力を強いてて、その犠牲の上に成り立ってる。
3時間程度あれば、再現コード付きのバグ報告が出来てしまう。
それをマニュアルを読むのに費やしてるのだから、無駄でしょ。
世界中のプログラマが3時間を世界が進歩する方向に費やせたら、Gitももっとよくなってたはずだよ。
694:デフォルトの名無しさん
22/10/31 15:39:10.00 oV1LtMOH0.net
それは世界中の人が俺に1円を恵んでくれたら
俺は大金持ちになっていたと言っているようなもんだな
695:デフォルトの名無しさん
22/10/31 15:57:50.61 h5Hfu9WR0.net
>>670
もっと良い物ができると主張するんなら作って広めてから出直してこい
もともと git を使ってきたやつらがどういう連中かわかって無さ過ぎ
linux カーネルコミュニティとか、文句言ってる暇があったらコード書いて変更した方が速いってやつらばかりだぞ
そういう連中がのべ何万人も十年以上使い続けた結果で今の仕様になってる。本当に問題だったら誰かがとっくに直してる
お前にはこの言葉を贈ろう「馬鹿でも使えるものは馬鹿しか使わない」
696:デフォルトの名無しさん
22/10/31 16:18:24.02 SCCWpcRv0.net
gitにdiffの書式の多様性を求めるなら、自分が使ってるコマンドの方を多様性を受け入れるようにすれば良いんじゃね
697:デフォルトの名無しさん
22/10/31 16:37:40.55 GzQExg5g0.net
gitにとってファイルの差分を抽出する機能は、単にユーザへ表示したりパッチをつくるだけじゃなくて、gitの特徴的なマージやリベースを実現するための核心的機能なんだよ
なので専用のものを内製する意味はある
698:デフォルトの名無しさん
22/10/31 18:09:11.73 J+3pjzxx0.net
>>671
OSSが世界中のプログラマからの元気玉なのは事実だろ
元気をマニュアルに消費されてなければ、もっと大きな元気玉になってただろうよ
699:デフォルトの名無しさん
22/10/31 18:20:34.93 5K9TC9u30.net
初歩的な質問ですが教えてください。
コミットの履歴が汚くなった場合、皆さんはどのように管理されてますでしょうか？
具体的には、
gitでdevelopからブランチを切ったAで作業しました。
ブランチAのコミット履歴が汚くなったので
新たに作成するブランチBにブランチAで変更したファイルを
一回のコミットで整理したいです。
git cherry-pick -n fromID..toID
などで整理しているのでしょうか？
700:デフォルトの名無しさん
22/10/31 18:28:03.00 oV1LtMOH0.net
>>675
タラレバ
701:デフォルトの名無しさん
22/10/31 18:33:43.29 J+3pjzxx0.net
>>672
> のべ何万人も十年以上使い続けた結果
それは言いすぎ。カーネルコミュニティって400人規模と聞いた覚えがある。
毎年全員入れ替わっても1万人規模だよ。
まあこれは本質ではないのでいいが。、
> 「馬鹿でも使えるものは馬鹿しか使わない」
これって誰の言葉だ？Linusが
> マジで、Cを選択する理由が「何もなかった」としてもだ、C++プログラマー避けになるというだけで、Cを使う大義名分になる。
> URLﾘﾝｸ(cpplover.blogspot.com)
と言ってるのは知ってるが。（しかもこれはGitの話らしい）
ちなみに俺はLinusの意見にも賛同する。プロジェクトに馬鹿が混入しないことは本当に重要なことだ。
ただ君と根本的に違うのは、「簡単は正義」と思ってることだ。
簡単に出来るのなら、簡単な方がいい。
馬鹿をふるい落とす為に敢えて難しい構造やコードにすることはない。
俺が見る限りLinusもそうしているわけではないが、君がそうしたいのは理解した。
まあ機会があれば実装して広めることになるかもしれない。
ただ俺は別のことをやろうとしてるから、Gitなんて動けば何でもいい程度でしかないので、優先順位は極めて低い。
あとたぶん、君は
> 文句言ってる暇があったらコード書いて変更した方が速い
の意味を誤解している。が、これは今言っても通じないと思う。
702:デフォルトの名無しさん
22/10/31 18:41:18.26 oV1LtMOH0.net
小１「掛け算よりも足し算のほうが簡単だ！」
703:デフォルトの名無しさん
22/10/31 18:42:37.79 oV1LtMOH0.net
しょう１「かけざんよりもたしざんのほうがかんたんだ！かんじよりもひらがなのほうがかんたんだ！」
704:デフォルトの名無しさん
22/10/31 18:50:02.57 sko8U7ef0.net
>>678
> ただ俺は別のことをやろうとしてるから、Gitなんて動けば何でもいい程度でしかないので、優先順位は極めて低い。
これまでの開発者を含めて他の人もそうだっただけという可能性に思い至れば何の不思議もないことなのに。
705:デフォルトの名無しさん
22/10/31 18:50:46.86 J+3pjzxx0.net
>>674
不可欠な機能ではあるが、核心的機能ではない。
事実として、Git内のdiffをGNUdiffに差し替えても、マージやリベースが出来なくなるわけではないだろ。
Gitは方針を間違ってる。
もし仮にGNUdiffのアルゴリズムが糞過ぎて出力が糞でマージが出来ないとしても、
アルゴリズム部分はGNUdiffにcontributeし、Gitがそのソースコードを使えばいいだけ。
Git内のdiffもGNUdiffからforkしたのだろうし、普通はこうすると思うけど。
別に実装すべきなのはフォーマッタで、--word-diffとかの部分だよ。
勿論GNUdiffに入れるのがベストだが、この辺
706:は断られてもおかしくないし。 ただこれも人間用であって、マージする為に必要な機能部分ではないから、 君らから見てもGitではなくdiffに入れておけ、となるはずだが。 まあdiffに手を入れたくなるのは分かるが、それはソフトウェア開発ではやってはいけない方向で、 我慢してGNUdiffにcontributeしておく方が全体の長期的利益になるんだよ。 Gitがこの辺、アルゴリズムとViewをごちゃ混ぜに扱ってるのも気になる。 MVCとかまるで言われない世界ではあるけど、それでも基本として理解しておくべきだよ。 ビューを分離しておくことはものすごく重要だから。
707:デフォルトの名無しさん
22/10/31 19:41:41.79 oV1LtMOH0.net
え？まさかgit diffを差分を見るだけのツールだと思ってるの？
708:デフォルトの名無しさん
22/10/31 19:42:41.80 oV1LtMOH0.net
GNU diffに依存したら、GNU diffが使われないところで
動かないってわからんかなぁ
diffは移植性低いんだよ？
709:デフォルトの名無しさん
22/10/31 19:49:40.38 J+3pjzxx0.net
ちなみに652で既に言ったが
> --output-indicator-new=<char>
> --output-indicator-old=<char>
> --output-indicator-context=<char>
> Specify the character used to indicate new, old or context lines in the generated patch. Normally they are +, - and ' ' respectively.
> URLﾘﾝｸ(www.git-scm.com)
このオプションが相当にヤバい。
これはデフォで
diff | less
となってる部分を、
diff --output-indicator-new='>' | less
とすれば幸せになれますよ、ということだが、これは
diff | sed 's/^\+/>/' | less
とすれば出来ることなので、gnuにこれを提案しても当然「そんなんイラネーよ」で終わってしまう。
Cで実装すべき案件ではないから。
そこで何故断られたのかを理解せず、だったらforkしますのノリなので、完全に無能の働き者だよ。
多分こいつらは本当にCしか書けない、Cしか知らない連中だ。
sed/awk/perl/python/rubyのどれかでも少しでも出来れば、この発想にはならない。
コントリビューターがこれを出してくるのも、メンテナがこれを止めないのも狂ってる。
プロジェクトにはいまだに正規表現を書けない老害しかいないと分かる。
だからこのオプションは、Linus的に言えば、常識的なプログラマー除けにはなってしまってるだろうよ。
710:デフォルトの名無しさん
22/10/31 19:51:14.64 oV1LtMOH0.net
git diffはパッチファイルを作るために利用されるし、
diffは環境依存するコマンドなんだから、
そんなのに依存したら、gitの移植性が低くなる
別の環境で実行したら、diffコマンドの出力がおかしくて
正しくパッチ当てられませんとかなったら困るやろ
常識で考えろや
711:デフォルトの名無しさん
22/10/31 19:53:03.45 oV1LtMOH0.net
>>685
> とすれば出来ることなので、gnuにこれを提案しても当然「そんなんイラネーよ」で終わってしまう。
あのさぁ、提案するのはGNUだけじゃだめだって理解してないの？
712:デフォルトの名無しさん
22/10/31 19:53:31.39 J+3pjzxx0.net
>>684
どういう意味？
少なくともどのプラットフォームにもdiffはあるだろ。
713:デフォルトの名無しさん
22/10/31 19:56:13.88 GzQExg5g0.net
>>682
diff.externalやdifftoolによる置き換えは差分表示に使うdiffを置き換えるだけで、git内部でマージやリベースを行うための差分抽出には使わないだろ
714:デフォルトの名無しさん
22/10/31 20:00:09.03 9mfNegYM0.net
ん?
これはもしかして以前来てたPOSIX原理主義者氏か?
715:デフォルトの名無しさん
22/10/31 20:00:09.25 oV1LtMOH0.net
>>688
全部同じ実装じゃねーよ
それぞれ全部細かい違いがある
すべてのプラットフォームのdiffにまで対応するなんて
大変な作業なんて誰もやろうとは思わん
716:デフォルトの名無しさん
22/10/31 20:01:01.17 oV1LtMOH0.net
例えば2004年版のdiffには-uがないからな
The Open Group Base Specifications Issue 6
URLﾘﾝｸ(pubs.opengroup.org)
717:デフォルトの名無しさん
22/10/31 20:02:19.83 J+3pjzxx0.net
>>686
> diffは環境依存するコマンド
は？
まあ仮にそうだったとして、Git内のdiffがあらゆる環境で同じdiffを生成するように小細工してるとでも？
ただまあこの場合、ぶっちゃけ、小細工出来る＝原因が分かってる≒多分Intサイズとかの違い、だから、
リモートリポジトリのマージで（俺は実際何を送ってくるのか知らんが）diffを送ってくるのなら、
それはマージ時点で鯖に問い合わせてdiffで済むかファイル本体を送らせてローカルでdiff取るかすればいいだけでしょ。
正直、原因究明して小細工するより後者の方が断然楽なので、合理的判断ならそうしてると思うけど。
>>691
前後したが上記。
>>689
その内部でマージやリベースを行う為のdiffをGNUdiffのdllコールと置き換えて、
マージやリベースが動かなくなるかって話だよ。普通に動くと思うけど。
718:デフォルトの名無しさん
22/10/31 20:03:29.56 oV1LtMOH0.net
> まあ仮にそうだったとして、Git内のdiffがあらゆる環境で同じdiffを生成するように小細工してるとでも？
同じdiffを生成するために、gitで実装してるんだろ
頭悪いのか？
依存ライブラリ（この場合はコマンドだが）を減らすのは
移植性を高めるための常識だ
719:デフォルトの名無しさん
22/10/31 20:04:11.62 oV1LtMOH0.net
OSの標準コマンドに依存したら
移植性は低くなるんだよ
常識やろ
720:デフォルトの名無しさん
22/10/31 20:08:10.94 J+3pjzxx0.net
>>692
> ユニファイド形式diffを最初に開発したのはウェイン・デイヴィソンで、
> 1990年8月のことであった（comp.sources.miscのVolume 14にunidiffとして投稿）。
> リチャード・ストールマンがGNUプロジェクトのdiffコマンドにこの機能を1ヶ月後に加え、
> 1991年1月リリースのGNU diff 1.15から使えるようになった。
> URLﾘﾝｸ(ja.wikipedia.org)
ただそれ以前に、-uがある/ないはGitでマージ出来る/出来ないにはならないだろ。
それは完全に人間用であってさ。
721:デフォルトの名無しさん
22/10/31 20:10:05.98 J+3pjzxx0.net
>>694,695
だからファイル本体をダウンロードして、mergeするマシン上でdiff取ればいいだけだろ。
これでマシン依存をなくせるし、普通の実装だよ。
通じないのか？どうもお前の書き込みは頭が悪そうだし。ならここら辺で切り上げるが。
722:デフォルトの名無しさん
22/10/31 20:15:24.67 oV1LtMOH0.net
>>696
-u がないとハンクの精度が下がるだろ
ほんとしらんならだまっとけよ
723:デフォルトの名無しさん
22/10/31 20:15:53.77 oV1LtMOH0.net
>>697
パッチファイルを受け取って
他の人がマージすることもあるだろ
ほーんと、しらんならだまっとけ
724:デフォルトの名無しさん
22/10/31 20:16:36.27 oV1LtMOH0.net
>>696
他のOSで使えるとは限らんだろうが
GNUしか頭にないんか
725:デフォルトの名無しさん
22/10/31 20:38:58.71 J+3pjzxx0.net
>>690
違うし、565からの議論は俺にとっては一部意味不明だが、正直相当不毛なのは分かる。
それはGitの構造が糞だからだ。
結局のところGitはファイルシステム上のblobツリーを管理するツールでしかない。
そしてblobが気に入らないのなら、テキストにしてしまえばいいだけで、それもまたGitでしかない。
これを理解出来ない馬鹿同士で議論してて空回りしてるだけのように見える。
具体的には、git cat-fileがblob読み出しで、対になる書き込みツールもあるはずだが知らないが、
それらを個別に交換出来れば何とでもなるだけ。PHPで一般的に使われてるPDO方式だが、
要は最終段のI/Oだけは各種取りそろえて、切り替えれば何でも出来る構造にする。つまり、
Git謹製の cat-file バイナリ：Git純正blob形式
オレオレバイナリかシェルスクリプト： Git謹製blobファイルの名前でディレクトリを作り、
その中に自分の好きな形式で突っ込んでおけばいいだけ。
XMLでもJSONでも、ただのテキストでもいい。
それらがssh用ならリモートリポジトリを読むし、DB用ならDBに格納されることになる。
最終段のI/Oを読み書きセットで交換してしまえば、その上のコードは全く同一でいけるんだよ。
繰り返すが、PHPやWebの連中は常識的にこれをやってる。(理由は複数のDBに対応する為)
それをsshは別に実装してるようだし、方針自体がかなり狂ってるよ。
LinusもDBに入れてるのを糞に言ってるが、保存先は本質ではないし、
適切なアーキテクチャであれば簡単に交換可能なものだ。
だから本来、こんな議論が発生する余地もないのだけど。
726:デフォルトの名無しさん
22/10/31 20:39:57.17 oV1LtMOH0.net
>>701
> それはGitの構造が糞だからだ。
結論ありきで理由を探すな
お前はクソな理由を一つも言っていない
727:デフォルトの名無しさん
22/10/31 20:40:47.45 oV1LtMOH0.net
以前来てたPOSIX原理主義者氏ではなく
また別のPOSIX原理主義者氏のようだなｗ
728:デフォルトの名無しさん
22/10/31 20:41:49.56 oV1LtMOH0.net
自分が認めているもの以外「全部方針が狂ってるよ」
その理由は、自分が認めていないからだよ
世界が認めていても
「俺が認めていないから世界の方が狂ってるんだよ！」
729:デフォルトの名無しさん
22/10/31 20:45:31.00 GrGctmUAM.net
POSIX原理主義はWindowsでの開発がめんどくさくなるんで本当に嫌いだわ
あと今更awkやsedの読みづらい文法覚えるより他のスクリプト言語で書いた方が楽だし、POSIX原理主義はPOSIXに慣れている奴のポジショントークにすぎないと思うね
730:デフォルトの名無しさん
22/10/31 20:46:22.02 GzQExg5g0.net
>>693
gitのバージョン管理されているファイルツリーはdiffコマンドがそのまま解釈できるような形式でファイルシステム上に存在しないからファイル単位で変換して外部関数呼び出すとか馬鹿だな
さらにgit内部で保持されるファイルの差分情報をdiffの出力みたいな字句解析が必要なバイト配列で取り扱うのも馬鹿げてる
このファイル差分抽出は間違いなくgitの核心的機能これが無ければVCSとして機能しない
731:デフォルトの名無しさん
22/10/31 20:49:18.25 oV1LtMOH0.net
>>705
POSIX原理主義者はPOSIXを理解してないよ。
732:デフォルトの名無しさん
22/10/31 20:55:34.73 GzQExg5g0.net
>>698
-uをサポートする前は、patch作るなら-cのコンテクスト形式だろ
-cなら-uとハンクの精度は変わらん
733:デフォルトの名無しさん
22/10/31 21:08:17.57 J+3pjzxx0.net
>>706
そこら辺の機能はGit以前から完全に機能してるんだよ。
> diffが作られてしばらくは、ソフトウェアコードや技術文書のマークアップのソース部分の変更箇所を比較する、
> プログラムのデバッグ出力の検証、ファイルシステム中のファイル一覧の比較といった使い方が一般的であった。
> ed用の出力により、ファイルへの一連の変更をひとまとめにしてファイル容量を節約するというアイデアが出てきた。
> Source Code Control System（SCCS）はそのようなアイデアを実装したものとして1970年代後半に実装がなされた。
> URLﾘﾝｸ(ja.wikipedia.org)
だからそれはGitのアイデアでも全然無く、Git以前からdiffとedを組み合わせれば誰でも出来る物だった。
勿論diffの出力がキモだから出来るだけ--minimumなのは目指すとしても、
それはdiffを改善すべき話で、Git本体が対応する話ではない。
てかこの辺のソフトウェア階層の話が通じないところを見ると、割と階層無しの文化＝本当にCしか知らない感じだな。
例えばJSとかでは、扱うデータの先がDBなのか、ローカルファイルなのか、メモリ上のStringなのかを
上位のコードは区別しないで済むようにコーディングすることが普通で、
と言うか実際はそうしか出来なくて、強制的にそうさせられるわけだが、
形式的には、ネットワークでもローカルファイルでもメモリ上のStringでも、
プログラミングモデル側からは全部読み書き出来る状態になってから制御が渡される。
(メモリ上に展開し終えてから渡されるイメージ、なおこれをRubyでは上手いこと遅延読み出しにしてたりするが)
CでI/Oを分離するにしても普通はそうするし、実際、Gitでもそうなってる。
でないと git log -L で全展開の倍ほどメモリ食うとかあり
734:得ないし。 最終段のI/Oは普通はそうやって上位のコードと分離するもので、Gitもcat-fileでそうなってる。 ただ、それを交換出来ないので、テキストやDBに保存したい奴に対応出来てないだけ。 これはGitの構造の問題だよ。 それでsshを別に実装しますとか、かなり馬鹿げた方針だ。 少なくともJS知ってればそうはならない。
735:デフォルトの名無しさん
22/10/31 21:09:37.44 J+3pjzxx0.net
Webの連中は馬鹿なのも事実だけど、馬鹿でも上手く行くように色々上手く出来てるのも事実なんだよ。
Ｃの連中は一度Webをやってみると凄く勉強になると思うよ。俺もそうだったし。
ただしWebはかなり糞なのも事実だが。
736:デフォルトの名無しさん
22/10/31 21:15:30.28 GzQExg5g0.net
>>709
マージやリベースでやってる差分抽出は最終段のI/Oじゃないし
C言語でシンプルに実装されてるgitをMSが作る馬鹿みたいに重いツールにしないでくれよ
737:デフォルトの名無しさん
22/10/31 21:34:40.89 GzQExg5g0.net
BitKeeperを元にGitを実装したリーナスはBitKeeper以前のVCSを糞みたいに言ってるんだよね
URLﾘﾝｸ(ezoeryou.github.io)
edとdiffを使ったようなVCSは眼中になかった
738:デフォルトの名無しさん
22/10/31 21:39:28.36 J+3pjzxx0.net
>>711
だから普通は、内部的に圧縮されたファイルへのアクセスは、
1. 単純にメモリ展開する
2. 何らかのプロキシオブジェクトでエミュレートする
のどちらかで、大概前者だしGitでもそうなってる。
だからここで速度低下とかは関係ない話だ。
(なお後者は/dev/zeroとか/dev/randomとかと言えば分かるだろう)
そこを他の言語、PHP/JS/Go/Rustのどれかを知ってれば、
そこでオブジェクトにしてI/O分離してマルチターゲットにしてしまうのも常識。
これを思いつけない/知らないのだから多分本当にCしか知らない連中だけでやってるよ。
君からもそれを感じる。
ちなみに重くなる/ならないなら、SQLiteは大量の小さいファイルならファイルよりも速いぜ！とか言ってるし、
他DBと違ってローカルだから試してみると面白いかもよ。
URLﾘﾝｸ(www.sqlite.org)
739:デフォルトの名無しさん
22/10/31 21:52:54.41 GzQExg5g0.net
>>713
内部的に圧縮されたファイル？
「ファイルツリーはdiffコマンドがそのまま解釈できるような形式でファイルシステム上に存在しない」
これを勘違いしたのかな？
ファイルじゃなくてファイルツリーね
gitのディレクトリーのツリー構造を保持する方法独特だからその各ファイルをdiff取ってもらうためにツリーをtraverseするインターフェースを提供する必要が有る
ファイル単位の差分抽出なんて複雑な処理でもないんだからそれをやってもらうためにそれよりはるかに複雑なインターフェースを設計するとか無駄以外の何物でもないな
740:デフォルトの名無しさん
22/10/31 21:54:31.60 J+3pjzxx0.net
>>712
ただそれはedとdiffが問題だったわけではないだろうし、
仮にそうだったとしても、正しくソフトウェアを構成していればすぐに交換可能で、全く問題にならないんだよ。
その辺がソフトウェア階層の意識がないなあと思うところだよ。
Cはそういう世界でもあるけどさ。
edとdiffで展開するのが駄目なら、他方式の cat-file 階層に交換してしまえば何とでもなるんだよ。
Gitの方式が優れていれば、他VCSがGitの末端階層のI/Oコードを取り込めば済むだけ。
だからそこを問題にする時点でズレてる。
例えばgzipの様なストリーミング方式の cat-file にしてもう動作するし、7zipでも何でもいいんだよ。
(バージョン管理システムの場合は個別ファイルではなくファイルセットでの圧縮なので実際はこれらは適切ではないが)
それでLinusが言ってるように、キモは
> 問題はコード量ではなくて、どのようにデータを扱うかだった。
> 初期の実際のコード量は、かなり少ない。基本的な考え方が正しいかどうかにかかっている。開発を始める前からそのアイディアについて考察していたわけだ。
であって、要はツリーコントロールであって、I/Oではないだろ。
741:デフォルトの名無しさん
22/10/31 22:11:44.63 J+3pjzxx0.net
>>714
ああ、ファイルと
742:勘違いしていたのは事実だが、それでも意味は同じだよ。 > gitのディレクトリーのツリー構造を保持する方法独特だからその各ファイルをdiff取ってもらうためにツリーをtraverseするインターフェースを提供する必要が有る 勿論その通りだが、つまりこれはファイルシステムであって、その先に隠蔽出来るんだよ。 NTFSかext4かbitlockerを使ってるか圧縮DISKかをアプリは気にしないだろ。 それはOSがファイルシステムの違いを隠蔽してくれるから。これと同じ。 同様に、 cat-file で末端のファイルの形式の違いは隠蔽出来て、 ファイルシステムドライバ（とでも言うべきか？)で、ツリー詳細構造の違いは隠蔽出来るんだよ。 そしてそれは当然Gitにも入ってる。 だからその上位からはGit形式のファイルツリー/オブジェクトツリーを 普通のファイルシステム/オブジェクトと同じように見せることは可能なんだよ。 そして実際にそうしてるはずだよ。 だからな、自分が管轄してる階層以外の所は、はっきり言って関係ないしコードからも見えないんだよ。 Cの場合はその辺の階層意識が希薄で、実際君との空回りもこれだが、Gitもこの辺は正しく実装されてるはず。
743:デフォルトの名無しさん
22/10/31 22:17:17.34 GzQExg5g0.net
>>716
cat-fileは単にblobの中身を表示するコマンドってだけで、逆をやるblobを作るコマンドが用意されてるわけじゃない
つまりここでソフトウェア的に階層がきれいに分かれてるわけじゃない
ここを置き換えて自由な圧縮アルゴリズムを使えるようになっていたとしたら
Libgit2 みたいな別実装のライブラリが出現する余地もなかっただろう
ここは変にインターフェース階層なんて用意しなくて正解
gitはツールであるとともにフォーマットでもあるんだよ
フォーマットに自由なオプションが用意されているとか別の実装を作る側としては悪夢でしかない
744:デフォルトの名無しさん
22/10/31 22:33:44.64 DiR+92tnM.net
そう、このクレーマーはGitのデータモデルやデータフォーマットとしての側面を見落としてる
確固とした優れたデータモデルを持つってのは立派なUNIX哲学の一つなんだけどねえ
745:デフォルトの名無しさん
22/10/31 22:39:17.91 h5Hfu9WR0.net
>>715
いいから、お前に git は向いてないから消えろ。git は万人向けじゃない。
自分で納得がいくものを作ってそれを使え。
どうせ多人数がかかわるようなプロジェクトとかには縁がないだろから、一人で寂しく使ってろ。
746:デフォルトの名無しさん
22/10/31 22:41:57.65 J+3pjzxx0.net
>>717
> 逆をやるblobを作るコマンドが用意されてるわけじゃない
ではなくて、用意するんだよ。
そうすれば何でも簡単に出来るようになるだけ。
実際は内部的には持っててコマンドとして公開してないだけだから、実装は簡単だし。
まあ本当にソフトウェア階層の話が通じないので困るが、もう一度懲りずに繰り返してみる。
Cで言うと、printfの先はcrt.oに繋がってるだろ。
アプリはprintfまで管轄してて、crt.oの階層は知らずに済む。
そしてcrt.oをそれぞれのマシンに用意すれば、同じソースコードが動くわけだ。(勿論コンパイル必要だが)
で、そのcrt.oをネットワーク用のにしたらssh先の端末に結果が表示され、
DB用にしたらDBにデータが格納され、
普通のcrt.oを使えば画面に文字が表示される、というだけ。
階層を導入しても苦労する事はないし、
逆にC以外の言語ではI/O階層を導入する以外の方法がない程に一般的だよ。
（と言うかC以外の言語ではI/Oを直接叩くことは一般的に出来ない）
Cは上から下まで全管轄出来るんだけど、無駄にやりすぎてるコードになりがちなのも事実。
なまじ出来るものだからやっちゃうのだけど、それは正しい構成ではないんだよ。
747:デフォルトの名無しさん
22/10/31 22:45:45.36 h5Hfu9WR0.net
>>720
糞理論いいから、まずは作って見せろ。
748:デフォルトの名無しさん
22/10/31 22:50:56.79 GzQExg5g0.net
>>720
そんな入れ替え可能な階層分けが必要なら最初から全部C言語以外で作ればよかったんだよ
でもリーナスはC言語を選んでほぼunixシステムコールを直接叩く方式で実装した
hqなんかの方がお前の好みに近いだろうけど、hqは廃れてgit全盛となった
むかしはこのスレにもhq信者が盛んにチョッカイかけに来たもんだけど、いまは何してるんだろうな
749:デフォルトの名無しさん
22/10/31 22:55:40.76 h5Hfu9WR0.net
もはや
750:名前すらちゃんと覚えてもらえてない hg さん。
751:デフォルトの名無しさん
22/10/31 22:59:10.92 J+3pjzxx0.net
>>717
あーだからな、フレームワークを一度使ってみれば勉強になると思うよ。
フレームワークは型に嵌められるのだけど、
その型はそれなりの奴が一生懸命考えた型だから、それなりなんだよ。
なるほどこうすればファイルもネットワークもDBも全部同じコードでいけるのか、とか分かるよ。
ファイルシステム構造も、末端のファイル自体も、
上位には関係ないように隠蔽出来るし、難しいことではない。
実際、Git cat-file はGitファイルシステムを隠蔽してる、とも言えるだろ。
>>722
つかなんか勘違いしてると思うが、階層を分けたら遅くなるとかではないんだよ。
(厳密に言えば関数コールが1つ入るからその分は遅くなるが)
752:デフォルトの名無しさん
22/10/31 23:00:32.54 h5Hfu9WR0.net
>>724
いいからお前は自分で作れ git 使う必要はないぞ
753:デフォルトの名無しさん
22/10/31 23:25:07.54 GzQExg5g0.net
>>724
結局gitがどういう方式で実装されているかなんてことよりファイルフォーマットの方が重要ってことだ
だからgitの実装とファイルフォーマットを切り離すようなインターフェース階層は必要無いしだれも実装しない
必要無いものを実装すれば余計なメンテの手間もかかる
754:デフォルトの名無しさん
22/10/31 23:25:57.99 Sz6pT8cp0.net
すごい勢いでスレ消費してるな…
>>676
1回のコミットで整理っていうのは、1つのコミットにまとめるってことかな？
それとも1回のコマンドで済ませたいってことかな(何度もcherry-pickしたくない)？
merge squashじゃあかんかね。
連続してない部分的なコミットをまとめるならrebase squashでもいいよ。
連続してないコミットなら、rebase -i使えばいいよ。いらないコミットはdropできるよ。
rebaseするときは、元のブランチ消えるから、必要なら復帰用にブランチ作っておくといいよ。
755:デフォルトの名無しさん
22/11/01 00:01:33.71 Jzc3CN/20.net
>>726
ファイルフォーマットというか、
Gitのキモはオブジェクトをハッシュでツリーにして管理すれば全て行けたって事だろ。
そして末端のファイルはblobだけど(既に言ったが)ディレクトリやJSONでもいいし、
中間のファイルフォーマットも実はどうでも良くて、
結局はメモリ上のオブジェクトツリーをどうやってファイルシステムにマッピングするかでしかないんだよ。
traverseさえ出来れば何も問題ないわけでさ。
例えば今のGitはハッシュ上2文字でディレクトリを作って分けてるが、
実は3文字の方が速い場合とかもあるはずだが、そこで階層を正しく切ってないと対応出来ないだろ。
まあこれについてはGitはおそらく対応出来てて、traverseエンジンは多分一つしかないから、それを交換すればいいだけ。
多分DBだとフラットの方が速い。(DB内に高性能のハッシュが実装されてる、というかDBってそれがキモなので)
或いは昔のNTFS(2000かXPの頃)だと、ディレクトリ内にハッシュがなかったので、
同一ディレクトリに20,000個とかファイルを置くととんでもなく遅くなったから、上8文字とか多めにしないと死ぬ。
この辺、つまり上何文字でディレクトリ切った方が速いかは、その下の階層のハッシュの実装によるでしょ。
こういうとき、ちゃんと階層を切ってれば、簡単に切り替えられる、ということ。
そんなの変数で～#defineで～ってのがC流かもしれんが、そういう事じゃないんだよ。
そこでぶった切ることによって、その先が、ファイルシステムであっても、ネットワークであっても、DBであっても、圧縮されてても、
要はtraverseさえ出来れば何でもいい、同じコードで走行出来るし、設定も自由に変えられるし、という自由度が得られる。
代償は関数コールが一段増えることだが、今はこれは問題にされないわけでね。
まあとにかく、後日にしようぜ。
ソフトウェアの階層の切り方についてはゆっくり考えてみてくれ。
基本的には、上記の通り、関数コールが一段増えるだけで無限の自由度が得られるだけ。
Cの場合は#defineマクロで実体を呼ぶかラッパを呼ぶか簡単に切換可能なので、
実際どうするかはともかく、
756:ソースコードはメンテしておくべきだよ。
757:デフォルトの名無しさん
22/11/01 00:33:10.99 kz7RaJ2H0.net
>>728
現状の.git/* の形式が十分にシンプル明解でこれが共通I/Fになっている
すでにこの共通I/Fに沿っていろいろな実装が存在している
結果これを変更するための内部的なI/F階層が必要とされていない
内部的な構造としてはそんなことよりSHA-1をSHA-256に変更することの方が重要で実験的実装が進んでいる
切り口が違うからお前の言うような階層をつくってもハッシュの形式の変更には対応できない
そんなくだらないことに割く労力は無い
758:デフォルトの名無しさん
22/11/01 00:33:26.41 1wY/uhrP0.net
長いからまとめたよ。
「俺は実装しないけど、俺以外の誰かが俺の推測に沿うように実装しておくべきなんだ。俺は実装しないけど。」
759:デフォルトの名無しさん
22/11/01 01:23:19.93 ju8ytuSJ0.net
なんでgitの話でフレームワークの話が出て来んのかな
760:デフォルトの名無しさん
22/11/01 01:46:22.68 Mxyz6tUC0.net
無限の自由度の代わりに組み合わせ爆発が生じてエッジケースでバグが出まくり、というのは嫌だという設計思想なんじゃないかな
確かにWeb系でDIするのは当たり前だけど、RDBMSやビジネスロジック以外はトラブってもいいWeb系と違ってgitでトラブル続発したら困るし。
ファイルシステムみたいなものでは。
761:デフォルトの名無しさん
22/11/01 01:52:53.48 Mxyz6tUC0.net
あと大体git自体が膨大なLinuxカーネルのVCSとしてかなり高速に、確実に動作する必要があったという大前提があるだろう。
そこを無視して汎用的にはこっちの方がいいってのは違うんじゃないかな。
汎用的な用途としてのVCSが欲しいならばpost-gitを作るしかないと思うよ。
762:デフォルトの名無しさん
22/11/01 02:08:49.56 QdibabTL0.net
そもそも汎用性がある方が良いというのから幻想
道具は利用目的にあっているかどうかが全て十徳ナイフありがたがるやつは素人
763:デフォルトの名無しさん
22/11/01 03:17:45.94 Jzc3CN/20.net
>>729
それも根本的に間違ってる。
ハッシュはハッシュでレイヤーを切るから、正しく構成されてるソフトウェアなら、
ハッシュを変更するのはハッシュ生成関数内だけで済むんだよ。
具体的には、全体は get_hash() を呼んでハッシュを受け取るようにしておいて、
その get_hash() 内でSHA-1かSHA-256かmd5かを変更するだけにするんだよ。
というかこんなの当たり前すぎてお前らが理解出来てないのにびびる。
オブジェクト指向では基本中の基本とされてることだぞ。
お前らプログラマじゃねえだろマジで。プログラマなら、ちょっと勉強し直さないとヤバいぜ。
ただこれは、本質的に「返ってくるオブジェクトのサイズは予想出来ない」事になり、
C的な「返ってくるオブジェクトのサイズは呼ぶ前に完全に予期出来ている（だいたい固定）」の世界にはフィットしない。
C++とかはデストラクタで、その他言語はGCで対応するのが常策だが、
これに関してはバイナリにハードコードで問題ないから#defineでいい。
ただC++だと#defineは悪とされてるから、絶対にデストラクタでやるんだ！いやスマポだ！みたいな奴も居て、
それを勧めてくるからLinusはブチ切れてるわけだが。
だけどハッシュサイズなんて動的に変化すること無いのだから、#defineで全く問題ない。
そしてそれに手こずってる時点で、#defineでの切換すら出来ない、
全体がそれぞれで勝手にSHA-1を生成してたコードになってるって事だよ。
それはマジで糞だよ。(まあ、でも直せば済む話ではあるんだけどさ)
764:デフォルトの名無しさん
22/11/01 03:19:13.38 Jzc3CN/20.net
>>732,733
これをDIと呼ぶのか？はさておき、DIでバグが増えるなんて事はないよ。
そして、get_hash()でのオーバーヘッドは関数呼び出し一回でしかなく、
それで致命的に遅くなるなんて事もないよ。
というか、
765:GitのマージってI/Oバウンドだと思ってるが違うのか？
766:デフォルトの名無しさん
22/11/01 03:55:08.59 kz7RaJ2H0.net
>>735
ただ単純にハッシュアルゴリズムをSHA-1からSHA-256に変更するわけじゃないぞ
既存のSHA-1リポジトリも全部(リベース状態にすることなしに)SHA-256で運用できるようにしたりするんだよ
gitの開発はリポジトリのフォーマットの継続性をとても重視してる
767:デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4)
22/11/01 08:06:29.98 Jzc3CN/20.net
>>737
同じだよ。
正しく構成されてる場合は何種類混在しても全く問題ないし、簡単に変更可能だ。
つかマジでそれオブジェクト指向(OOP)の基本中の基本だから。
ただ、混在なら、Cで一般的に使われてるSIZEOFの#defineでは対応出来ないが、
Linusのコードなら、Cでは一般的に禁止されてる小文字マクロで
普通にそこら辺の関数もマクロだらけの可能性があり、(linuxカーネルコードがそう）
この場合は、#define内のマクロ定義を一箇所変更するだけで対応可能ではある。
が、まあ、マクロ云々の話は本来はNGとされてて他言語では厳禁だから、いわゆる正しい方策を示すと、
全体の関数はハッシュの中身が何か知らない状態で記述するんだよ。
get_hash()でハッシュのポインタを貰いました、中身は知りませんので具体的な操作はできません、
なので一々投げ返して操作して貰いますがよろしいですね？とする。
768:デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4)
22/11/01 08:06:50.06 Jzc3CN/20.net
と書くと意味不明だが、この場合は要は貰ったポインタを一々投げ返して操作してもらう。
具体的には、
Hash* hp = get_hash(myObject); // myObjectからHashを生成して貰う、Hashの実体は何か知らない
Stream* sp = traverse(hp); // hashをtraverseに投げてstraem的な何かを示している末端のポインタを貰う、traverseはtraverse出来る何か、ファイルかDBかssh先のストレージか知らんが、とにかくtraverse出来る何かをtraverseして、末端のポインタを返す
GitObject* go = cat_file(sp); // cat_fileに末端のポインタを渡して、GitObjectを貰う
とする。これをOOP文法(Cにはないが）で一般的にはメソッドにして、
Hash* hp = get_hash(myObject); // 管理するのはhashのポインタのみ、中身は知らない
GitObject* go = hp.traverse().cat_file(); // hashを手がかりに翻訳させ、GitObjectを得る
とするんだよ。結果、全体のコードは実際のHashの中身がSHA-1かSHA-256かなんて知る必要もないし、
とにかくtraverseに投げてさらにcat_fileに投げれば、欲しかったGitObjectのポインタが得られる、という構造にする。
こうすれば、本体のコードはハッシュの種類(SHA-1かSHA-2576か)とは依存しなくなる（＝どちらでも全く同じバイナリで動かせるようになる）
そして travserseする実体がDBであったり、末端ファイルの中身がJSONであったりしても、
本体のコードはそれに依存しないから、何でも自由に選べるようになる。
本体のコードは、自身が使う GitObject の中身は知っているが、
それ以外はhashを手がかりに、treeはtraverseに翻訳させ、末端の何かはcat_fileに翻訳させ、その具体的な実体は何か知らない状態で記述するんだよ。
これは拡張性ではなく保守性を上げる為の方策だが、マジで、あおり抜きで、OOPでは基本中の基本だ。
だからフレームワークとかはこうとしか書けないように構成されてるから、一回使ってみれば上手く矯正されると思うぞ。
とにかく、このレベルが理解出来ないのはヤバイってもんじゃない。
多分OOPの授業では1日目とかのレベル。
もっとも、1日目で意味を理解出来る奴は居ないが。
だからOOPって何？みたいな質問が掲示板上でもやたらでてくるわけでさ。
769:デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4)
22/11/01 08:51:54.94 Jzc3CN/20.net
補足。
分からなければ「OOP 抽象化」でググって色々読んでみてくれ。
死ぬほどでてくるはず。マジで基本中の基本だから。
ハッシュを交換することに手こずるようなら、その『コード』は間違いなく糞だ。(Git自体が糞と言っているわけではない）
ただ、修正すればいいだけ、要は漏れなく上記のようにしてしまえばいいだけではあるが。
正しく構成すれば、Hash変更なんて簡単に出来るし、
そもそもそうなってないコードなんてOOPでは存在を許されてない。
（そうとは書けないように構成されてる。
それを
770:強制的にやらせるシステムの一つがprivateだが、これはこれで間違った使われ方も多いが）
771:デフォルトの名無しさん (ﾜｯﾁｮｲ d9e4-Xmag)
22/11/01 09:16:06.92 kz7RaJ2H0.net
長々とご苦労さんだがお前SHA-256対応の意味が理解できてないよ
772:デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4)
22/11/01 09:26:52.60 Jzc3CN/20.net
>>741
俺は以下記事の理解書いてる。
俺が書いた事の意味が分からないのは君の問題。
URLﾘﾝｸ(www.infoq.com)
ただ、初めてOOPを示されていきなり意義を理解出来る奴はほぼ居ないのも事実。
でも、君は確実に老害扱いされてると思うよ。
773:デフォルトの名無しさん (ﾜｯﾁｮｲ f15f-iYvO)
22/11/01 09:32:09.77 WFTKMpG40.net
なんだか知らんけど5chでうだうだ言ってて何になるの
774:デフォルトの名無しさん (ﾜｯﾁｮｲ d9e4-Xmag)
22/11/01 09:36:58.90 kz7RaJ2H0.net
>>742
君はその記事の意味することを理解できてないね
コミットオブジェクトの構造とか役目を理解出来てないと難しいかもしれない
775:デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4)
22/11/01 09:57:34.79 Jzc3CN/20.net
>>744
そう思いたいんだろうけど、残念ながらそうじゃない。
少なくとも君はソフトウェア階層やOOPの基本事項について全く理解出来てない。
だから今、老害と言われ続けるか、再び学び直して熟練者と言われるかの分水嶺にいるだけ。
俺は君に何も強制することは出来ないが。
確かに俺はGit初心者なので、記事の理解は間違ってるかもしれない。
でも、ハッシュの中身や長さが変わったり混在したところで、
正しく構成されてるソフトウェアなら数行の変更で対応可能なのは事実だよ。
そして君と同様の人達によってGitが作られているのであれば、
そりゃそうなってなくて苦労するんだろうさ。
まあいいけどね。もう水掛け論だから終わりにしようぜ。これ以上やってもお互い得る物もないし。
776:デフォルトの名無しさん (ﾜｯﾁｮｲ 8b8f-5UCg)
22/11/01 10:12:34.67 ju8ytuSJ0.net
> GITは、すべてのファイルオブジェクトとコミットの識別と整合性チェックをSHA-1に強く依存しています
こう書いてあるのになんで無視するんだろう
777:デフォルトの名無しさん (ﾜｯﾁｮｲ d9e4-Xmag)
22/11/01 10:29:09.24 kz7RaJ2H0.net
>>745
数行で対応ｗ
それが出来ないgithubは無能集団なんですねｗ
糞MSに買われちゃうぐらいだから仕方ないか
778:デフォルトの名無しさん
22/11/01 12:34:56.06 lDKItQe4r.net
Git初心者に語らせると頓珍漢な文章が生まれるという好例
779:デフォルトの名無しさん
22/11/01 12:39:40.93 QdibabTL0.net
>>745
お前日本語読めなさそうだな
ましてやリンク先にある英語とかかけらも理解できてないだろ
混在とかじゃないぞ。二つを同時につけて「安全」に相互変換するということだぞ
安全にすることが目的でSHA-256を使えば解決みたいな話じゃない
�
780:ｨ前みたいなのが目的と手段を取り違えるタイプの典型 OOPとかアホなプログラマでも理解できる単純なことなわけないだろ そんなんで済むならとっくに終わってる まずは常識で考えろ できないなら黙って勉強しろ
781:デフォルトの名無しさん
22/11/01 18:29:25.93 /+vO/8+o0.net
長文すげー
782:デフォルトの名無しさん
22/11/02 05:40:42.57 n+gr/3CY0.net
>>749
どうであれ同じだよ。
複数付けようが、何をどう組み合わせようが、
抽象化の向こうの実体については知らないし、取り扱うコードも存在してないから、
同じバイナリで動作するんだよ。それが抽象化と隠蔽で、これはOOPの基本中の基本。
783:デフォルトの名無しさん
22/11/02 05:41:43.29 n+gr/3CY0.net
んー、お前ら完全に化石だわ。若い奴からは確実に馬鹿にされてるよ。
というか、現在において有名OSSにこんな化石居住区が存在してたことにびっくりだわ。
>>747
数行ってのは誇張ではなく、実際にそんなもんなんだよ。
例えばMMDは3DVision対応に20-30行と言ってるが、
> そのため、樋口氏がMMDの3D Vision対応に要したのは、20～30行程度の簡単なコーディングのみだった。
> URLﾘﾝｸ(pc.watch.impress.co.jp)
この樋口氏はVer5->7でDirectX対応してて、その時もインタビュー受けてて(ググッても出てこないが)
確か「よくよく確認して、実際に変更する必要があるのは2-3行だったのでほっとしました」
とか言ってたはず。
これは特殊ケースではなく、こうなるように設計するんだよ。
これに対してGitはマニュアル見てもそういう思想が全く見あたらず、「頑張ればいいよね」で終わってる。
だから糞なソースも「頑張って」修正して何とかするんだ、のノリだ。
ソフトウェア工学はそんなのは20年前にクリアしてて、今は、
A. どうすれば変更に対して強くなるか（仕様変更があってもソースコードを変更せずに済むか）
B. どうすればそもそもソースコードを記述する必要すらなく出来るのか(全ての状況に対し同じバイナリで対応する)
C. どうすれば出来るだけ早い段階でバグを検出出来るか
とか移ってて、大体馬鹿がCに対して悪ノリしてるからLinusがこき下ろす事態になるのだが、
ABはちゃんとやらないと話にならないよ。
だからまあ、次のGitは「勉強をがんばらなくてすむGit」で、
実装で一番簡単な方法は、Gitをバックエンドに使ってシェルスクリプトでラップすることだよ。これらは既に言ったが。
でも君らは「頑張らなくちゃいけない」「頑張るべきものだ」と思っちゃってるみたいだから、
今のGitプロジェクトからはこれは出てこないだろう。
となると、上記のようにして簡単に実装したNext-Gitに成果をかっさらわれ続ける事態になると思うよ。
ちょうどGNU/Linuxの形に似てるが。
あれはLinusが悪いわけではないし、ストールマンも別になんとも思ってないようだけど。
784:デフォルトの名無しさん
22/11/02 06:01:09.34 z+vraLDY0.net
> これは特殊ケースではなく、こうなるように設計するんだよ。
> これに対してGitはマニュアル見てもそういう思想が全く見あたらず、「頑張ればいいよね」で終わってる。
それあなたの感想ですよね？
gitはソースコード1行程度で変更終わりですよ
785:デフォルトの名無しさん
22/11/02 06:03:01.35 z+vraLDY0.net
> 実装で一番簡単な方法は、Gitをバックエンドに使ってシェルスクリプトでラップすることだよ。これらは既に言ったが。
シェルスクリプトは移植性低いって分かってる？
シェルスクリプトでラップしようものなら
Linuxでは動くがFreeBSDでは動かないってことが
しょっちゅう発生する
シェルスクリプトで頑張るものじゃない
786:デフォルトの名無しさん
22/11/02 07:01:05.57 S2ENS6Jw0.net
git の一部機能は git コマンドを使ったスクリプトで実装されていたんだけど、多くのユーザーの要望に応える形でそれらのC言語化進めてる
787:デフォルトの名無しさん
22/11/02 09:34:00.28 33j+wJW8H.net
シェルでラップw
USPから悪い影響でも受けたか？
788:デフォルトの名無しさん (ﾜｯﾁｮｲ 8bbb-VzUj)
22/11/02 10:35:32.50 sFE/M4aa0.net
OOPなんて初心者プログラマ訓練ギブスってことを理解できなくてアホ理論展開しているやつがいてｗ
789:デフォルトの名無しさん
22/11/02 14:42:23.54 LlnSL/r70.net
OOPなんか、そん辺のサンデープログラマでもかなり深い所までメリットデメリット含め浸透してるがな。
関数指向やクロージャがある言語も同様で
もはや当たり前のようにハイブリッドになってて一部の原理主義者以外いい塩梅で使ってるから話題にはならん。
790:デフォルトの名無しさん
22/11/02 15:33:51.58 4T0OIw/dr.net
OOPそれほど語るなら、お前の大好きなシェルスクリプトはみんなOOP意識して作られてるのかって感じだな
791:デフォルトの名無しさん
22/11/02 18:08:31.10 mw55lzgRM.net
リーナスを中心としたOSSコミュニティの起源にタネンバウムとのモノリシックカーネル・マイクロカーネル論争があることを知らないのかな？
結果として無駄な抽象階層を積み重ねることの無意味さをLinuxカーネルの成功が証明してしまった
もちろんLinuxカーネルもファイルシステムとか必要なとこは抽象化されてるけどね
792:デフォルトの名無しさん
22/11/02 18:41:51.51 1AIcQZnX6.net
今どきの若い奴(というか最新の風潮)ってなんでもかんでもオブジェクト指向を徹底するって感じじゃないと思うけどなあ
それこそオブジェクト指向主義みたいなのが滅茶苦茶強かったのって20年前ぐらいじゃない？
WindowsもNTでマイクロカーネルにしたけどオーバーヘッドデカすぎて一部はカーネル空間に戻したりしたでしょ。
SIerの階層が深い開発なんかだとオブジェクト指向を徹底しないと事故が起こりそうだけど、そういうとこしか知らない人間なのか？
793:デフォルトの名無しさん
22/11/02 22:26:03.48 KtYxSAYnr.net
何でもかんでもシェルでやろうとするやつは病気
名前を呼んではいけないあの開発手法とか推してそう
794:デフォルトの名無しさん
22/11/03 05:47:24.09 AHw2USmo0.net
>>755
それはどのプラットフォームで問題になったの？
賢い選択とは思えないけどね。
具体的なデメリットは既に666で挙げたとおり。
俺はシェルの互換性問題なんて有ったとは思えないけど、
(昔からsh《bsh》は互換性は高かったし、今はその後継のbashで統一されてる。
ああ確かにcsh/tcsh/ksh/zshはゴミだったし死滅したよ)
それが問題なら、GitのC化ではなく、直接シェルの互換性を上げるのが常策だよ。
互換性がC化で達成出来るのなら、
既にあるbash(多分C)ソースをコンパイルしただけのものを同梱し、
gsh(=gitsh)だ！これを使え！と強弁すれば済んだろ。
なんかやっぱり無能の働き者を地で行ってる気はする。
仕事を減らす努力をしてないよね。
795:デフォルトの名無しさん
22/11/03 05:49:10.00 AHw2USmo0.net
>>758
その通りだ。だからアマチュアの樋口Pも正しく対応出来てた。
だからこそ、このスレのこれまでのやりとりに驚いている。
今時初心者でも、他言語スレでもあり得ない流れだ。
で、パッチ出てきたけど、あれでは駄目だね。
彼等はC流のメモリ管理の方法を知らず、Gitは完全に糞コードで出来てる。
あれでは他にもメモリリークだらけだよ。
(ただこれも想定内っぽいし、
リークしたところでアプリとしては大した問題でもないのも事実だが)
彼等は、バグを直す努力はしているが、
バグが出にくいコードにする努力は全くしてない。
OOPもやりすぎると問題だが、何故彼等はそうするのかを学んで、
美味しいところだけ貰えばいい�
796:ﾌにとは思うよ。 OOP原理主義者も、Gitプロジェクトやこのスレ民みたいなOOP排除原理主義者も、同様に問題だよ。
797:デフォルトの名無しさん
22/11/03 06:07:03.27 AHw2USmo0.net
ただ見る限りGit界隈は密結合主義のようだ。
つまり、Gitと知識的に密結合した、Gitに詳しい奴だけがGitを使うべきであり、
tutorial1が基本コマンドなら普通はtutorial2は応用コマンドのところ、
なんと内部データ構造の紹介になってるし、
(ただこれは俺には極めて有効に作用したが、普通はブーイングの嵐だろう)
798:デフォルトの名無しさん
22/11/03 06:07:22.90 AHw2USmo0.net
ソースコードも密結合、これは馬鹿除けだ！と言い放つ。
糞コードでもパッチの手数で勝負だ！カリスマLinusならモグラ叩き志願者は無限に募れる！
とまあ、他の誰も出来ないアプローチだね。
ただまあ、ソースコードを清潔に保つ目的は長期的メンテの為であり、
それは実際出来てるしいいだろ、と言われれば、はーそうですねー(棒)だが。
799:デフォルトの名無しさん
22/11/03 06:07:59.96 AHw2USmo0.net
これ見てたら、buggyな糞コードでもとりあえず動けば受け入れてどんどん改訂し、バグもパッチの手数で勝負するのと、
普通のプロジェクトがやってる、レビューして駄目なコードは最初からrejectするのと、
(つまり手間をかけてもrejectされる可能性があるからコードを投げるのを躊躇される)
どっちが良いのだろう？とは考えさせられるよ。
リソースが無限にあるOSSでは、前者の方がいいのだろうか？
LinusはBillJoyに対して「オープンソースを理解してない」と思ったらしいが、こういう事なのだろうか？
(この発言はLinus著作本にあるらしいが、俺は読めてない)
しかしこのアプローチでは、絶対に浄化はしない。
自分の糞を片づけるのは仕方ないとして、
他人の糞を片づけたがる奴はいないし、そもそもその界隈が掃除に価値を置いてない。
しかし糞コードならどんどん投げてもらえるし、それらを受け入れる限り、進化が止まることもない。
はーなんだかねー。なるほど研究者と色々衝突するのも分かる気はする。
そういや大昔「伽藍とバザール」読んだなーと思って今読み返してみたが、これがバザールなのか？
（NGにかかったので分割した）
800:デフォルトの名無しさん
22/11/03 10:41:57.59 NhDXzDSd0.net
それだけ文句あるなら本家MLで言うか自分で作り直してみろよ軍師様
これだけ大口叩いておいて英語のMLでコミュニケーションとれないとかだったら笑うが
Git は世界中のプログラマが使ってる最重要プロジェクトで、これが改良されるとなれば世界中から絶賛される
801:デフォルトの名無しさん
22/11/03 10:46:51.87 odT0DHDr0.net
まだやってのか
暇そうだな
802:デフォルトの名無しさん
22/11/03 13:22:38.17 AHw2USmo0.net
>>768
それは無理だね。
仮に時間が十分にあったとしても、俺が改善出来るのはソースコードであって、アプリではない。
アプリの改善には良い仕様にする事が最も重要で、実装は実は大した問題ではない。
(使う分には十分に動けばなんでも良くて、それが糞コードで出来てたから何？でしかない)
GitはLinus本人が当時のVCSの問題点を全て把握してたからいい仕様になった。
俺はそうじゃない。今の俺がやったら俺にとって都合がいいだけで、他にとっては糞な物にしかならない。
ただ実際はLinusもこれで、みんな乗り換えて来たから同じ問題を抱えていたんだろ、
という解釈らしいが、いずれにしても使い込んでる奴じゃないといい仕様には出来ないんだよ。
そして例のブランコ問題
> 顧客が本当に必要だったもの
> URLﾘﾝｸ(dic.nicovideo.jp)
803:0%E3%81%A3%E3%81%9F%E3%82%82%E3%81%AE もあり、顧客自身が実装してるんだから、そりゃ商用VCSでは絶望的に仕様的に太刀打ち出来ない。 そしてソースコード戦略も違う。Gitはコードレビューとか無い世界なんじゃないかな？ それで回るってのがスゲエが、多分これは「伽藍とバザール」の衝撃を追体験しただけなのだろう。 ソースコードを綺麗にしたら、新機能の追加が断然早くはなるけど、それは同じ人数での話で、 ここも手数で勝負だ！と来られたら、為す術もない。 ソースコードなんて糞でいいんだ、人数さえ有れば！では、研究者とは対立するよ。 なるほどエンジニアリングの天才だというのも納得ではある。 だからまあ、Gitを根本的に覆すにはGitよりも良い仕様が必要で、これは本当に難しいんだろうさ。 ところで、やはり俺のワークフローではIndexが邪魔なので削除しようと思うんだけど、 そもそもあれはどう使う為に設計されたものなのだ？ 多分Indexの存在が一番直感的でなく、『説明されてないと』間違える所だと思うんだが。 今のところadd直後にcommitしてて、邪魔でしかない状態で使ってる。
804:デフォルトの名無しさん
22/11/03 13:30:44.47 9oLRzF140.net
index stageなかったら複数ファイルの変更を一度にcommitできないじゃん。コミット粒度の問題から、全部の変更をcommitしたいわけでもないし。
どのcommitを取ってきてもちゃんと動く状態にするのが普通だからどう考えてもいるでしょ。
805:デフォルトの名無しさん
22/11/03 13:52:50.16 /4IN/B1bM.net
indexの意味がわかってない馬鹿が全然関係無いファイルをコミットしてリポジトリをブチ壊す
806:デフォルトの名無しさん
22/11/03 14:35:27.11 AHw2USmo0.net
>>771
> index stageなかったら複数ファイルの変更を一度にcommitできないじゃん。
いや普通に出来るよ。曖昧だったが、俺は git add -u; git commit -m "message"; で使ってる。
以降はワークフローの話だからどちらが正しいとかいう事ではないが、
> コミット粒度の問題から、全部の変更をcommitしたいわけでもないし。
これは若干邪道というか基本的に全部commitするものだろうし、commitしてから前に進めばいいだけで、
> どのcommitを取ってきてもちゃんと動く状態にするのが普通だから
これは俺の場合はちょっと違ってて、動かないのもcommitしてるしそれでいいと思ってるんだよ。
master/developブランチでは全部動くべきだけど、
featureでは途中のは動く必要ないし、動くようになったらdevelopにマージして消滅するんだろ？
なら特に問題ない気がする。
途中経過を記録してないことの方が問題で、記録しすぎてたら出力から間引けばいいだろ、というノリ。
だからdiffが画面１枚に収まらないようならcommitする感じ。
実際はbanchを使うのはこれからで、git flow を真似して上記のようにするつもりだが、何かまずいかな？
807:デフォルトの名無しさん
22/11/03 14:40:47.35 5PP47Osh0.net
git分からない思想も理解できないならSVN使えば？
808:デフォルトの名無しさん
22/11/03 14:46:46.91 9oLRzF140.net
>>773
そりゃgitの設計思想で想定されたコミットの仕方をしていないからindex stageがいらないと感じるだけでしょ。
大多数は設計思想通りに使っているので、index stageが必要だと理解していると思うよ。
だから、「どう使うために設計された」かと聞かれれば、gitの思想通りにコミット粒度を適度に保つためだとしか言いようがない。
「俺は違うから俺はいらない」はそれはそうだろうが、だから何？って話になる。
809:デフォルトの名無しさん
22/11/03 15:04:33.12 jVDh6EB5M.net
適当なタイミングで時系列に修正を記録していくものだと思ってる阿保には理解できないVCS
810:デフォルトの名無しさん
22/11/03 15:05:56.85 AHw2USmo0.net
>>775
git add -u を複数回して粒度を上げて動くものだけcommitしてもいいのだけど、
俺の場合は10回に1回程度は2-3回前の変更とdiff取った方が見やすいことがあって、
その場合にhash控えておくのが面倒だし、gcされてたらさらに面倒だし、gc切るのもまた邪道だろうしで、
動かないのもcommitしてfeatureの途中は動きませんと割り切るのが一番ましかと思ってる。
まあでもありがとう。
粒度調整の為ならこちらの予想の範囲内ではあった。
811:デフォルトの名無しさん
22/11/03 15:26:33.67 O+O1uzzM0.net
>>777
> その場合にhash控えておくのが面倒だし、gcされてたらさらに面倒だし、gc切るのもまた邪道だろうしで、
N個前との diff は git diff HEAD~N でハッシュを控える必要もないし gc のくだりは何のこと言ってるのかわからない。
> 動かないのもcommitしてfeatureの途中は動きませんと割り切るのが一番ましかと思ってる。
ローカルブランチなら別に構わないけど、そのノリで作られたブランチをそのままレビューするのは効率悪い。
なのでマージ前のブランチをレビュー対象とする開発では push の際に整理することになるから、
都度整理の際にインデックスはとても有用。
他にも、作業中に全然関係ない typo 直したりするのにも使える。
812:デフォルトの名無しさん
22/11/03 15:53:58.77 HnXRQ5rf0.net
index の重要性が分からないやつが git 語ってて草。
素人向けに説明すると git の役目は他人に読んでもらうやすい分かり易いパッチを仕上げること。
個人で作る分にはそれほど関係ないが共同作業するには他人への分かり易さ、見た目は最重要といっていい。
料理に例えるならフライパンやまな板のまま出すんじゃなくて、皿に盛って食べ易くしてから出すのが基本。
ワークツリーがフライパンで、インデックスが皿。フライパンからでも直接食えるけど、綺麗に皿に盛って、そこで丁寧にチェックしてから提供すれば他人の作業効率が上がる。
813:デフォルトの名無しさん
22/11/03 16:18:44.28 AHw2USmo0.net
>>778
> N個前との diff は git diff HEAD~N でハッシュを控える必要もないし gc のくだりは何のこと言ってるのかわからない。
(tutorial2を読んだだけの理解だから間違ってるかもしれんが、)
669で言ったように、Gitが分かりにくいのは業務プロセス名がコマンドに付いてるからだよ。
実際には、git add でスナップショットを取ってて、(←これが直感的に認識出来ない）
git commit でツリーの頭にそれを付け加えてるだけ。
だからaddしてないと付け加えるべきスナップショットがないからコケる。
それで、>>103-107、stashしてたら何処かに存在してるし、
実はaddした時点で保存されてるから、こちらもgcが行われる以前ならhashさえ分かれば引っ張ってくることが可能。
ただし次のaddでindex先が切り替えられてダングリングになり、gc対象になるから、
存在してるかどうかはgcの動作具合による。
(だから初心者向けには、git add でスナップショットが取れてるなんて死んでも言えないし、余計に分かりにくくなってる）
俺が粒度を上げるのなら、commitせずに複数回addする事になり、
2回以上前のはツリーから外されてるのでHEADからでは辿れない。(git fsckなら探せるはずだが)
だから動かない物もcommitしてHEADから辿れるようにしようとしている。
まあちょっと書き方が悪かったかもしれんが。
なので、実際の動作は git add 改め ss (take SnapShot)、git commit 改め relinkなのだけど、
ついでに relink もリストラして ss (git add -u; git commit) と ss -m "message" (git add -u; git commit -m "message")でいい。
これなら alias ss='git add -u; git commit' で済むし、
直感的になってアホでも使える。コミットメッセージが空なら動かない。
これが俺流の「勉強しなくていいGit」だよ。Indexよさらば。アホ向けGitこんにちは。
> マージ前のブランチをレビュー対象とする開発では push の際に整理することになるから
本体リポジトリとルールが違うと収まりが悪いのは了解した。
> 他にも、作業中に全然関係ない typo 直したりするのにも使える。
なるほどこれは微妙に便利かも。
(しかし俺流アホ向けgitでもこれは問題なく出来る。何せgitコマンドはスルーだからな)
814:デフォルトの名無しさん
22/11/03 16:20:05.12 AHw2USmo0.net
>>779
いやレビュー対象はcommit済みで、index上ではないだろ。
815:デフォルトの名無しさん
22/11/03 16:22:38.83 5PP47Osh0.net
うんうんわかった
大人しくSVN使え
その方が君には向いている
816:デフォルトの名無しさん
22/11/03 17:18:17.27 NhDXzDSd0.net
>>781
779はindex上でレビューするんじゃなくて、indexにいれた状態にしてからdiff --cachedでcommit前の確認をするってことじゃない？自分もそれやるよ
817:デフォルトの名無しさん
22/11/03 17:50:52.37 e1pojM/n0.net
>>763
> (昔からsh《bsh》は互換性は高かったし、今はその後継のbashで統一されてる。
> ああ確かにcsh/tcsh/ksh/zshはゴミだったし死滅したよ)
FreeBSDにはbash入っとらんぞ
818:デフォルトの名無しさん
22/11/03 17:52:28.68 e1pojM/n0.net
>>763
> 既にあるbash(多分C)ソースをコンパイルしただけのものを同梱し、
> gsh(=gitsh)だ！これを使え！と強弁すれば済んだろ。
bashだけじゃ足らんだろ
GNUコマンドも全部入れなきゃな！
819:デフォルトの名無しさん
22/11/03 17:53:10.48 e1pojM/n0.net
>>770
> 仮に時間が十分にあったとしても、俺が改善出来るのはソースコードであって、アプリではない。
だからソースコードを改善しろってｗ
820:デフォルトの名無しさん
22/11/03 18:10:35.38 3fLLADP3M.net
>>784
macもbsahやめたんだよね
GPLから逃げるために
821:デフォルトの名無しさん
22/11/03 19:01:05.13 AHw2USmo0.net
あと実は、masterの意義も分からないのだが。俺の場合は、
master: 今現在Web上で公開しているもの
develop: 今現在ローカル上でテストしているもの
feature: 今現在変更中のソースコード
と3つポインタが必要なのは分かる。
しかし、masterは常にdevelopとfast-forwardマージするなら、developにタグ打てば済む。
途中からのbranchも可能だし、hotfixするにしても問題ない。
branchケチる意味もないのも分かるが、それにしても無駄に多い気もする。
と思ってたら、俺にはサル先生方式位が適切な気がしてきた。
> ここでは統合ブランチとトピックブランチという二種類のブランチを使った運用方法について紹介します。
> URLﾘﾝｸ(backlog.com)
サル先生方式の統合ブランチにタグ打つだけと比べて、
masterとdevelopとして別に持っておいたら何が嬉しいの？
822:デフォルトの名無しさん
22/11/03 19:03:24.24 AHw2USmo0.net
>>784
>>787
政治的案件をOSS側がフォローする必要ないと思うが…
823:デフォルトの名無しさん
22/11/03 20:29:42.55 e1pojM/n0.net
>>789
なに政治的案件の話にすり替えようとしてるんだよ
gitは環境依存が激しいシェルスクリプトに依存しないように
C言語で書いてるって話をしていただろ
824:デフォルトの名無しさん
22/11/03 20:33:17.75 e1pojM/n0.net
>>788
1系、2系の同時開発とかあるやろ
825:デフォルトの名無しさん
22/11/03 20:41:00.73 vXMSDhes0.net
.gitignoreの書き方で質問
app.log, app.log.1, app.log.2みたいな感じで増えていくログファイルを無視したいのですがどう書けばいいですか？
826:デフォルトの名無しさん
22/11/03 20:41:54.93 5PP47Osh0.net
>>788
なんだやっぱりブランチのことすら分かってなかったのか
827:デフォルトの名無しさん
22/11/03 20:48:29.66 5fumPTTR6.net
>>792
*.log* でなにか被ったりする？
828:792
22/11/03 20:58:19.76 vXMSDhes0.net
logフォルダ作ってそれを無視することにしました
>>794
ごめんなさい！
829:デフォルトの名無しさん
22/11/03 21:00:04.22 AHw2USmo0.net
>>791
あ、なるほど了解。
逆に言えば、同時開発する気がなければ要らないわけだな。
830:デフォルトの名無しさん
22/11/03 21:04:46.26 e1pojM/n0.net
>>796
今自分で「必要だ」って言ったってこと理解してるかい？
831:デフォルトの名無しさん
22/11/03 21:15:11.85 AHw2USmo0.net
>>790
C化しただけで環境依存が無くなるのなら、既にC化されてるbashでいいだろ。
Cコード上で何か小細工が必要なら、それは「互換性を上げる」名分でbashにcontributeすべきで、
Git側で吸収する案件ではない。
GPLから逃れたいってのも意味が分からん。
bashのコードを改変して新機能追加してmac_bachにしたら、そのコードを公開しないといけないが、
普通にbashを使って作業するだけなら関係ないから使えばいいだけ。
何か思惑有るんだろうけど、Gitがソースを汚してまでフォローする案件じゃないだろ。
> また、これ以外にも zsh や bash などのシェルが FreeBSD Ports Collection から利用可能です。
> https://