Git 18

[表示 : 全て最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2ch.scのread.cgiへ]
Update time : 08/13 17:55 / Filesize : 365 KB / Number-of Response : 1056
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

Git 18

1 名前：デフォルトの名無しさん [2022/04/23(土) 03:25:45.27 ID:HOOXt/T30.net]: ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。

Git - Fast Version Control System
git-scm.com/

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

◆前スレ
Git 16©2ch.net
https://mevius.5ch.net/test/read.cgi/tech/1502726047/
Git 17
https://mevius.5ch.net/test/read.cgi/tech/1599016710/
VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured
652 名前：デフォルトの名無しさん mailto:sage [2022/10/16(日) 04:55:55.59 ID:kNlIrq3k0.net]: 間違えた、すまん
653 名前：デフォルトの名無しさん mailto:age [2022/10/19(水) 13:19:13.07 ID:1sfAoeRGa.net]: Git v2.38.1
654 名前：デフォルトの名無しさん mailto:sage [2022/10/27(木) 07:22:57.17 ID: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 名前：デフォルトの名無しさん mailto:sage [2022/10/28(金) 00:23:09.45 ID:yz6FOYrM0.net]: LooseCompressionの全展開用の領域 2MB*2800=5.6GB
git logは内部でlessにパイプでデータを渡してるから
パイプバッファも含めて約2倍だろうか
Packしなけりゃ少しはマシかもしれない(未確認)
656 名前：デフォルトの名無しさん mailto:sage [2022/10/28(金) 07:15:31.79 ID: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 名前：デフォルトの名無しさん mailto:sage [2022/10/28(金) 07:18:13.37 ID:RikIMzkC0.net]: 報告してあげるといい事案だと感じる
658 名前：デフォルトの名無しさん mailto:sage [2022/10/29(土) 06:39:27.49 ID: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 名前：デフォルトの名無しさん mailto:sage [2022/10/29(土) 08:37:46.51 ID:e5vmfD+T0.net]: >>637
HEAD~100 とかじゃ駄目なの？
660 名前：デフォルトの名無しさん mailto:sage [2022/10/29(土) 08:44:53.54 ID:+5EirK6r0.net]: いやバグレポートすればいいと思う
661 名前：デフォルトの名無しさん mailto:sage [2022/10/29(土) 09:15:13.77 ID:J4pkDf7Q0.net]: >>638
実はそこは初心者過ぎてよく知らないんだわ。
git log HEAD~100
では制限出来なかったけど、どう書くべきなの？

とりあえず公式マニュアルでは -n が最初に載ってるので、-n が一番お手軽なのだと思う。
これが効かないのは、多分実装忘れじゃないかと。
> https://www.git-scm.com/docs/git-log

>>639
多分、メモリ大量使用は仕様で、-n が効かないのはバグだね。
662 名前：デフォルトの名無しさん mailto:sage [2022/10/29(土) 09:25:26.30 ID:+5EirK6r0.net]: 合理性のないメモリ使用があるなら実害があるユーザーが改善のリクエストをバグレポートで出せばいい
そういうもん
レアケース扱いされることもあれば皆が困ってるようなら優先的にチューニングされる
仕様なのでは！？と空気読んで黙ってるのは奥ゆかしいニンジャ精神
663 名前：デフォルトの名無しさん mailto:sage [2022/10/29(土) 09:38:02.85 ID:J4pkDf7Q0.net]: >>641
なるほどその通りだ。
ガイドラインが糞長げえ…orz が、数日のうちにレポートする方向でやります。
> https://www.chiark.greenend.org.uk/~sgtatham/bugs.html
> https://www.git-scm.com/community 内の this guide が上記
664 名前：デフォルトの名無しさん [2022/10/29(土) 11:09:21.06 ID:+W9Ulup+0.net]: >>640
手練れのエンジニアとお見受けするが、どのジャンルで仕事されているので？
665 名前：デフォルトの名無しさん mailto:sage [2022/10/29(土) 15:16:52.52 ID:e5vmfD+T0.net]: >>640
HEAD~100..HEAD みたいなのを最後につけてレンジを制限する話だけど効かない？
666 名前：デフォルトの名無しさん [2022/10/29(土) 21:10:22.54 ID:YQqcaKMe0.net]: git log -100 じゃなくて？
667 名前：デフォルトの名無しさん mailto:sage [2022/10/29(土) 23:05:25.26 ID:e5vmfD+T0.net]: >>645
-100 と -n 100 と --max-count=100 は同じ意味で表示するログの数を制限する
A..B はログを検索する対象を制限する。(Bには存在するけどAには存在しないコミットという意味になる）
668 名前：デフォルトの名無しさん mailto:sage [2022/10/30(日) 02:06:46.88 ID:IOU525bY0.net]: >>644
効いた！ありがとう。

何ぞそれ？と思いきや git log のdocumentの頭に書いてあるのな。
> https://www.git-scm.com/docs/git-log
gitは機能が多すぎてドキュメントがやたら長いので端折っていたのが敗因だ。
やはり最初は一通り読まないと駄目だな。

これなら回せばいいので、組んでみたら32bit環境で43秒で終了した。
これだと高速化チューニングではなく単にfree忘れっぽいのでレポートしておいた。
再現用のスクリプトも同梱してるから気になる人はどうぞ。
https://lore.kernel.org/git/CAFOPqVXz2XwzX8vGU7wLuqb2ZuwTuOFAzBLRM_QPk+NJa=eC-g@mail.gmail.com/T/#u
669 名前：デフォルトの名無しさん mailto:sage [2022/10/30(日) 09:36:57.12 ID:b5HYhcbp0.net]: >>647
おつかれ。
慣れてくると git log とかは全ログ対象にはしなくて、素でレンジ指定するので、この手のリソース問題は見つけ難いんだよな。
670 名前：デフォルトの名無しさん mailto:sage [2022/10/30(日) 12:37:33.31 ID:IOU525bY0.net]: >>648
初心者は意味不明な使い方を無自覚でやるから、どうしてもマイナーバグに当たりやすい。
なるほどタグを付けてgit logでは範囲指定がデフォか…
ってそのままtutorialに書いてあったわ。やっぱちゃんと読まなきゃ駄目だったorz
> https://www.git-scm.com/docs/gittutorial
つまるところ、今までこんな馬鹿げた使い方をした奴は居なかっただけだな。
671 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4) mailto:sage [2022/10/30(日) 18:58:14.60 ID:IOU525bY0.net]: git diff の出力はデフォでpatchになってるのだが、これどうやったら切れるんだ？
> https://www.git-scm.com/docs/git-diff#Documentation/git-diff.txt--p

既にフォーマッタを持っているので、
unixコマンドのdiffのデフォルト出力と同じ物が
672 名前：欲しい。 切るオプションも無いし、下の方のCONFIGURATIONにもそれらしい設定が見つからない。 diff.externalでdiffごと入れ替えないと駄目とかいうクソ仕様？ -s や --no-patchでは出力そのものが出なくなる。ただし > or to cancel the effect of --patch. と書いてあるから、かつては--no-patchではdiffのデフォ出力で、-sで出力無しだった気配はあるが。 []: [ここ壊れてます]
673 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 8bbb-VzUj) mailto:sage [2022/10/30(日) 21:37:56.23 ID:b5HYhcbp0.net]: >>650
git diff は git diff 形式 (unified diff 形式の変形) で出力される。それ以外の形式が欲しい場合は外部コマンド使うしかない。
674 名前：デフォルトの名無しさん mailto:sage [2022/10/30(日) 22:10:12.22 ID:IOU525bY0.net]: >>651
マジかー。クソ過ぎ。仕様考えた奴馬鹿すぎ。
スクリプトに食わす為に先頭の+-の文字を変更するオプションとかあるのだけど、
これでいいと思った奴は死ねだな。
675 名前：デフォルトの名無しさん mailto:sage [2022/10/30(日) 22:14:38.98 ID:b5HYhcbp0.net]: >>652
git はパッチ管理システムなんだから、それ以外が考慮されてると思う方が贅沢。
676 名前：デフォルトの名無しさん mailto:sage [2022/10/30(日) 22:34:52.61 ID:IOU525bY0.net]: >>653
いやそうじゃねえ。というかこれはソフトウェアの構成を間違ってるよ。

diffだってバグはあるのだから、内製は止めて、普通にdiffのdllをコールすべきなんだよ。
GitはLinusが1日で作ったらしいし、最初はどう考えてもそうなっていたはず。
だから俺は config の中にデフォで diff -u みたいなエイリアスがあるのかと思ってた。
diffを内包する事に、何のメリットもない。

この名残がexternal driverで、それが使えればいいという事なのだろうけど、
ご丁寧にこれを禁止するオプションまである。(-no-ext-diff)
多人数の開発では、同じ画面を見ていた方が何かと楽だから、揃える方向で努力するのはごもっともだが、
禁止するのは違う。どこかでおかしな思想が混入しているよ。

そもそも、それ以外を考慮しない＝外部コマンドで十分出来る事はdllを呼ぶ、であって、
この構成だとGitがdiffも構成してるから、君は認識を間違ってる。
Gitは明らかにおかしい方向で無駄な事をやってしまっている。
そしてそれは君の価値観的にもNGなはずだよ。
677 名前：デフォルトの名無しさん mailto:sage [2022/10/30(日) 23:37:53.37 ID:b5HYhcbp0.net]: >>654
Linus のこと知ってるのなら長文書く前に調べろ。
git 作る以前から、みんなが勝手なフォーマットでパッチ送って来るのは非常に困るので推奨のパッチ形式を決めてあったんだよ。
で git 作る時に強制的にその形式に統一されるようにした。どうしても他の形式で出したい場合はひと手間かかるのが設計意図どおり。
678 名前：デフォルトの名無しさん mailto:sage [2022/10/30(日) 23:53:15.06 ID:LXgcbV870.net]: Linusも言ってたような気がするけど、気に食わなければ自分で作れ
以上
679 名前：デフォルトの名無しさん mailto:sage [2022/10/30(日) 23:58:47.31 ID:IOU525bY0.net]: >>655
Linusはデフォを -u にして、patch送るならオプション無しで送れ、としただけでしょ。
これは間違ってない。
問題は、元のdiffの形式の出力が出来なくなってる事だよ。
オプションで出来るよ、でよかっただけ。

オプションすら禁止なら、今のgit diff に各種出力オプションがあること自体が君的に矛盾するだろ。
何故君がそんな意味不明なポジショントークをするのか分からないが、
Gitが方針を間違ってるのは事実だよ。
オプション禁止なら、git diff にオプションを何一つ付けてはいけない。
(仮にこれであれば、賛同はしないが理解はする）

ただまあ、ドキュメントの雰囲気だと、
おそらく昔は --no-patch で元のdiff形式が出せたのではないかと推測される。
君がどこまで知っているのか知らないけど、多分君の歴史理解も間違ってると思うよ。
680 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 00:04:41.05 ID:h5Hfu9WR0.net]: >>657
お前以外は誰もオプションとか必要ないから作ってないだけだよ。むしろ邪魔。どうしてもやりたければ外部コマンド指定でできるんだからオプションとかでやるよりよっぽど汎用性がある。
オープンソースなんだからオプション必要ならお前が自分でつくればいい。
681 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 00:08:19.51 ID:h5Hfu9WR0.net]: あと－－no-patch には昔からパッチ出さない機能しかないぞ。頭悪い推測とかする暇があったら過去のソース確認してこい。
それこそ git で調べればすぐだぞ
682 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 00:21:01.40 ID:J+3pjzxx0.net]: >>859
そうか？ならマニュアルの
> to cancel the effect of --patch
の部分は明らかに不要だから削除要請出しといてくれ。

というか君の「昔」がどれ位か知らんが、Linusの言ってた？フォーマットが統一されてないってのは、
diffの各種オプションではなく、edやsharに対してだと思うぞ。
683 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 00:43:54.22 ID:h5Hfu9WR0.net]: >>660
不要だと思ってるのはお前だけ。その思い込みが勘違いの原因だろ。
684 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4) mailto:sage [2022/10/31(月) 07:08:10.92 ID:J+3pjzxx0.net]: 色々確認したが、Gitの現状認識としては651であってるっぽい。
そして外部ツール使うしかないが、これは環境設定無しでコマンドだけで出来る。（動作確認済み)
git difftool --extcmd=/usr/bin/diff <commit> <commit>
> https://qastack.jp/programming/255202/how-do-i-view-git-diff-output-with-my-preferred-diff-tool-viewer

ついでにその中、
> Gitについて学ぶほど、それは1人の人、つまり元のプログラマーのために作られたものだと感じます。
これもよく言われてるようだが、俺も今回の件で同意だ。
合理性に欠ける判断をしているのだから色々文句言われるのも当然だ。
ただLinusは自分用に作った物を公開したら勝手に使われてるだけだから、知ったこっちゃ無いってのも分かる。
ただそれならそうと、いつもの調子でドキュメントにも書いててくれないと困るね。
合理的な構成を推定すると迷子になってしまう。

俺は絶対に diff -u 以外のフォーマットを許さない！絶対にだ！

とか書いてあれば、最初から諦めるので無駄に探す必要はなかった。
俺はLinusのこういった感情的な部分はわりと好きなのだが、まあ昨今の code of conduct では書いても消されるんだろうけども。
685 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 10:11:41.92 ID:J+3pjzxx0.net]: てかGitってまさかのモノリシックかよ！
こりゃ文句言われるのも分かるわ。完全に方向を間違ってる。
結果的に肥大化していったのだろうけど、現在の状況でこれは駄目だよ。

つかこれシェル化する方向のプロジェクトはないの？
子コマンド群のバイナリだけ貰いたいんだけどさ。
686 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 10:39:47.64 ID:sko8U7ef0.net]: >>663 好きに fork しなよ。
687 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 12:23:13.35 ID:h5Hfu9WR0.net]: 自分でやってみればいいよ。
自分で多数の人が参加する巨大なプロジェクトを管理するようになれば、形式が統一されていることがどれだけ重要かわかる。
仕様を強制されているようでも、これこそが git の使い易さ、戦闘証明済の実力だと気付くよ。空想と現場は違う。
688 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 13:21:07.66 ID: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 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 14:15:23.19 ID:Yrczlr02M.net]: Simple is not easy
Gitは後者を選択することでSIerのドカタまで幅広く受け入れられたということだ
691 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 14:29:14.51 ID:Pk1WyFqz0.net]: (だからgit difftoolが用意されてんだろと言いたいけど、linux原理主義者みたいだし黙っとこう)
692 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4) mailto:sage [2022/10/31(月) 15:04:18.65 ID:J+3pjzxx0.net]: >>667
他よりましなだけだろ。

ただ俺が思うに、Gitはもっと簡単に出来て、
・勉強しないといけないGit(今)
・勉強しなくてもなんとなく使えちゃうGit(次世代)
に分離すると思うよ。次世代版の需要圧力はもう既に十分あるし。

実のところ、今のgitにラッパシェルスクリプト群を被せれば次世代版出来ちゃうし、
(勿論見た目だけだがそれが重要)
俺はそれ作って使おうかとも思案中。
Gitは業務プロセス名のコマンドだから、実際何が起こっているのか分かりにくいのが一番の問題だよ。
コマンド名変えるだけでも相当変わる。
693 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4) mailto:sage [2022/10/31(月) 15:05:02.85 ID:J+3pjzxx0.net]: >>668
それに辿り着くのにググったりマニュアルを読まないといけないのが問題なんだよ。
今のGitは世界中のプログラマに努力を強いてて、その犠牲の上に成り立ってる。

3時間程度あれば、再現コード付きのバグ報告が出来てしまう。
それをマニュアルを読むのに費やしてるのだから、無駄でしょ。
世界中のプログラマが3時間を世界が進歩する方向に費やせたら、Gitももっとよくなってたはずだよ。
694 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 15:39:10.00 ID:oV1LtMOH0.net]: それは世界中の人が俺に1円を恵んでくれたら
俺は大金持ちになっていたと言っているようなもんだな
695 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 15:57:50.61 ID:h5Hfu9WR0.net]: >>670
もっと良い物ができると主張するんなら作って広めてから出直してこい

もともと git を使ってきたやつらがどういう連中かわかって無さ過ぎ
linux カーネルコミュニティとか、文句言ってる暇があったらコード書いて変更した方が速いってやつらばかりだぞ
そういう連中がのべ何万人も十年以上使い続けた結果で今の仕様になってる。本当に問題だったら誰かがとっくに直してる

お前にはこの言葉を贈ろう「馬鹿でも使えるものは馬鹿しか使わない」
696 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 16:18:24.02 ID:SCCWpcRv0.net]: gitにdiffの書式の多様性を求めるなら、自分が使ってるコマンドの方を多様性を受け入れるようにすれば良いんじゃね
697 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 16:37:40.55 ID:GzQExg5g0.net]: gitにとってファイルの差分を抽出する機能は、単にユーザへ表示したりパッチをつくるだけじゃなくて、gitの特徴的なマージやリベースを実現するための核心的機能なんだよ
なので専用のものを内製する意味はある
698 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 18:09:11.73 ID:J+3pjzxx0.net]: >>671
OSSが世界中のプログラマからの元気玉なのは事実だろ
元気をマニュアルに消費されてなければ、もっと大きな元気玉になってただろうよ
699 名前：デフォルトの名無しさん [2022/10/31(月) 18:20:34.93 ID:5K9TC9u30.net]: 初歩的な質問ですが教えてください。
コミットの履歴が汚くなった場合、皆さんはどのように管理されてますでしょうか？

具体的には、
gitでdevelopからブランチを切ったAで作業しました。

ブランチAのコミット履歴が汚くなったので
新たに作成するブランチBにブランチAで変更したファイルを
一回のコミットで整理したいです。

git cherry-pick -n fromID..toID
などで整理しているのでしょうか？
700 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 18:28:03.00 ID:oV1LtMOH0.net]: >>675
タラレバ
701 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 18:33:43.29 ID:J+3pjzxx0.net]: >>672
> のべ何万人も十年以上使い続けた結果
それは言いすぎ。カーネルコミュニティって400人規模と聞いた覚えがある。
毎年全員入れ替わっても1万人規模だよ。
まあこれは本質ではないのでいいが。、

> 「馬鹿でも使えるものは馬鹿しか使わない」
これって誰の言葉だ？Linusが
> マジで、Cを選択する理由が「何もなかった」としてもだ、C++プログラマー避けになるというだけで、Cを使う大義名分になる。
> https://cpplover.blogspot.com/2013/05/linus-torvalsc.html
と言ってるのは知ってるが。（しかもこれはGitの話らしい）
ちなみに俺はLinusの意見にも賛同する。プロジェクトに馬鹿が混入しないことは本当に重要なことだ。

ただ君と根本的に違うのは、「簡単は正義」と思ってることだ。
簡単に出来るのなら、簡単な方がいい。
馬鹿をふるい落とす為に敢えて難しい構造やコードにすることはない。
俺が見る限りLinusもそうしているわけではないが、君がそうしたいのは理解した。

まあ機会があれば実装して広めることになるかもしれない。
ただ俺は別のことをやろうとしてるから、Gitなんて動けば何でもいい程度でしかないので、優先順位は極めて低い。
あとたぶん、君は
> 文句言ってる暇があったらコード書いて変更した方が速い
の意味を誤解している。が、これは今言っても通じないと思う。
702 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 18:41:18.26 ID:oV1LtMOH0.net]: 小１「掛け算よりも足し算のほうが簡単だ！」
703 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 18:42:37.79 ID:oV1LtMOH0.net]: しょう１「かけざんよりもたしざんのほうがかんたんだ！かんじよりもひらがなのほうがかんたんだ！」
704 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 18:50:02.57 ID:sko8U7ef0.net]: >>678
> ただ俺は別のことをやろうとしてるから、Gitなんて動けば何でもいい程度でしかないので、優先順位は極めて低い。
これまでの開発者を含めて他の人もそうだっただけという可能性に思い至れば何の不思議もないことなのに。
705 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 18:50:46.86 ID: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 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 19:41:41.79 ID:oV1LtMOH0.net]: え？まさかgit diffを差分を見るだけのツールだと思ってるの？
708 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 19:42:41.80 ID:oV1LtMOH0.net]: GNU diffに依存したら、GNU diffが使われないところで
動かないってわからんかなぁ
diffは移植性低いんだよ？
709 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 19:49:40.38 ID: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.
> https://www.git-scm.com/docs/git-diff
このオプションが相当にヤバい。
これはデフォで

diff | less

となってる部分を、

diff --output-indicator-new='>' | less

とすれば幸せになれますよ、ということだが、これは

diff | sed 's/^\+/>/' | less

とすれば出来ることなので、gnuにこれを提案しても当然「そんなんイラネーよ」で終わってしまう。
Cで実装すべき案件ではないから。
そこで何故断られたのかを理解せず、だったらforkしますのノリなので、完全に無能の働き者だよ。
多分こいつらは本当にCしか書けない、Cしか知らない連中だ。
sed/awk/perl/python/rubyのどれかでも少しでも出来れば、この発想にはならない。
コントリビューターがこれを出してくるのも、メンテナがこれを止めないのも狂ってる。
プロジェクトにはいまだに正規表現を書けない老害しかいないと分かる。
だからこのオプションは、Linus的に言えば、常識的なプログラマー除けにはなってしまってるだろうよ。
710 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 19:51:14.64 ID:oV1LtMOH0.net]: git diffはパッチファイルを作るために利用されるし、
diffは環境依存するコマンドなんだから、
そんなのに依存したら、gitの移植性が低くなる

別の環境で実行したら、diffコマンドの出力がおかしくて
正しくパッチ当てられませんとかなったら困るやろ
常識で考えろや
711 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 19:53:03.45 ID:oV1LtMOH0.net]: >>685
> とすれば出来ることなので、gnuにこれを提案しても当然「そんなんイラネーよ」で終わってしまう。
あのさぁ、提案するのはGNUだけじゃだめだって理解してないの？
712 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 19:53:31.39 ID:J+3pjzxx0.net]: >>684
どういう意味？
少なくともどのプラットフォームにもdiffはあるだろ。
713 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 19:56:13.88 ID:GzQExg5g0.net]: >>682
diff.externalやdifftoolによる置き換えは差分表示に使うdiffを置き換えるだけで、git内部でマージやリベースを行うための差分抽出には使わないだろ
714 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 20:00:09.03 ID:9mfNegYM0.net]: ん?
これはもしかして以前来てたPOSIX原理主義者氏か?
715 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 20:00:09.25 ID:oV1LtMOH0.net]: >>688
全部同じ実装じゃねーよ
それぞれ全部細かい違いがある

すべてのプラットフォームのdiffにまで対応するなんて
大変な作業なんて誰もやろうとは思わん
716 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 20:01:01.17 ID:oV1LtMOH0.net]: 例えば2004年版のdiffには-uがないからな
The Open Group Base Specifications Issue 6
https://pubs.opengroup.org/onlinepubs/009604499/utilities/diff.html
717 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 20:02:19.83 ID:J+3pjzxx0.net]: >>686
> diffは環境依存するコマンド
は？
まあ仮にそうだったとして、Git内のdiffがあらゆる環境で同じdiffを生成するように小細工してるとでも？

ただまあこの場合、ぶっちゃけ、小細工出来る＝原因が分かってる≒多分Intサイズとかの違い、だから、
リモートリポジトリのマージで（俺は実際何を送ってくるのか知らんが）diffを送ってくるのなら、
それはマージ時点で鯖に問い合わせてdiffで済むかファイル本体を送らせてローカルでdiff取るかすればいいだけでしょ。
正直、原因究明して小細工するより後者の方が断然楽なので、合理的判断ならそうしてると思うけど。

>>691
前後したが上記。

>>689
その内部でマージやリベースを行う為のdiffをGNUdiffのdllコールと置き換えて、
マージやリベースが動かなくなるかって話だよ。普通に動くと思うけど。
718 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 20:03:29.56 ID:oV1LtMOH0.net]: > まあ仮にそうだったとして、Git内のdiffがあらゆる環境で同じdiffを生成するように小細工してるとでも？

同じdiffを生成するために、gitで実装してるんだろ
頭悪いのか？

依存ライブラリ（この場合はコマンドだが）を減らすのは
移植性を高めるための常識だ
719 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 20:04:11.62 ID:oV1LtMOH0.net]: OSの標準コマンドに依存したら
移植性は低くなるんだよ
常識やろ
720 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 20:08:10.94 ID:J+3pjzxx0.net]: >>692
> ユニファイド形式diffを最初に開発したのはウェイン・デイヴィソンで、
> 1990年8月のことであった（comp.sources.miscのVolume 14にunidiffとして投稿）。
> リチャード・ストールマンがGNUプロジェクトのdiffコマンドにこの機能を1ヶ月後に加え、
> 1991年1月リリースのGNU diff 1.15から使えるようになった。
> https://ja.wikipedia.org/wiki/Diff
ただそれ以前に、-uがある/ないはGitでマージ出来る/出来ないにはならないだろ。
それは完全に人間用であってさ。
721 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 20:10:05.98 ID:J+3pjzxx0.net]: >>694,695
だからファイル本体をダウンロードして、mergeするマシン上でdiff取ればいいだけだろ。
これでマシン依存をなくせるし、普通の実装だよ。

通じないのか？どうもお前の書き込みは頭が悪そうだし。ならここら辺で切り上げるが。
722 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 20:15:24.67 ID:oV1LtMOH0.net]: >>696
-u がないとハンクの精度が下がるだろ
ほんとしらんならだまっとけよ
723 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 20:15:53.77 ID:oV1LtMOH0.net]: >>697
パッチファイルを受け取って
他の人がマージすることもあるだろ
ほーんと、しらんならだまっとけ
724 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 20:16:36.27 ID:oV1LtMOH0.net]: >>696
他のOSで使えるとは限らんだろうが
GNUしか頭にないんか
725 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 20:38:58.71 ID: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 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 20:39:57.17 ID:oV1LtMOH0.net]: >>701
> それはGitの構造が糞だからだ。
結論ありきで理由を探すな
お前はクソな理由を一つも言っていない
727 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 20:40:47.45 ID:oV1LtMOH0.net]: 以前来てたPOSIX原理主義者氏ではなく
また別のPOSIX原理主義者氏のようだなｗ
728 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 20:41:49.56 ID:oV1LtMOH0.net]: 自分が認めているもの以外「全部方針が狂ってるよ」
その理由は、自分が認めていないからだよ

世界が認めていても
「俺が認めていないから世界の方が狂ってるんだよ！」
729 名前：デフォルトの名無しさん [2022/10/31(月) 20:45:31.00 ID:GrGctmUAM.net]: POSIX原理主義はWindowsでの開発がめんどくさくなるんで本当に嫌いだわ
あと今更awkやsedの読みづらい文法覚えるより他のスクリプト言語で書いた方が楽だし、POSIX原理主義はPOSIXに慣れている奴のポジショントークにすぎないと思うね
730 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 20:46:22.02 ID:GzQExg5g0.net]: >>693
gitのバージョン管理されているファイルツリーはdiffコマンドがそのまま解釈できるような形式でファイルシステム上に存在しないからファイル単位で変換して外部関数呼び出すとか馬鹿だな
さらにgit内部で保持されるファイルの差分情報をdiffの出力みたいな字句解析が必要なバイト配列で取り扱うのも馬鹿げてる
このファイル差分抽出は間違いなくgitの核心的機能これが無ければVCSとして機能しない
731 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 20:49:18.25 ID:oV1LtMOH0.net]: >>705
POSIX原理主義者はPOSIXを理解してないよ。
732 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 20:55:34.73 ID:GzQExg5g0.net]: >>698
-uをサポートする前は、patch作るなら-cのコンテクスト形式だろ
-cなら-uとハンクの精度は変わらん
733 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 21:08:17.57 ID:J+3pjzxx0.net]: >>706
そこら辺の機能はGit以前から完全に機能してるんだよ。
> diffが作られてしばらくは、ソフトウェアコードや技術文書のマークアップのソース部分の変更箇所を比較する、
> プログラムのデバッグ出力の検証、ファイルシステム中のファイル一覧の比較といった使い方が一般的であった。
> ed用の出力により、ファイルへの一連の変更をひとまとめにしてファイル容量を節約するというアイデアが出てきた。
> Source Code Control System（SCCS）はそのようなアイデアを実装したものとして1970年代後半に実装がなされた。
> https://ja.wikipedia.org/wiki/Diff
だからそれは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 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 21:09:37.44 ID:J+3pjzxx0.net]: Webの連中は馬鹿なのも事実だけど、馬鹿でも上手く行くように色々上手く出来てるのも事実なんだよ。
Ｃの連中は一度Webをやってみると凄く勉強になると思うよ。俺もそうだったし。
ただしWebはかなり糞なのも事実だが。
736 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 21:15:30.28 ID:GzQExg5g0.net]: >>709
マージやリベースでやってる差分抽出は最終段のI/Oじゃないし
C言語でシンプルに実装されてるgitをMSが作る馬鹿みたいに重いツールにしないでくれよ
737 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 21:34:40.89 ID:GzQExg5g0.net]: BitKeeperを元にGitを実装したリーナスはBitKeeper以前のVCSを糞みたいに言ってるんだよね
https://ezoeryou.github.io/blog/article/2015-04-08-linus-git-interview.html
edとdiffを使ったようなVCSは眼中になかった
738 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 21:39:28.36 ID:J+3pjzxx0.net]: >>711
だから普通は、内部的に圧縮されたファイルへのアクセスは、
1. 単純にメモリ展開する
2. 何らかのプロキシオブジェクトでエミュレートする
のどちらかで、大概前者だしGitでもそうなってる。
だからここで速度低下とかは関係ない話だ。
(なお後者は/dev/zeroとか/dev/randomとかと言えば分かるだろう)
そこを他の言語、PHP/JS/Go/Rustのどれかを知ってれば、
そこでオブジェクトにしてI/O分離してマルチターゲットにしてしまうのも常識。
これを思いつけない/知らないのだから多分本当にCしか知らない連中だけでやってるよ。
君からもそれを感じる。

ちなみに重くなる/ならないなら、SQLiteは大量の小さいファイルならファイルよりも速いぜ！とか言ってるし、
他DBと違ってローカルだから試してみると面白いかもよ。
https://www.sqlite.org/fasterthanfs.html
739 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 21:52:54.41 ID:GzQExg5g0.net]: >>713
内部的に圧縮されたファイル？
「ファイルツリーはdiffコマンドがそのまま解釈できるような形式でファイルシステム上に存在しない」
これを勘違いしたのかな？
ファイルじゃなくてファイルツリーね
gitのディレクトリーのツリー構造を保持する方法独特だからその各ファイルをdiff取ってもらうためにツリーをtraverseするインターフェースを提供する必要が有る
ファイル単位の差分抽出なんて複雑な処理でもないんだからそれをやってもらうためにそれよりはるかに複雑なインターフェースを設計するとか無駄以外の何物でもないな
740 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 21:54:31.60 ID:J+3pjzxx0.net]: >>712
ただそれはedとdiffが問題だったわけではないだろうし、
仮にそうだったとしても、正しくソフトウェアを構成していればすぐに交換可能で、全く問題にならないんだよ。
その辺がソフトウェア階層の意識がないなあと思うところだよ。
Cはそういう世界でもあるけどさ。

edとdiffで展開するのが駄目なら、他方式の cat-file 階層に交換してしまえば何とでもなるんだよ。
Gitの方式が優れていれば、他VCSがGitの末端階層のI/Oコードを取り込めば済むだけ。
だからそこを問題にする時点でズレてる。
例えばgzipの様なストリーミング方式の cat-file にしてもう動作するし、7zipでも何でもいいんだよ。
(バージョン管理システムの場合は個別ファイルではなくファイルセットでの圧縮なので実際はこれらは適切ではないが)

それでLinusが言ってるように、キモは
> 問題はコード量ではなくて、どのようにデータを扱うかだった。
> 初期の実際のコード量は、かなり少ない。基本的な考え方が正しいかどうかにかかっている。開発を始める前からそのアイディアについて考察していたわけだ。
であって、要はツリーコントロールであって、I/Oではないだろ。
741 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 22:11:44.63 ID:J+3pjzxx0.net]: >>714
ああ、ファイルと
742 名前：勘違いしていたのは事実だが、それでも意味は同じだよ。 > gitのディレクトリーのツリー構造を保持する方法独特だからその各ファイルをdiff取ってもらうためにツリーをtraverseするインターフェースを提供する必要が有る 勿論その通りだが、つまりこれはファイルシステムであって、その先に隠蔽出来るんだよ。 NTFSかext4かbitlockerを使ってるか圧縮DISKかをアプリは気にしないだろ。 それはOSがファイルシステムの違いを隠蔽してくれるから。これと同じ。 同様に、 cat-file で末端のファイルの形式の違いは隠蔽出来て、 ファイルシステムドライバ（とでも言うべきか？)で、ツリー詳細構造の違いは隠蔽出来るんだよ。 そしてそれは当然Gitにも入ってる。 だからその上位からはGit形式のファイルツリー/オブジェクトツリーを 普通のファイルシステム/オブジェクトと同じように見せることは可能なんだよ。 そして実際にそうしてるはずだよ。 だからな、自分が管轄してる階層以外の所は、はっきり言って関係ないしコードからも見えないんだよ。 Cの場合はその辺の階層意識が希薄で、実際君との空回りもこれだが、Gitもこの辺は正しく実装されてるはず。 []: [ここ壊れてます]
743 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 22:17:17.34 ID:GzQExg5g0.net]: >>716
cat-fileは単にblobの中身を表示するコマンドってだけで、逆をやるblobを作るコマンドが用意されてるわけじゃない
つまりここでソフトウェア的に階層がきれいに分かれてるわけじゃない
ここを置き換えて自由な圧縮アルゴリズムを使えるようになっていたとしたら
Libgit2 みたいな別実装のライブラリが出現する余地もなかっただろう
ここは変にインターフェース階層なんて用意しなくて正解
gitはツールであるとともにフォーマットでもあるんだよ
フォーマットに自由なオプションが用意されているとか別の実装を作る側としては悪夢でしかない
744 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 22:33:44.64 ID:DiR+92tnM.net]: そう、このクレーマーはGitのデータモデルやデータフォーマットとしての側面を見落としてる
確固とした優れたデータモデルを持つってのは立派なUNIX哲学の一つなんだけどねえ
745 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 22:39:17.91 ID:h5Hfu9WR0.net]: >>715
いいから、お前に git は向いてないから消えろ。git は万人向けじゃない。
自分で納得がいくものを作ってそれを使え。
どうせ多人数がかかわるようなプロジェクトとかには縁がないだろから、一人で寂しく使ってろ。
746 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 22:41:57.65 ID: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 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 22:45:45.36 ID:h5Hfu9WR0.net]: >>720
糞理論いいから、まずは作って見せろ。
748 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 22:50:56.79 ID:GzQExg5g0.net]: >>720
そんな入れ替え可能な階層分けが必要なら最初から全部C言語以外で作ればよかったんだよ
でもリーナスはC言語を選んでほぼunixシステムコールを直接叩く方式で実装した

hqなんかの方がお前の好みに近いだろうけど、hqは廃れてgit全盛となった
むかしはこのスレにもhq信者が盛んにチョッカイかけに来たもんだけど、いまは何してるんだろうな
749 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 22:55:40.76 ID:h5Hfu9WR0.net]: もはや
750 名前：名前すらちゃんと覚えてもらえてない hg さん。 []: [ここ壊れてます]
751 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 22:59:10.92 ID:J+3pjzxx0.net]: >>717
あーだからな、フレームワークを一度使ってみれば勉強になると思うよ。

フレームワークは型に嵌められるのだけど、
その型はそれなりの奴が一生懸命考えた型だから、それなりなんだよ。
なるほどこうすればファイルもネットワークもDBも全部同じコードでいけるのか、とか分かるよ。

ファイルシステム構造も、末端のファイル自体も、
上位には関係ないように隠蔽出来るし、難しいことではない。
実際、Git cat-file はGitファイルシステムを隠蔽してる、とも言えるだろ。

>>722
つかなんか勘違いしてると思うが、階層を分けたら遅くなるとかではないんだよ。
(厳密に言えば関数コールが1つ入るからその分は遅くなるが)
752 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 23:00:32.54 ID:h5Hfu9WR0.net]: >>724
いいからお前は自分で作れ git 使う必要はないぞ

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef