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 627 名前：デフォルトの名無しさん mailto:sage [2022/10/07(金) 18:27:03.31 ID:GHAO4XK10.net] >>606 � 628 名前：ｶゃあ、お前がシェルスクリプトで git 書けばいいんじゃね？ 俺はバイトオーダーに依存しないCプログラムの書き方知ってるのでそっち使うけど。 [] [ここ壊れてます] 629 名前：デフォルトの名無しさん mailto:sage [2022/10/07(金) 18:36:41.70 ID:E++rKArz0.net] >>607 我らはすでにシェルスクリプトでバージョン管理を行うすべを持っておる gitを書く必要などない 知りたくばこれを買ってPOSIX主義的バージョン管理概論を読め https://richlab.org/coterie/lpf.html 630 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ cfbb-fxWw) mailto:sage [[ここ壊れてます] .net] >>608 ゴミを勧めんな。オライリーに訴えられてろ。 631 名前：デフォルトの名無しさん mailto:sage [2022/10/07(金) 20:35:52.31 ID:E++rKArz0.net] >>609 ゴミならば大学の教科書になっておらぬわ 632 名前：デフォルトの名無しさん mailto:sage [2022/10/07(金) 23:21:13.94 ID:YKezo8WP0.net] forkで2つのコミットの差分どうやって見るの？ 履歴から2つ選択しても出ない。コンテキストメニューも。未実装？ 633 名前：デフォルトの名無しさん mailto:sage [2022/10/08(土) 00:36:23.18 ID: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 名前：デフォルトの名無しさん mailto:sage [2022/10/08(土) 05:07:17.54 ID:qNYwj5bN0.net] >>610 大学には頭おかしいのがおらんとでも？ 大学全体の何割が使ってるか言ってみ。 635 名前：デフォルトの名無しさん mailto:sage [2022/10/08(土) 07:49:17.82 ID:fwLI4Y/XM.net] どうせ安全じゃないだろw >fatal: detected dubious ownership in repository at こんなものつけるなよカス 636 名前：デフォルトの名無しさん mailto:sage [2022/10/08(土) 09:15:42.49 ID:vxPAcYo70.net] >>613 大学だけじゃないぞ プログラマならシェルスクリプトマガジンぐらい知っておろう そこに長期連載されているほど、普及しておる 頭がおかしいなら、こんなに長く連載されるはずがないな 637 名前：デフォルトの名無しさん mailto:sage [2022/10/08(土) 13:26:00.09 ID:HbWzH6SVM.net] >>615 シェルスクリプトなぁ……簡単な作業の自動化用途だな。 なんでgitスレでこんな話題が？ NG指定したほうがいい？ 638 名前：デフォルトの名無しさん mailto:sage [2022/10/08(土) 14:00:29.88 ID:x9F/jCO70.net] >>612set-headサブコマンドが使えるみたい 639 名前：デフォルトの名無しさん mailto:sage [2022/10/08(土) 14:11:03.99 ID:vxPAcYo70.net] >>616 愚か者め。シェルスクリプトは何でも出来る。CGIも作れた。 この間はUNIX哲学に基づいてリアルタイムカーネルなしに シェルスクリプトだけでリアルタイム処理を実現してみせたわ https://www.sea.jp/ss2021/download/11-SS2021.pdf 640 名前：デフォルトの名無しさん mailto:sage [2022/10/08(土) 14:23:26.42 ID:vxPAcYo70.net] >>616 gitのような目的を見失ったバージョン管理ソフトを使っているからだ バージョン管理ソフトはライブラリよりも長く行き続けなければならんものだが リポジトリでわけのわからんバイナリ形式を使っておるから バージョン管理ソフトが滅んだら復元は不可能になる。一体何を考えておるのか。 「データはテキスト形式で保存しろ」とはUNIX哲学でも言われている。 641 名前：デフォルトの名無しさん mailto:sage [2022/10/08(土) 14:47:58.03 ID:TKlSmRLn0.net] 容れ物が古くなったら新しい容れ物に中身を移すだけ。 642 名前：デフォルトの名無しさん mailto:sage [2022/10/08(土) 14:51:46.02 ID:vxPAcYo70.net] >>620 よくもまあ懲りもせずにといったところだな そうやって古くなったソフトを捨て新しいものに入れ替え せっかく覚えた知識は無駄になり移行作業で苦しむ POSIX原理主義なら一度覚えた知識は一生使うことが出来る 新しいことを覚える必要はない 643 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ deb0-zauZ) mailto:sage [[ここ壊れてます] .net] 啓蒙したいんだろうけど >新しいことを覚える必要はない これ読んで「そんなメリットがあるなら俺もPOSIX原理主義に入信しよう」と考えるエンジニアがいるもんかね。 644 名前：デフォルトの名無しさん mailto:sage [2022/10/08(土) 15:30:37.98 ID:5sXOif570.net] >>617 git remote set-headだとリモートトラッキングブランチのHEADが変わっただけでベアリポジトリ側のHEADは変わらず、 HEADが指してるブランチ(master)も削除操作が利かないままだったんですが、もうちょっと教えてもらえませんか 645 名前：デフォルトの名無しさん mailto:sage [2022/10/08(土) 17:26:15.60 ID:qNYwj5bN0.net] >>621 いいから、お前は黙ってシェルスクリプトでOSカーネルでも書いとけ。完成するまで戻って来るな。 646 名前：デフォルトの名無しさん mailto:sage [2022/10/08(土) 17:39:03.44 ID:88/OpuEG0.net] 啓蒙したいんじゃなくて単に荒らしたいだけだから だいたいオープンソースなのにソフトウェアが滅ぶとか意味がわからん 647 名前：デフォルトの名無しさん mailto:sage [2022/10/10(月) 11:28:58.21 ID:JuIf0a+H0.net] シェルスクリプトのヤツは釣りだろ？ マジでいってんだったら頭おかしいだろw (基地外を釣るエサ投下) 648 名前：デフォルトの名無しさん mailto:sage [2022/10/10(月) 17:13:47.79 ID:+gDGPUis0.net] https://megalodon.jp/2017-0110-1117-05/qiita.com/richmikan@github/items/7c2f844169db9a83c5ae 私の場合は「POSIX原理主義者」という名の人格者として名を知られるようになってきたが、「原理主義」を名乗るだけあって、 649 名前：デフォルトの名無しさん mailto:sage [2022/10/10(月) 17:25:23.67 ID:PTVZRYxu0.net] >>627 いいからお前はシェルスクリプトでカーネル書く作業に戻れ。シェルスクリプトがあれば何でもできるんだろ。 650 名前：デフォルトの名無しさん mailto:sage [2022/10/10(月) 17:30:56.62 ID:+gDGPUis0.net] >>628 勘違いしてるぞ。俺は人格者（笑）って書き込んだだけだぞ 651 名前：デフォルトの名無しさん mailto:sage [2022/10/16(日) 04:54:37.57 ID:kNlIrq3k0.net] Shelling at Russian power plant leaves Belgorod without electricity https://www.youtube.com/watch?v=n32nblVVz1g 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 使う必要はないぞ 753 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 23:25:07.54 ID:GzQExg5g0.net] >>724 結局gitがどういう方式で実装されているかなんてことよりファイルフォーマットの方が重要ってことだ だからgitの実装とファイルフォーマットを切り離すようなインターフェース階層は必要無いしだれも実装しない 必要無いものを実装すれば余計なメンテの手間もかかる 754 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 23:25:57.99 ID:Sz6pT8cp0.net] すごい勢いでスレ消費してるな… >>676 1回のコミットで整理っていうのは、1つのコミットにまとめるってことかな？ それとも1回のコマンドで済ませたいってことかな(何度もcherry-pickしたくない)？ merge squashじゃあかんかね。 連続してない部分的なコミットをまとめるならrebase squashでもいいよ。 連続してないコミットなら、rebase -i使えばいいよ。いらないコミットはdropできるよ。 rebaseするときは、元のブランチ消えるから、必要なら復帰用にブランチ作っておくといいよ。 755 名前：デフォルトの名無しさん mailto:sage [2022/11/01(火) 00:01:33.71 ID: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 名前：デフォルトの名無しさん mailto:sage [2022/11/01(火) 00:33:10.99 ID:kz7RaJ2H0.net] >>728 現状の.git/* の形式が十分にシンプル明解でこれが共通I/Fになっている すでにこの共通I/Fに沿っていろいろな実装が存在している 結果これを変更するための内部的なI/F階層が必要とされていない 内部的な構造としてはそんなことよりSHA-1をSHA-256に変更することの方が重要で実験的実装が進んでいる 切り口が違うからお前の言うような階層をつくってもハッシュの形式の変更には対応できない そんなくだらないことに割く労力は無い 758 名前：デフォルトの名無しさん mailto:sage [2022/11/01(火) 00:33:26.41 ID:1wY/uhrP0.net] 長いからまとめたよ。 「俺は実装しないけど、俺以外の誰かが俺の推測に沿うように実装しておくべきなんだ。俺は実装しないけど。」 759 名前：デフォルトの名無しさん mailto:sage [2022/11/01(火) 01:23:19.93 ID:ju8ytuSJ0.net] なんでgitの話でフレームワークの話が出て来んのかな 760 名前：デフォルトの名無しさん [2022/11/01(火) 01:46:22.68 ID:Mxyz6tUC0.net] 無限の自由度の代わりに組み合わせ爆発が生じてエッジケースでバグが出まくり、というのは嫌だという設計思想なんじゃないかな 確かにWeb系でDIするのは当たり前だけど、RDBMSやビジネスロジック以外はトラブってもいいWeb系と違ってgitでトラブル続発したら困るし。 ファイルシステムみたいなものでは。 761 名前：デフォルトの名無しさん [2022/11/01(火) 01:52:53.48 ID:Mxyz6tUC0.net] あと大体git自体が膨大なLinuxカーネルのVCSとしてかなり高速に、確実に動作する必要があったという大前提があるだろう。 そこを無視して汎用的にはこっちの方がいいってのは違うんじゃないかな。 汎用的な用途としてのVCSが欲しいならばpost-gitを作るしかないと思うよ。 762 名前：デフォルトの名無しさん mailto:sage [2022/11/01(火) 02:08:49.56 ID:QdibabTL0.net] そもそも汎用性がある方が良いというのから幻想 道具は利用目的にあっているかどうかが全て十徳ナイフありがたがるやつは素人 763 名前：デフォルトの名無しさん mailto:sage [2022/11/01(火) 03:17:45.94 ID: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 名前：デフォルトの名無しさん mailto:sage [2022/11/01(火) 03:19:13.38 ID:Jzc3CN/20.net] >>732,733 これをDIと呼ぶのか？はさておき、DIでバグが増えるなんて事はないよ。 そして、get_hash()でのオーバーヘッドは関数呼び出し一回でしかなく、 それで致命的に遅くなるなんて事もないよ。 というか、 765 名前：GitのマージってI/Oバウンドだと思ってるが違うのか？ [] [ここ壊れてます] 766 名前：デフォルトの名無しさん mailto:sage [2022/11/01(火) 03:55:08.59 ID:kz7RaJ2H0.net] >>735 ただ単純にハッシュアルゴリズムをSHA-1からSHA-256に変更するわけじゃないぞ 既存のSHA-1リポジトリも全部(リベース状態にすることなしに)SHA-256で運用できるようにしたりするんだよ gitの開発はリポジトリのフォーマットの継続性をとても重視してる 767 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4) mailto:sage [2022/11/01(火) 08:06:29.98 ID:Jzc3CN/20.net] >>737 同じだよ。 正しく構成されてる場合は何種類混在しても全く問題ないし、簡単に変更可能だ。 つかマジでそれオブジェクト指向(OOP)の基本中の基本だから。 ただ、混在なら、Cで一般的に使われてるSIZEOFの#defineでは対応出来ないが、 Linusのコードなら、Cでは一般的に禁止されてる小文字マクロで 普通にそこら辺の関数もマクロだらけの可能性があり、(linuxカーネルコードがそう） この場合は、#define内のマクロ定義を一箇所変更するだけで対応可能ではある。 が、まあ、マクロ云々の話は本来はNGとされてて他言語では厳禁だから、いわゆる正しい方策を示すと、 全体の関数はハッシュの中身が何か知らない状態で記述するんだよ。 get_hash()でハッシュのポインタを貰いました、中身は知りませんので具体的な操作はできません、 なので一々投げ返して操作して貰いますがよろしいですね？とする。 768 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4) mailto:sage [2022/11/01(火) 08:06:50.06 ID: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) mailto:sage [2022/11/01(火) 08:51:54.94 ID:Jzc3CN/20.net] 補足。 分からなければ「OOP 抽象化」でググって色々読んでみてくれ。 死ぬほどでてくるはず。マジで基本中の基本だから。 ハッシュを交換することに手こずるようなら、その『コード』は間違いなく糞だ。(Git自体が糞と言っているわけではない） ただ、修正すればいいだけ、要は漏れなく上記のようにしてしまえばいいだけではあるが。 正しく構成すれば、Hash変更なんて簡単に出来るし、 そもそもそうなってないコードなんてOOPでは存在を許されてない。 （そうとは書けないように構成されてる。 それを 770 名前：強制的にやらせるシステムの一つがprivateだが、これはこれで間違った使われ方も多いが） [] [ここ壊れてます] 771 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ d9e4-Xmag) mailto:sage [2022/11/01(火) 09:16:06.92 ID:kz7RaJ2H0.net] 長々とご苦労さんだがお前SHA-256対応の意味が理解できてないよ 772 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4) mailto:sage [2022/11/01(火) 09:26:52.60 ID:Jzc3CN/20.net] >>741 俺は以下記事の理解書いてる。 俺が書いた事の意味が分からないのは君の問題。 https://www.infoq.com/jp/news/2020/11/git-2-29-sha-256/#:~:text=%E3%81%A4%E3%81%BE%E3%82%8A%E3%80%81Git%E3%81%AF%E3%80%81%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E5%90%8D%E3%81%A8%E3%82%B3%E3%83%B3%E3%83%86%E3%83%B3%E3%83%84%E3%81%AE%E4%B8%A1%E6%96%B9%E3%81%ABSHA-256%E3%82%92%E4%BD%BF%E7%94%A8%E3%81%99%E3%82%8B%E6%96%B0%E3%81%97%E3%81%84%E3%83%AA%E3%83%9D%E3%82%B8%E3%83%88%E3%83%AA%E5%BD%A2%E5%BC%8F%E3%82%92%E5%B0%8E%E5%85%A5%E3%81%97%E3%81%9F%E3%80%82,%E3%81%93%E3%81%AE%E6%96%B0%E3%81%97%E3%81%84%E5%BD%A2%E5%BC%8F%E3%81%AF%E3%80%81%E3%83%AD%E3%83%BC%E3%82%AB%E3%83%AB%E3%81%A7%E7%94%9F%E6%88%90%E3%81%95%E3%82%8C%E3%81%9FSHA-256%E5%90%8D%E3%81%A8SHA-1%E5%90%8D%E3%81%AE%E9%96%93%E3%81%AE%E5%8F%8C%E6%96%B9%E5%90%91%E3%83%9E%E3%83%83%E3%83%94%E3%83%B3%E3%82%B0%E3%82%82%E3%83%97%E3%83%AD%E3%83%93%E3%82%B8%E3%83%A7%E3%83%8B%E3%83%B3%E3%82%B0%E3%81%99%E3%82%8B%E3%80%82 ただ、初めてOOPを示されていきなり意義を理解出来る奴はほぼ居ないのも事実。 でも、君は確実に老害扱いされてると思うよ。 773 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ f15f-iYvO) mailto:sage [2022/11/01(火) 09:32:09.77 ID:WFTKMpG40.net] なんだか知らんけど5chでうだうだ言ってて何になるの 774 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ d9e4-Xmag) mailto:sage [2022/11/01(火) 09:36:58.90 ID:kz7RaJ2H0.net] >>742 君はその記事の意味することを理解できてないね コミットオブジェクトの構造とか役目を理解出来てないと難しいかもしれない 775 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4) mailto:sage [2022/11/01(火) 09:57:34.79 ID:Jzc3CN/20.net] >>744 そう思いたいんだろうけど、残念ながらそうじゃない。 少なくとも君はソフトウェア階層やOOPの基本事項について全く理解出来てない。 だから今、老害と言われ続けるか、再び学び直して熟練者と言われるかの分水嶺にいるだけ。 俺は君に何も強制することは出来ないが。 確かに俺はGit初心者なので、記事の理解は間違ってるかもしれない。 でも、ハッシュの中身や長さが変わったり混在したところで、 正しく構成されてるソフトウェアなら数行の変更で対応可能なのは事実だよ。 そして君と同様の人達によってGitが作られているのであれば、 そりゃそうなってなくて苦労するんだろうさ。 まあいいけどね。もう水掛け論だから終わりにしようぜ。これ以上やってもお互い得る物もないし。 776 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 8b8f-5UCg) mailto:sage [2022/11/01(火) 10:12:34.67 ID:ju8ytuSJ0.net] > GITは、すべてのファイルオブジェクトとコミットの識別と整合性チェックをSHA-1に強く依存しています こう書いてあるのになんで無視するんだろう 777 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ d9e4-Xmag) mailto:sage [2022/11/01(火) 10:29:09.24 ID:kz7RaJ2H0.net] >>745 数行で対応ｗ それが出来ないgithubは無能集団なんですねｗ 糞MSに買われちゃうぐらいだから仕方ないか 778 名前：デフォルトの名無しさん mailto:sage [2022/11/01(火) 12:34:56.06 ID:lDKItQe4r.net] Git初心者に語らせると頓珍漢な文章が生まれるという好例 779 名前：デフォルトの名無しさん mailto:sage [2022/11/01(火) 12:39:40.93 ID:QdibabTL0.net] >>745 お前日本語読めなさそうだな ましてやリンク先にある英語とかかけらも理解できてないだろ 混在とかじゃないぞ。二つを同時につけて「安全」に相互変換するということだぞ 安全にすることが目的でSHA-256を使えば解決みたいな話じゃない � 780 名前：ｨ前みたいなのが目的と手段を取り違えるタイプの典型 OOPとかアホなプログラマでも理解できる単純なことなわけないだろ そんなんで済むならとっくに終わってる まずは常識で考えろ できないなら黙って勉強しろ [] [ここ壊れてます] 781 名前：デフォルトの名無しさん mailto:sage [2022/11/01(火) 18:29:25.93 ID:/+vO/8+o0.net] 長文すげー 782 名前：デフォルトの名無しさん mailto:sage [2022/11/02(水) 05:40:42.57 ID:n+gr/3CY0.net] >>749 どうであれ同じだよ。 複数付けようが、何をどう組み合わせようが、 抽象化の向こうの実体については知らないし、取り扱うコードも存在してないから、 同じバイナリで動作するんだよ。それが抽象化と隠蔽で、これはOOPの基本中の基本。 783 名前：デフォルトの名無しさん mailto:sage [2022/11/02(水) 05:41:43.29 ID:n+gr/3CY0.net] んー、お前ら完全に化石だわ。若い奴からは確実に馬鹿にされてるよ。 というか、現在において有名OSSにこんな化石居住区が存在してたことにびっくりだわ。 >>747 数行ってのは誇張ではなく、実際にそんなもんなんだよ。 例えばMMDは3DVision対応に20-30行と言ってるが、 > そのため、樋口氏がMMDの3D Vision対応に要したのは、20～30行程度の簡単なコーディングのみだった。 > https://pc.watch.impress.co.jp/docs/topic/feature/415525.html この樋口氏はVer5->7でDirectX対応してて、その時もインタビュー受けてて(ググッても出てこないが) 確か「よくよく確認して、実際に変更する必要があるのは2-3行だったのでほっとしました」 とか言ってたはず。 これは特殊ケースではなく、こうなるように設計するんだよ。 これに対してGitはマニュアル見てもそういう思想が全く見あたらず、「頑張ればいいよね」で終わってる。 だから糞なソースも「頑張って」修正して何とかするんだ、のノリだ。 ソフトウェア工学はそんなのは20年前にクリアしてて、今は、 A. どうすれば変更に対して強くなるか（仕様変更があってもソースコードを変更せずに済むか） B. どうすればそもそもソースコードを記述する必要すらなく出来るのか(全ての状況に対し同じバイナリで対応する) C. どうすれば出来るだけ早い段階でバグを検出出来るか とか移ってて、大体馬鹿がCに対して悪ノリしてるからLinusがこき下ろす事態になるのだが、 ABはちゃんとやらないと話にならないよ。 だからまあ、次のGitは「勉強をがんばらなくてすむGit」で、 実装で一番簡単な方法は、Gitをバックエンドに使ってシェルスクリプトでラップすることだよ。これらは既に言ったが。 でも君らは「頑張らなくちゃいけない」「頑張るべきものだ」と思っちゃってるみたいだから、 今のGitプロジェクトからはこれは出てこないだろう。 となると、上記のようにして簡単に実装したNext-Gitに成果をかっさらわれ続ける事態になると思うよ。 ちょうどGNU/Linuxの形に似てるが。 あれはLinusが悪いわけではないし、ストールマンも別になんとも思ってないようだけど。 784 名前：デフォルトの名無しさん mailto:sage [2022/11/02(水) 06:01:09.34 ID:z+vraLDY0.net] > これは特殊ケースではなく、こうなるように設計するんだよ。 > これに対してGitはマニュアル見てもそういう思想が全く見あたらず、「頑張ればいいよね」で終わってる。 それあなたの感想ですよね？ gitはソースコード1行程度で変更終わりですよ 785 名前：デフォルトの名無しさん mailto:sage [2022/11/02(水) 06:03:01.35 ID:z+vraLDY0.net] > 実装で一番簡単な方法は、Gitをバックエンドに使ってシェルスクリプトでラップすることだよ。これらは既に言ったが。 シェルスクリプトは移植性低いって分かってる？ シェルスクリプトでラップしようものなら Linuxでは動くがFreeBSDでは動かないってことが しょっちゅう発生する シェルスクリプトで頑張るものじゃない 786 名前：デフォルトの名無しさん mailto:sage [2022/11/02(水) 07:01:05.57 ID:S2ENS6Jw0.net] git の一部機能は git コマンドを使ったスクリプトで実装されていたんだけど、多くのユーザーの要望に応える形でそれらのC言語化進めてる 787 名前：デフォルトの名無しさん mailto:sage [2022/11/02(水) 09:34:00.28 ID:33j+wJW8H.net] シェルでラップw USPから悪い影響でも受けたか？ 788 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 8bbb-VzUj) mailto:sage [2022/11/02(水) 10:35:32.50 ID:sFE/M4aa0.net] OOPなんて初心者プログラマ訓練ギブスってことを理解できなくてアホ理論展開しているやつがいてｗ 789 名前：デフォルトの名無しさん mailto:sage [2022/11/02(水) 14:42:23.54 ID:LlnSL/r70.net] OOPなんか、そん辺のサンデープログラマでもかなり深い所までメリットデメリット含め浸透してるがな。 関数指向やクロージャがある言語も同様で もはや当たり前のようにハイブリッドになってて一部の原理主義者以外いい塩梅で使ってるから話題にはならん。 790 名前：デフォルトの名無しさん mailto:sage [2022/11/02(水) 15:33:51.58 ID:4T0OIw/dr.net] OOPそれほど語るなら、お前の大好きなシェルスクリプトはみんなOOP意識して作られてるのかって感じだな 791 名前：デフォルトの名無しさん mailto:sage [2022/11/02(水) 18:08:31.10 ID:mw55lzgRM.net] リーナスを中心としたOSSコミュニティの起源にタネンバウムとのモノリシックカーネル・マイクロカーネル論争があることを知らないのかな？ 結果として無駄な抽象階層を積み重ねることの無意味さをLinuxカーネルの成功が証明してしまった もちろんLinuxカーネルもファイルシステムとか必要なとこは抽象化されてるけどね 792 名前：デフォルトの名無しさん [2022/11/02(水) 18:41:51.51 ID:1AIcQZnX6.net] 今どきの若い奴(というか最新の風潮)ってなんでもかんでもオブジェクト指向を徹底するって感じじゃないと思うけどなあ それこそオブジェクト指向主義みたいなのが滅茶苦茶強かったのって20年前ぐらいじゃない？ WindowsもNTでマイクロカーネルにしたけどオーバーヘッドデカすぎて一部はカーネル空間に戻したりしたでしょ。 SIerの階層が深い開発なんかだとオブジェクト指向を徹底しないと事故が起こりそうだけど、そういうとこしか知らない人間なのか？ 793 名前：デフォルトの名無しさん mailto:sage [2022/11/02(水) 22:26:03.48 ID:KtYxSAYnr.net] 何でもかんでもシェルでやろうとするやつは病気 名前を呼んではいけないあの開発手法とか推してそう 794 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 05:47:24.09 ID:AHw2USmo0.net] >>755 それはどのプラットフォームで問題になったの？ 賢い選択とは思えないけどね。 具体的なデメリットは既に666で挙げたとおり。 俺はシェルの互換性問題なんて有ったとは思えないけど、 (昔からsh《bsh》は互換性は高かったし、今はその後継のbashで統一されてる。 ああ確かにcsh/tcsh/ksh/zshはゴミだったし死滅したよ) それが問題なら、GitのC化ではなく、直接シェルの互換性を上げるのが常策だよ。 互換性がC化で達成出来るのなら、 既にあるbash(多分C)ソースをコンパイルしただけのものを同梱し、 gsh(=gitsh)だ！これを使え！と強弁すれば済んだろ。 なんかやっぱり無能の働き者を地で行ってる気はする。 仕事を減らす努力をしてないよね。 795 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 05:49:10.00 ID:AHw2USmo0.net] >>758 その通りだ。だからアマチュアの樋口Pも正しく対応出来てた。 だからこそ、このスレのこれまでのやりとりに驚いている。 今時初心者でも、他言語スレでもあり得ない流れだ。 で、パッチ出てきたけど、あれでは駄目だね。 彼等はC流のメモリ管理の方法を知らず、Gitは完全に糞コードで出来てる。 あれでは他にもメモリリークだらけだよ。 (ただこれも想定内っぽいし、 リークしたところでアプリとしては大した問題でもないのも事実だが) 彼等は、バグを直す努力はしているが、 バグが出にくいコードにする努力は全くしてない。 OOPもやりすぎると問題だが、何故彼等はそうするのかを学んで、 美味しいところだけ貰えばいい� 796 名前：ﾌにとは思うよ。 OOP原理主義者も、Gitプロジェクトやこのスレ民みたいなOOP排除原理主義者も、同様に問題だよ。 [] [ここ壊れてます] 797 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 06:07:03.27 ID:AHw2USmo0.net] ただ見る限りGit界隈は密結合主義のようだ。 つまり、Gitと知識的に密結合した、Gitに詳しい奴だけがGitを使うべきであり、 tutorial1が基本コマンドなら普通はtutorial2は応用コマンドのところ、 なんと内部データ構造の紹介になってるし、 (ただこれは俺には極めて有効に作用したが、普通はブーイングの嵐だろう) 798 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 06:07:22.90 ID:AHw2USmo0.net] ソースコードも密結合、これは馬鹿除けだ！と言い放つ。 糞コードでもパッチの手数で勝負だ！カリスマLinusならモグラ叩き志願者は無限に募れる！ とまあ、他の誰も出来ないアプローチだね。 ただまあ、ソースコードを清潔に保つ目的は長期的メンテの為であり、 それは実際出来てるしいいだろ、と言われれば、はーそうですねー(棒)だが。 799 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 06:07:59.96 ID:AHw2USmo0.net] これ見てたら、buggyな糞コードでもとりあえず動けば受け入れてどんどん改訂し、バグもパッチの手数で勝負するのと、 普通のプロジェクトがやってる、レビューして駄目なコードは最初からrejectするのと、 (つまり手間をかけてもrejectされる可能性があるからコードを投げるのを躊躇される) どっちが良いのだろう？とは考えさせられるよ。 リソースが無限にあるOSSでは、前者の方がいいのだろうか？ LinusはBillJoyに対して「オープンソースを理解してない」と思ったらしいが、こういう事なのだろうか？ (この発言はLinus著作本にあるらしいが、俺は読めてない) しかしこのアプローチでは、絶対に浄化はしない。 自分の糞を片づけるのは仕方ないとして、 他人の糞を片づけたがる奴はいないし、そもそもその界隈が掃除に価値を置いてない。 しかし糞コードならどんどん投げてもらえるし、それらを受け入れる限り、進化が止まることもない。 はーなんだかねー。なるほど研究者と色々衝突するのも分かる気はする。 そういや大昔「伽藍とバザール」読んだなーと思って今読み返してみたが、これがバザールなのか？ （NGにかかったので分割した） 800 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 10:41:57.59 ID:NhDXzDSd0.net] それだけ文句あるなら本家MLで言うか自分で作り直してみろよ軍師様 これだけ大口叩いておいて英語のMLでコミュニケーションとれないとかだったら笑うが Git は世界中のプログラマが使ってる最重要プロジェクトで、これが改良されるとなれば世界中から絶賛される 801 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 10:46:51.87 ID:odT0DHDr0.net] まだやってのか 暇そうだな 802 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 13:22:38.17 ID:AHw2USmo0.net] >>768 それは無理だね。 仮に時間が十分にあったとしても、俺が改善出来るのはソースコードであって、アプリではない。 アプリの改善には良い仕様にする事が最も重要で、実装は実は大した問題ではない。 (使う分には十分に動けばなんでも良くて、それが糞コードで出来てたから何？でしかない) GitはLinus本人が当時のVCSの問題点を全て把握してたからいい仕様になった。 俺はそうじゃない。今の俺がやったら俺にとって都合がいいだけで、他にとっては糞な物にしかならない。 ただ実際はLinusもこれで、みんな乗り換えて来たから同じ問題を抱えていたんだろ、 という解釈らしいが、いずれにしても使い込んでる奴じゃないといい仕様には出来ないんだよ。 そして例のブランコ問題 > 顧客が本当に必要だったもの > https://dic.nicovideo.jp/a/%E9%A1%A7%E5%AE%A2%E3%81%8C%E6%9C%AC%E5%BD%93%E3%81%AB%E5%BF%85%E8%A6%81%E3%81%A 803 名前：0%E3%81%A3%E3%81%9F%E3%82%82%E3%81%AE もあり、顧客自身が実装してるんだから、そりゃ商用VCSでは絶望的に仕様的に太刀打ち出来ない。 そしてソースコード戦略も違う。Gitはコードレビューとか無い世界なんじゃないかな？ それで回るってのがスゲエが、多分これは「伽藍とバザール」の衝撃を追体験しただけなのだろう。 ソースコードを綺麗にしたら、新機能の追加が断然早くはなるけど、それは同じ人数での話で、 ここも手数で勝負だ！と来られたら、為す術もない。 ソースコードなんて糞でいいんだ、人数さえ有れば！では、研究者とは対立するよ。 なるほどエンジニアリングの天才だというのも納得ではある。 だからまあ、Gitを根本的に覆すにはGitよりも良い仕様が必要で、これは本当に難しいんだろうさ。 ところで、やはり俺のワークフローではIndexが邪魔なので削除しようと思うんだけど、 そもそもあれはどう使う為に設計されたものなのだ？ 多分Indexの存在が一番直感的でなく、『説明されてないと』間違える所だと思うんだが。 今のところadd直後にcommitしてて、邪魔でしかない状態で使ってる。 [] [ここ壊れてます] 804 名前：デフォルトの名無しさん [2022/11/03(木) 13:30:44.47 ID:9oLRzF140.net] index stageなかったら複数ファイルの変更を一度にcommitできないじゃん。コミット粒度の問題から、全部の変更をcommitしたいわけでもないし。 どのcommitを取ってきてもちゃんと動く状態にするのが普通だからどう考えてもいるでしょ。 805 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 13:52:50.16 ID:/4IN/B1bM.net] indexの意味がわかってない馬鹿が全然関係無いファイルをコミットしてリポジトリをブチ壊す 806 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 14:35:27.11 ID: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 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 14:40:47.35 ID:5PP47Osh0.net] git分からない思想も理解できないならSVN使えば？ 808 名前：デフォルトの名無しさん [2022/11/03(木) 14:46:46.91 ID:9oLRzF140.net] >>773 そりゃgitの設計思想で想定されたコミットの仕方をしていないからindex stageがいらないと感じるだけでしょ。 大多数は設計思想通りに使っているので、index stageが必要だと理解していると思うよ。 だから、「どう使うために設計された」かと聞かれれば、gitの思想通りにコミット粒度を適度に保つためだとしか言いようがない。 「俺は違うから俺はいらない」はそれはそうだろうが、だから何？って話になる。 809 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 15:04:33.12 ID:jVDh6EB5M.net] 適当なタイミングで時系列に修正を記録していくものだと思ってる阿保には理解できないVCS 810 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 15:05:56.85 ID:AHw2USmo0.net] >>775 git add -u を複数回して粒度を上げて動くものだけcommitしてもいいのだけど、 俺の場合は10回に1回程度は2-3回前の変更とdiff取った方が見やすいことがあって、 その場合にhash控えておくのが面倒だし、gcされてたらさらに面倒だし、gc切るのもまた邪道だろうしで、 動かないのもcommitしてfeatureの途中は動きませんと割り切るのが一番ましかと思ってる。 まあでもありがとう。 粒度調整の為ならこちらの予想の範囲内ではあった。 811 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 15:26:33.67 ID:O+O1uzzM0.net] >>777 > その場合にhash控えておくのが面倒だし、gcされてたらさらに面倒だし、gc切るのもまた邪道だろうしで、 N個前との diff は git diff HEAD~N でハッシュを控える必要もないし gc のくだりは何のこと言ってるのかわからない。 > 動かないのもcommitしてfeatureの途中は動きませんと割り切るのが一番ましかと思ってる。 ローカルブランチなら別に構わないけど、そのノリで作られたブランチをそのままレビューするのは効率悪い。 なのでマージ前のブランチをレビュー対象とする開発では push の際に整理することになるから、 都度整理の際にインデックスはとても有用。 他にも、作業中に全然関係ない typo 直したりするのにも使える。 812 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 15:53:58.77 ID:HnXRQ5rf0.net] index の重要性が分からないやつが git 語ってて草。 素人向けに説明すると git の役目は他人に読んでもらうやすい分かり易いパッチを仕上げること。 個人で作る分にはそれほど関係ないが共同作業するには他人への分かり易さ、見た目は最重要といっていい。 料理に例えるならフライパンやまな板のまま出すんじゃなくて、皿に盛って食べ易くしてから出すのが基本。 ワークツリーがフライパンで、インデックスが皿。フライパンからでも直接食えるけど、綺麗に皿に盛って、そこで丁寧にチェックしてから提供すれば他人の作業効率が上がる。 813 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 16:18:44.28 ID: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 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 16:20:05.12 ID:AHw2USmo0.net] >>779 いやレビュー対象はcommit済みで、index上ではないだろ。 815 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 16:22:38.83 ID:5PP47Osh0.net] うんうんわかった 大人しくSVN使え その方が君には向いている 816 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 17:18:17.27 ID:NhDXzDSd0.net] >>781 779はindex上でレビューするんじゃなくて、indexにいれた状態にしてからdiff --cachedでcommit前の確認をするってことじゃない？自分もそれやるよ 817 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 17:50:52.37 ID:e1pojM/n0.net] >>763 > (昔からsh《bsh》は互換性は高かったし、今はその後継のbashで統一されてる。 > ああ確かにcsh/tcsh/ksh/zshはゴミだったし死滅したよ) FreeBSDにはbash入っとらんぞ 818 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 17:52:28.68 ID:e1pojM/n0.net] >>763 > 既にあるbash(多分C)ソースをコンパイルしただけのものを同梱し、 > gsh(=gitsh)だ！これを使え！と強弁すれば済んだろ。 bashだけじゃ足らんだろ GNUコマンドも全部入れなきゃな！ 819 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 17:53:10.48 ID:e1pojM/n0.net] >>770 > 仮に時間が十分にあったとしても、俺が改善出来るのはソースコードであって、アプリではない。 だからソースコードを改善しろってｗ 820 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 18:10:35.38 ID:3fLLADP3M.net] >>784 macもbsahやめたんだよね GPLから逃げるために 821 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 19:01:05.13 ID:AHw2USmo0.net] あと実は、masterの意義も分からないのだが。俺の場合は、 master: 今現在Web上で公開しているもの develop: 今現在ローカル上でテストしているもの feature: 今現在変更中のソースコード と3つポインタが必要なのは分かる。 しかし、masterは常にdevelopとfast-forwardマージするなら、developにタグ打てば済む。 途中からのbranchも可能だし、hotfixするにしても問題ない。 branchケチる意味もないのも分かるが、それにしても無駄に多い気もする。 と思ってたら、俺にはサル先生方式位が適切な気がしてきた。 > ここでは統合ブランチとトピックブランチという二種類のブランチを使った運用方法について紹介します。 > https://backlog.com/ja/git-tutorial/stepup/02/ サル先生方式の統合ブランチにタグ打つだけと比べて、 masterとdevelopとして別に持っておいたら何が嬉しいの？ 822 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 19:03:24.24 ID:AHw2USmo0.net] >>784 >>787 政治的案件をOSS側がフォローする必要ないと思うが… 823 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 20:29:42.55 ID:e1pojM/n0.net] >>789 なに政治的案件の話にすり替えようとしてるんだよ gitは環境依存が激しいシェルスクリプトに依存しないように C言語で書いてるって話をしていただろ 824 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 20:33:17.75 ID:e1pojM/n0.net] >>788 1系、2系の同時開発とかあるやろ 825 名前：デフォルトの名無しさん [2022/11/03(木) 20:41:00.73 ID:vXMSDhes0.net] .gitignoreの書き方で質問 app.log, app.log.1, app.log.2みたいな感じで増えていくログファイルを無視したいのですがどう書けばいいですか？ 826 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 20:41:54.93 ID:5PP47Osh0.net] >>788 なんだやっぱりブランチのことすら分かってなかったのか 827 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 20:48:29.66 ID:5fumPTTR6.net] >>792 *.log* でなにか被ったりする？ 828 名前：792 [2022/11/03(木) 20:58:19.76 ID:vXMSDhes0.net] logフォルダ作ってそれを無視することにしました >>794 ごめんなさい！ 829 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 21:00:04.22 ID:AHw2USmo0.net] >>791 あ、なるほど了解。 逆に言えば、同時開発する気がなければ要らないわけだな。 830 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 21:04:46.26 ID:e1pojM/n0.net] >>796 今自分で「必要だ」って言ったってこと理解してるかい？ 831 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 21:15:11.85 ID:AHw2USmo0.net] >>790 C化しただけで環境依存が無くなるのなら、既にC化されてるbashでいいだろ。 Cコード上で何か小細工が必要なら、それは「互換性を上げる」名分でbashにcontributeすべきで、 Git側で吸収する案件ではない。 GPLから逃れたいってのも意味が分からん。 bashのコードを改変して新機能追加してmac_bachにしたら、そのコードを公開しないといけないが、 普通にbashを使って作業するだけなら関係ないから使えばいいだけ。 何か思惑有るんだろうけど、Gitがソースを汚してまでフォローする案件じゃないだろ。 > また、これ以外にも zsh や bash などのシェルが FreeBSD Ports Collection から利用可能です。 > https:// 832 名前：docs.freebsd.org/ja/books/handbook/basics/ 自分でインストールしろよ。 [] [ここ壊れてます] 833 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 21:16:20.05 ID:e1pojM/n0.net] だからなんでgit使うだけで bash＋たくさんコマンド入れなきゃならんのだよ 834 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 21:22:26.35 ID:AHw2USmo0.net] >>797 必要なのはポインタであってブランチではないんだ。 というか、俺にとってはその時のスナップショットが復元出来れば何だっていいんだよ。 fast-forwardでは履歴が辿れないからrebaseで、みたいな話もあるからもうちょっと確認必要だが、 git flow は手動ではなくインストールして使え、そうすれば全部やってくれる、としてるところばかりで、 どうもmergeの時に色々判断して小細工してるようだが、何やってるのか書いてないから分からないんだ。 まあでも色々他の簡単なのもあるみたいだし、初心者だから出来るだけ単純なのにするよ。 835 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 21:25:51.42 ID:AHw2USmo0.net] >>799 逆に一体どんな環境でやってるのさ？ 普通のunixコマンド一式すら入ってないのか？ そもそもGitなんてPCかそれに近い環境で動けば良くて、それ以外は考慮する必要ない気がするが。 836 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 21:29:12.32 ID:e1pojM/n0.net] >>800 今話をしているのはお前が言ったこと > 逆に言えば、同時開発する気がなければ要らないわけだな。 if (同時に開発する気がある) { 　　いる } else { 　　いらない } 自分で同時に開発する気があればいるって言っただろ自分で 837 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 21:39:01.44 ID:AHw2USmo0.net] >>802 ん？どこを誤解されてるのかは分からんが、 俺は複数バージョンを同時開発する気はない。 ただ、リリース後にバグが発覚するする事はあるので、hotfixはする。 838 名前：デフォルトの名無しさん [2022/11/03(木) 23:10:44.38 ID:9oLRzF140.net] >>801 普通にSourceTreeとかでコマンド一杯を前提としているとは思えないが。 839 名前：デフォルトの名無しさん [2022/11/03(木) 23:14:43.83 ID:9oLRzF140.net] >>788 少なくともCIで回すときは楽だろ。 Git初心者で視野狭すぎなのに、その視野の狭さを無視して「合理的に考えてこれが不要」ってのがあんたのスタイルのようだけど、 そうやってわざわざ視野の狭さから来る「不要」の主張をして反感を買ったレスで学びたいのか？ 勉強したいなら、炎上スタイルは目障りなんでよしてほしいな。二言ぐらい余計なんだよ。 840 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 23:20:07.30 ID:NhDXzDSd0.net] >>798 以下は簡単に調べただけで、時系列の検証もしてないので、何か間違いあるかもしれない macOSはbash,gcc,sambaをベースシステムにいれるのをやめた これらはGPLv2からGPLv3にライセンスが変更されて、GPLv3に追加されたバイナリの取り扱いに関する条項がmacOSのセキュリティポリシーに合わなくなったのがその理由 linusはこのGPLv3の条項に批判的で、gitはGPLv2のままでいく可能性が高い GPLv3のbashに依存するようgitを作り変えると、インストール方法をちょっと特殊にしないとgitもこのGPLv3の条項の制限をうけることになってしまうので、まあやらないだろうね 他のOSSに依存するとこういうのもあるから気を付けないといけない 841 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 00:15:00.44 ID:SQ9pznPg0.net] > Cコード上で何か小細工が必要なら、それは「互換性を上げる」名分でbashにcontributeすべきで、 Git側で吸収する案件ではない。 頭おかしい 842 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 00:54:15.51 ID:NvjwOVKTd.net] まあdevelopはいらないかな mainブランチで開発すりゃいいよ リリースブランチが必要なら別途releaseブランチを作ればよいのであって、デフォルトブランチは開発系の先端を指してる方が分かりやすい 843 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 01:05:42.22 ID:EF7BixRC0.net] >>798 > Cコード上で何か小細工が必要なら、それは「互換性を上げる」名分でbashにcontributeすべきで、 gitの都合でbashに迷惑をかけるな お前のやりそうなことだな 自分の都合で関係ないやつに迷惑をかける 844 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 01:06:39.03 ID:EF7BixRC0.net] >>808 初心者のお前の感想なんかどうでもいいよ 845 名前：デフォルトの名無しさん [2022/11/04(金) 02:09:07.55 ID:v1xRwBrw0.net] GPLに賛同せずにGNU製 846 名前：品を使ってたってことだろね。 結局Linusもタダ乗り爺ってことでしょ。 [] [ここ壊れてます] 847 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 02:50:33.29 ID:BbpXyzD40.net] ブランチの名前の付け方や使い方なんてほんとどうでも良い。チーム内で話し合え git のブランチは全部等価 デフォルトで main / master 作られるけど これも使いたくなけりゃ使わなくて良いし名前変えても良い 848 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 18:16:16.05 ID:XH5wI1Z90.net] >>805 そんなガキみたいなことはしないが、 どう取るのも自由だし、気に入らないのなら無視してくれて構わんよ。 ただgitがポンコツだと言ったとしても、それ本来お前ら関係ないよね？ 自身の分身と思えるほどcontributeしまくってるのなら別だけどさ。 > 少なくともCIで回すときは楽だろ。 必要になったときに作ればいいだけなのと、 多分仕様か実装を間違えてて、今のGitの動作では技術的に実用性がない。 これは次の投稿で詳しく述べる。 849 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 18:17:59.81 ID:XH5wI1Z90.net] A. 消したbranchの情報が確認出来るのって、reflogsだけ？ B. あと、branchは線だ！ってマニュアルは言ってるけど、点だよなこれ？ （ドキュメントか実装のどちらかが間違ってると思うが) 以下git-flowを真似てるとして、gitkと同様に下から上にcommitして、 impl5@feature5, merged to develop and master, add tag of "Version1". impl4@feathre4 impl3@feature3 impl2@feature2, merged to develop, add tag of "Version0". impl1@feathre1 impl0@feature0 initial@master, develop としたとする。 このとき、featureXを一々作っては消させてるのだから、 何か簡単に一覧に出来るコマンドがあるべきだが、無さそう。(git log --walk-reflogsで探すことは出来るが) 正直あとから参照することはほぼ無いが、何かあってもいいと思うが？---(A) 850 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 18:19:31.52 ID:XH5wI1Z90.net] そして、どうやらGitはブランチローカルという感覚がないらしく？ どのブランチにいても同じ結果が出るのはどうなのよ？---(B) 具体的には、この場合、 masterブランチでは、HEAD~1はinitialを指し、(master上での一つ前) developブランチでは、HEAD~1はimpl2を指すべき(develop上での一つ前) だと思うのだが、どこにいてもHEAD~1はimpl4を指してしまう。 つまり、HEAD~Nの探索先はグローバルであり、それは.git/objects下のツリーそのものらしい。 つかね、masterブランチにいた場合、 git diff HEAD~1 HEAD で前回のリリースと今回のリリースの違い git diff HEAD~2 HEAD で前々回のリリースと今回のリリースの違い git log ではmasterブランチ上のリリースした物のcommitログだけに絞られて表示 じゃないと実用的な意味がないと思うんだけどさ。 masterにはmergeしかしない運用なら通常は漏れなくタグが打たれ、「点」のアクセスはタグで出来る。 よって残るは「線」のアクセスだが、ブランチは「線」になってない。 実装はよく知らんが、ブランチを切って増えるのは以下の2つで、 .git/refs/heads は先頭「点」、 .git/logs/refs/heads はlogだから、「線」の為の物が無さそう。 本来ブランチはDBで言うINDEXで、CREATE INDEX develop ON git_tree WHERE branch='develop'; みたいなもので、これが「線」だと思うんだけどさ。 実際は「点」なのでHEADしか見えておらず、HEAD~1をブランチによって切り替えられない。 と思うのだが、理解間違ってる？ ここは多分仕様変更した方がいい。(直感的でないし、意味が分からない) けど今更出来ないだろうから、Gitの仕様の綻びの一つで、next-gitで修正されるべき案件だろうね。 851 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 18:20:37.25 ID:XH5wI1Z90.net] >>806 MacOSがFreeBSD系なのとLinusがGPLv3をボロクソ言ってたのは知ってたが、両方とも理由は知らなかった。 > GPLv3に追加されたバイナリの取り扱いに関する条項がmacOSのセキュリティポリシーに合わなくなった よく分からんが 852 名前：結局は両方ともここかな？ > プロプライエタリなドライバソフトをLinuxカーネルに読み込む際にDRMの技術を応用している件についてだと思います。 > http://japan.cnet.com/news/ent/story/0,2000047623,20095317,00.htm > GPLv3ではDRMを実装する場合はそのDRMのアルゴリズムに加えて秘密鍵も公開することを義務付けているので、 > そのようなことをしたらプロプライエタリなドライバを提供してもらえなくなるため、賛成はできない、と。 > https://srad.jp/story/06/01/29/1119224/ ただこれって、 GPLv3のコードを使ったバイナリを配布する際、そのバイナリと同じ物を作れるソースコードも配布しろ、だから、 GPLv3のBashをGit配布zipに同梱してもBashのバイナリだから何ら問題ないはずなんだけどね。 GPLv3だからだめだ、ならGPLv2(～2007)のBashでも十分だろうしさ。 やっぱりかなり政治的だよ。勿論譲れないのだろうけどさ。 [] [ここ壊れてます] 853 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 18:22:05.12 ID:XH5wI1Z90.net] >>807 >>809 お前ら狭量すぎ。OSS全体で盛り上がるんだ！という考えが無さ過ぎ。 diffもそうだが、bashの互換性が本当に問題なら、bashを修正すれば全員助かるだろ。 Gitコマンドをシェルで実装すると、unixコマンドの中にgitコマンドが混ぜ込まれてる形になる。 そのgitコマンドをcpに差し替え、unixコマンドだけの状態で環境依存で使い物にならないのなら、 それは立派なバグだから、bashの連中に投げれば直してもらえるよ。 自分で抱え込みすぎ。それでは回らなくなる。(のが一般的だが、バザールだからなあ…) ただGNUとは根本的にウマが合わないだろうよ。 仕様はグダグダ、ソースコードはゴミ、でも回り続けてるのだから、GNU(伽藍)から見たら何じゃあこれは！！！ってなる。 Git側にはGNUの開発速度はどうにも認められないだろうしね。 854 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 8b14-Tk+f) mailto:sage [2022/11/04(金) 19:16:09.99 ID:EF7BixRC0.net] > お前ら狭量すぎ。OSS全体で盛り上がるんだ！という考えが無さ過ぎ。 だからgitの話はgitの中で盛り上がればいいだろ 勝手に他人の家で盛り上がるな ば～か 855 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 8b14-Tk+f) mailto:sage [2022/11/04(金) 19:18:48.53 ID:EF7BixRC0.net] >>817 あとgitをbashに依存させるな 856 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 8b14-Tk+f) mailto:sage [2022/11/04(金) 19:19:54.54 ID:EF7BixRC0.net] bashがなんでも修正を入れるわけがない それは俺の仕事じゃないと言って断られるが落ち bashをぶくぶく太らせるな 一つ事だけやらせろ 857 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 19:54:32.33 ID:fRhzbJ/d0.net] >>816 GPLv3ではバイナリを配布する際にそのバイナリをユーザがソースからコンパイルしなおして入れ替え可能でなければいけないという条項になっているらしい MacOSやiOSのアプリやストアから配布するAndroidのアプリなんかの今どきのバイナリ配布は、署名済みバイナリしか実行できないから、ここにGPLv3の物を入れるとライセンス違反になる 858 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 19:57:10.42 ID:fRhzbJ/d0.net] >>817 GNUは別に開発組織ではないから統一的な開発ポリシーなんてものはないが、 GPLv3に移行するようなFSF管理下のGNUプロダクトは、歴史も古いし、比較的少数のおっさん達が気ままに管理してることが多いので、OSSと呼ばれるようになる前からの伝統的なUNIXフリーソフトのべたなソースツリー構成なものばかり たとえばbashのソースコード構成なんてgitみたいにトップディレクトリ下に組み込みコマンドの実装コードがだらだら並んでてgitと変わらん 859 名前：デフォルトの名無しさん [2022/11/04(金) 20:10:08.60 ID:jUM5cpqM0.net] どのOSでメインに作業してるのかわからん感じだな。 LinuxはCでモノリシックだとDISり、GNUコマンド群でないmacOSも� 860 名前：桝RDISり、 Windowsなんか論外って感じだろ。 3OSぐらい使ってたらとてもシェルなんか信用できないけどな。 [] [ここ壊れてます] 861 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 21:06:47.76 ID:XH5wI1Z90.net] >>822 いやそこまでは全然見てない。 今回の仕様とパッチの顛末見て、他もそうだと勝手に推定してる。 読む価値のないコードのはずだから。(物によって全然違うかもしれんが) ただこれで回ってるのは事実だからな～。ちょっと観戦モードだ。 まず既に言ってるが仕様がグダグダ。 仕様は追加は簡単だが、削除することは基本的に無理なので、厳選しないといけないのに、まるで出来てない。 つまりこの辺の常識的な長期保守戦略をまるで知らない奴がやってて、止める奴もいないということ。 そして今回のメモリリークだが、確保したらそこで寿命も確定する、実装が一番簡単なタイプで、 これをリークさせるようなら話にならない。 ただそれでもミスることはあるが、出てきたパッチがこれまたグダグダで、Cのメモリ管理の基本を完全に無視してる。 レビューがあったら見た瞬間落とされるソースだ。そりゃリークするよな、としか思わない。 (ただし第２弾、第３弾も出てきて、ましになりつつあるが、それでも方向性を根本的に間違ってる。 とはいえ、展開が異常に早いのも確か) だから、通常の開発をやっているであろうGNUでは、仕様のレビューでも、コードのレビューでも落とされる。 だけどGit側にその理由を理解出来る奴がいないからこうなわけで、当然ブチ切れる。 そして喧嘩別れ、だったら俺らで作るからいいよ、でforkして突っ走ってるだけのように見える。 若すぎる。 ただそれでも実装能力だけはあるので、diffはGNUより装飾周りが断然進歩してる。 これはやっぱりGNUdiffと一緒にやってた方がみんな幸せだったと思うよ。 上手く導ける奴がいれば、 というより普通に長期保守したことがある奴が上層部に一人でもいれば、この辺は簡単に修正出来ると思うのだけど、 それは伽藍タイプの話で、バザールだとどうにもならないのかもしれんし、 突っ走らせないとプロジェクト自体が死ぬのかもしれんし、(サメみたいにね) よく分からん。 862 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 21:10:52.33 ID:EF7BixRC0.net] 口だけ達者で何もできない無能 863 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 21:14:59.38 ID:PwG12fTHM.net] >>824 GNUが何なのか全く理解できていない 864 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 21:27:19.25 ID:PwG12fTHM.net] >>823 自分が理解できないものは全部糞 理解力が致命的に弱い この2つが合わさると全方面Disることになる 865 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 21:35:53.62 ID:SQ9pznPg0.net] >>817 何で自分の関心の向かないOSSにわざわざ貢献しないといけないんですか？ 金も貰えないのにそんなの苦行でしょう、アホらしい それとも君はLinusに向かってそれを要求できるほどGNUに対して貢献してるんですか？ 866 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 21:39:58.51 ID:EF7BixRC0.net] bashの方を直せって言うなら GNU bashのプロジェクトに殴り込みをかければいいじゃん お前が 867 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 21:54:21.97 ID:XH5wI1Z90.net] >>828 逆だよ。他人に投げられることは他人に投げろと言ってる。 bashのバグだってことになれば、勝手に直してもらえるだろ。 自分で対応するのは、直してもらえないのが確定してからでいい。 >>829 そもそも俺はbashの互換性で苦労した試しがない。 ただそもそもOS跨いでシェルスクリプトを持っていった試しも無いけどな。てかそんなこと普通せんし。 あーだから、最悪Linux/Windows/Mac用と3種類用意すればよかったんじゃね？C化よりは楽だろうよ。 868 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 21:55:50.76 ID:EF7BixRC0.net] > 逆だよ。他人に投げられることは他人に投げろと言ってる。 なんのために？ 869 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 21:56:20.74 ID:EF7BixRC0.net] > bashのバグだってことになれば、勝手に直してもらえるだろ。 だからお前がbashに通報しろって お前という他人に投げたぞｗ さっさとやれ 870 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 7997-uk66) [2022/11/04(金) 22:08:26.91 ID:jUM5cpqM0.net] >>8 871 名前：30 え、Cでプログラム書いたことないの？OS間の違い、標準Cライブラリの方がよっぽど互換性に苦労することないよ… 考慮しなければならないのはファイルシステムと改行コードぐらいだろう。 [] [ここ壊れてます] 872 名前：デフォルトの名無しさん (ﾌﾞｰｲﾓ MM33-ntN1) mailto:sage [2022/11/04(金) 22:17:50.42 ID:qsZ+zSWqM.net] まあおまえら落ち着け>>815とか見る限りこいつはひとりではGitを理解できない 炎上させて答えを引き出そうとしてるから餌を与えちゃいかん ほっとけばすぐいなくなるよ 873 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 22:48:48.23 ID:XH5wI1Z90.net] >>834 ああ、@1か、これは失礼。 ただお世辞にも分かりやすいとは言えないねこれは。 まあでも、ならbranchを残す意味はあり、>>815は取り下げだな。 >>814については引き続き募集中。 874 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 22:50:35.62 ID:XH5wI1Z90.net] @{1}ね、まあ分かると思うけど 875 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 23:04:09.79 ID:7RpVnNq7M.net] >>836 @{1}に気が付くとはさすが軍師殿ｗｗｗ 876 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 00:48:19.73 ID:yugci9j10.net] HEAD~1 で一つ前のリリースとか言ってて爆笑 リリースごとに一回だけコミットするつもりなのか？ 永久に git 理解できそうにないな 877 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 01:35:03.83 ID:CLSrxuim0.net] ネットのクソ記事で独学するより、まともな本買って学習すればいいのにな つうかあれか、gitの仕様の粗探しがしたいから使い方とかどうでもいいのか 878 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 01:42:19.97 ID:zPyCNtrD0.net] そもそも一つ前ｗみたいな考え方するようなものじゃないよなｗ 879 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 03:02:36.62 ID:0q4aURph0.net] 自分が理解できないから、知ってるシェルスクリプトにすがってるだけだな POSIX原理主義者と一緒。POSIXの名前を勝手に使って シェルスクリプトしかできないのをごまかしてる gitを利用してシェルスクリプトしかできないのをごまかしてる 880 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) mailto:sage [2022/11/05(土) 09:15:20.90 ID:646uiMLL0.net] >>717 ちなみに書く側のコマンドは hash-objectのようだ。 多分初期はPlumbing Commandsをシェルスクリプトでラップして各上位コマンドを提供してたのだろう。 そして俺にはこの程度のシェルスクリプトが環境依存するとはとても思えないんだけどさ。 >>821 って、ふと気づいたが、俺が使ってるのはGitBashだったわ。 現在の公式版にもGitBashバイナリは同梱されてるし、ライセンスがどうこうという問題は無いか、解決されてるよ。 Macは政治的だとして、Linusはその辺実務的に見えるから、 GPLv3をボロカス言って自分はGPLv3には参加しないが、(これは正当な権利で全く問題ない) GPLv3を殺す為にGPLv3のプロダクトの同梱すらしない、みたいなことはしないのだろうよ。 881 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) mailto:sage [2022/11/05(土) 10:38:45.29 ID:646uiMLL0.net] >>814 公式のcontribに置いてあるユーザー製作の勝手ツールにあるのは発見した。 つまり熟知してる公式からみても面倒な作業だと認めているわけだ。 解決というよりは諦めと納得だが、これも質問を閉じる。 > https://zenn.dev/yoichi/articles/git-restore-branch ちなみに、branchを『後から追加』は出来るか？ いやそんな使い方はおかしい！禁止だ！かもしれんが、 やはり俺にはbranchはただの(DBにおける)INDEXで、 随時落としたり作ったり復活させられないと使いづらい。(のではないかと予想している) ただ、要はreflogを偽造すればいいだけのようだが、 再実装は時間の無駄で 882 名前：しかないので、既にあればそれを使いたい。 [] [ここ壊れてます] 883 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 11:40:31.33 ID:zDjINlW+0.net] >>842 index-stageを理解してないおまえにはわからないかもしれないけど、 DBへ登録されるのはwork tree上のファイル丸ごとでない場合もあるし、 逆にDBからwork treeへ展開されるのもファイルの中の一部分の場合があるから、 そんな単純にはいかない 884 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 11:40:56.02 ID:zDjINlW+0.net] >>842 Windowsはアプリを実行する上でコード署名が必須でないから問題にならないだけ 885 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 11:41:36.89 ID:zDjINlW+0.net] >>843 gitのマージを全然理解できてないからブランチを復活させたいとか思ってしまうんだな 普段の運用でスクリプトを使ってブランチを復活させたいとか思う羽目になることはあまりない ブランチがDBにおけるindexみたいなものとか、後から追加できる？みたいな疑問が生じるあたり、ブランチが何なのか全然わかってない reflogの偽造が必要という発想もかなりズレてるし、>>814 をみるとコミットの履歴がどういうものなのか理解できていないのだろう 886 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 12:57:19.46 ID:646uiMLL0.net] >>844 さすがにその程度は知ってるぞ。 ただ、一般的には git add -A で問題ないディレクトリ構成で使う方が多いんじゃないか？ まあそれはさておき、 要は、正しくソフトウェアが構成されてれば、cat-file/hash-object を組みで交換すれば、 末端のファイル形式は自由に選べるって事だよ。sshにすればネットワーク先にも余裕だ。 つってももうこの話は通じないのでいいが。 887 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 13:13:08.87 ID:646uiMLL0.net] >>845 つまり現行2.38.1のMac版にはBashバイナリが入ってないのか？ それでMacに元々入っているbash以外のshを使ってれば、そりゃ問題は発生するだろうさ。 > https://qiita.com/ko1nksm/items/59c2e8a7afa969af8212#:~:text=Mac%20%E3%81%AE%E3%82%B7%E3%82%A7%E3%83%AB%E3%81%AF%20macOS%2010.15%20Catalina%20%E3%81%A7%20bash%20%E3%81%8B%E3%82%89,%E3%81%AB%E5%A4%89%E3%82%8F%E3%81%A3%E3%81%9F%E3%81%A8%E4%B8%80%E8%88%AC%E3%81%AB%E8%A8%80%E3%82%8F%E3%82%8C%E3%81%A6%E3%81%84%E3%81%BE%E3%81%99%E3%81%8C%E3%80%81%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB%E3%81%95%E3%82%8C%E3%81%A6%E3%81%84%E3%82%8B%E3%82%B7%E3%82%A7%E3%83%AB%E3%81%AF%E3%83%90%E3%83%BC%E3%82%B8%E3%83%A7%E3%83%B3%E7%95%AA%E5%8F%B7%E3%81%AE%E9%81%95%E3%81%84%E3%82%92%E9%99%A4%E3%81%84%E3%81%A6%E4%BB%A5%E5%89%8D%E3%81%A8%E3%81%BB%E3%81%A8%E3%82%93%E3%81%A9%E5%A4%89%E3%82%8F%E3%81%A3%E3%81%A6%E3%81%84%E3%81%BE%E3%81%9B%E3%82%93%E3%80%82%20%2Fbin%2Fsh%20%E3%81%AF%20POSIX%20%E3%83%A2%E3%83%BC%E3%83%89%E3%81%A7%20bash%20%28%2Fbin%2Fbash%29%20%E3%82%92%E8%B5%B7%E5%8B%95%E3%81%97%E3%81%BE%E3%81%99 Macとしては署名済みじゃないとウイルスかもしれないので認められず、 GPLとしては署名付けるならその署名を作るソースも公開しろと言ってるわけ？ どっちも拗らせすぎだが、 一般論としては、Mac側に「開発者オプション」で「署名がないバイナリの動作を許可する」があれば済む話では？ 実際自分でコンパイルしたバイナリを動かせないと困るし。 ただ、Macってスマホと同一化したからこれって脱獄になるんだっけ？ ならまあ、Gitの為に脱獄はないし、こじれるのは分かるが。 まあ、正直つき合いきれないが、俺なら、C化ではなく、 bashの機能を諦めてshの機能だけで書き直す方を選択するけどね。 888 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 13:19:32.87 ID:zDjINlW+0.net] >>847 実際仕事すればわかるが add -Aで綺麗なコミットを作れるように整備されてるリポジトリはあまり無い デバッグしながらコミットしていくときは add -p を使うことがとても多い 889 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 13:20:48.95 ID:zDjINlW+0.net] >>848 https://www.infoq.com/jp/news/ 890 名前：2019/07/macos-ditches-bash-for-zsh/ [] [ここ壊れてます] 891 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 13:57:20.56 ID:0q4aURph0.net] git add -Aで十分とかさぁ、開発経験なさすぎだろ それはgitをバックアップとか途中セーブ機能とでも思ってんのか？ 1 commit = 一機能の追加とか、一日の最後にやるものとか思ってるんだろ 通常なにかのバグの修正とか 複数の個別の問題の複合なのに それ全部まとめんな 892 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 13:58:29.56 ID:646uiMLL0.net] >>846 そもそも俺含めて大半のプログラマはGitを理解したいとは思ってなくて、 単に便利だから使ってるだけだと思うがな。 理解せずに使えるのならそれに越したことはない。 (この価値観が相容れないのは理解したからもういいが） 君はGitを履歴追跡ツールとしてしか見てないようだが、 俺はもっと一般的に、Git形式のDBとして見てる。(INSERT履歴が保持されるDB) そして、俺は>>808と同意見で、 開発が今現在行われていないブランチは閉じられてた方が見やすいと思ってる。 常時存在するのはgit-flowでいうdevelopだけで、masterやreleaseはタグでよく、 hotfixを作るならまずmasterブランチを復活させ、そこからhotfixを発生させたほうがいい。 (なおreleaseブランチは最後にバージョンを打つ奴にはいいが、 俺は先にバージョンを打ってから更新部分を実装するので、俺のワークフローには合わない） それ以外にも、featureX付加時の変更漏れ/不適切な変更によるバグ挿入が後で発覚することはあるから、 git-flow的にfeatureを作っては消しで行くなら、ブランチの復活はプログラマには疑問のないことだ。 featureX_patch0と新たな変更扱いしてもgitオブジェクトツリー自体は同じだが、 名前が似てるだけの別物扱いになるので、 featureXの開発『線』をメンテナンスする気なら、branchの復活が必要になる。 実は、とりあえず同じ名前で作り直せば自動的にくっつく馬鹿向け仕様か？と試してみたが、 まあGitの文化でこれはなかった。 が、まあ、俺的にはこれであって欲しかったね。 「同じ名前が昔ありましたが、そこにくっつけますか？(Y/N)」「Y」 「いい加減にしてくださいよ、何回目ですか？」「うるせーよ」みたいな。 ただこれ、branch側は --list オプションで表示を簡単に絞れるから、 Gitの思想としてはbranchは「消さずに全部残しておけ」で、 git-flowがGitの思想と合ってないだけだね。ならツール用意しとけと。 893 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 14:02:51.18 ID:0q4aURph0.net] >>852 世の中に理解しないで使えるものなんてない 894 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 14:04:13.47 ID:0q4aURph0.net] 大体gitの使い方を理解したいと思ってるやつはアホ 理解するのはバージョン管理の仕方だ こうやってツールの使い方を学ぶことが理解だと思ってるから gitがなくなったらどうしよう また新しいことを学ばなきゃいけないってなるんやろ 895 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 14:19:41.99 ID:W/77BOuWM.net] >>854 git そのものを理解すること諦めたか でもお前使い方の方も盛大に勘違いしてるよ 896 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 14:24:19.56 ID:646uiMLL0.net] >>851 > それはgitをバックアップとか途中セーブ機能とでも思ってんのか？ > 1 commit = 一機能の追加とか、一日の最後にやるものとか思ってるんだろ そうだぞ。 ブッ込んでおけば後で何とでもなるただのバケツでしかない。 バケツの使い方を学べとか、知るかボケだ。 後でバケツから探し出すハメになった時、取り出し方をググって取り出せれば十分だ。 大方、プログラマの大半はこの程度の認識のはずだぞ。 そしてお前が望む、綺麗な管理記録は、これのサブセットでしかないんだよ。 だから例えば俺が780で言ったように、「コミットメッセージが空」を除外すれば簡単に得られる。 今のGitにこの機能がないだけ。（まあ近い機能はあるが） DBならWHEREに条件を付加すればいいだけの楽勝案件で、Web系ならみんな出来るよ。 sedのワンライナーで済むことすらCで実装するGit界隈だと誰も出来ないのだろうけどさ。 まあGitにSQLインタフェースを付け加えればWeb系の奴等は文句言わなくなるんじゃないかな？ 連中にとっては直感的になるから。 897 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 14:34:25.48 ID:0q4aURph0.net] > 大方、プログラマの大半はこの程度の認識のはずだぞ。 お前の周りの無能集団だけだろ 898 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 14:35:58.29 ID:0q4aURph0.net] 一体どこのプロジェクトに「2022年11月4日の仕事終了時のセーブ」なんてコミットがあるんですかねぇ 899 名前：デフォルトの名無しさん mailto:age [2022/11/05(土) 14:42:21.04 ID:oTMzuhJSa.net] >>858 それなんて、俺の前の職場 900 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 14:46:20.49 ID:0q4aURph0.net] データの取り出し方なんか知っていても 過去のコミットのミスを簡単に直せないなら バージョン管理は苦痛になるし やっぱりツールの使い方だけ知ってバージョン管理をしたことがないんだろうな バージョン管理が不便だからgitが作られたんだぞ 901 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 14:58:06.66 ID:646uiMLL0.net] >>859 俺はそれでいいと思うけど。 記録してない方が問題で、記録さえしてあれば、ゴミとマジを簡単に分離出来れば十分だ。 >>860 今のGitの修正は十分苦痛だよ。 修正させたくないから面倒にする、は間違いで、 簡単に修正出来るが、修正したことも履歴に残るようにする、が正しい。 902 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 15:03:35.62 ID:0q4aURph0.net] × 俺はそれでいいと思うけど。 ○ 無能はそんなことをしている。 まずさぁ、gitというかバージョン管理の基本を理解してないんだからさ そこから勉強しなよ 903 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 15:04:40.67 ID:0q4aURph0.net] > 簡単に修正出来るが、修正したことも履歴に残るようにする、が正しい。 お前はテキストエディタで保存するたびに gitにセーブしろって言ってんのか？ｗ 904 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 16:06:55.57 ID:646uiMLL0.net] >>863 俺が言ってる「修正」は、Git自体の修正で、 > なのでマージ前のブランチをレビュー対象とする開発では push の際に整理することになる (778) の場合に、SQL的に、 DELETE FROM my_repo WHERE branch='featureX' AND commit_message=''; あるいは、 CREATE INDEX beautiful_featureX ON my_repo WHERE branch='featureX' AND commit_message=''; で済むのに、何故Gitにつき合ってグダグダやらねばならんのだ？ということ。 それとは別に、ちょこまかcommitしても、俺は構わんと思うけど。 上記のように、それを１コマンドで除去出来れば、実務上何ら問題ない。 粒度が細かすぎてDBが膨れあがるなら、その部分を定期的にバックアップに切り出していけばいいだけ。 bitcoinはこの方式だ。 >>862 多分根本的に違うのは、 俺： 俺のワークフローに合うようにツールをカスタマイズする 863： Gitのワークフローに合わせてgitを使え、それ以外認めない！ なんだよ。 Linusが個人的に開発したんだからGit自体はそれでいいんだが、 全世界でLinuxと同じワークフローが適切なわけではない。 905 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 16:10:37.55 ID:5Oe/8sYX0.net] >>864 アホなの？コミットメッセージは毎回入れるものだ 906 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 16:11:36.07 ID:5Oe/8sYX0.net] >>864 > 全世界でLinuxと同じワークフローが適切なわけではない。 だからgitはいろんなワークフローに対応してるんだろうが お前のはバージョン管理のワークフローではない ただのバックアップのワークフローだ 907 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 16:45:19.71 ID:CLSrxuim0.net] まあ1人プロジェクトみたいだし好き勝手やらせればいいさ 908 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 16:54:40.83 ID:5Oe/8sYX0.net] コミットメッセージが空だったら～とかわけわからんなｗ 909 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 16:56:10.72 ID:5Oe/8sYX0.net] 行単位で独立してるデータベースのデータじゃないんだからさぁ ソースコードは前後の歴史とつながってる DELETEなんちゃらみたいに一つだけ取り除くことが出来るのは稀 910 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 17:21:12.99 ID:646uiMLL0.net] >>869 それは当然UIの話で、当たり前だが� 911 名前：熾狽ﾌリンクは接続し直すんだよ。 そしてそれをユーザーには見せない。 多分ここら辺の階層の話がGitには存在しないんだよ。 だからユーザーがviでリンク書き換えろとかの勢いだろ。 超密結合だし滅茶苦茶だよそれは。 [] [ここ壊れてます] 912 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 17:22:28.46 ID:5Oe/8sYX0.net] >>870 都合が悪いからって無視するな 前後のソースコード関連してるから 途中のコミットを取り除くことはできないと言ってる 913 名前：デフォルトの名無しさん [2022/11/05(土) 17:28:35.59 ID:B2i8Nuif0.net] つまり、両親がイブに中出ししてお前が生まれたという歴史において、 イブの中出しだけを無かったことにはできないと言うことだね その後の歴史でお前が存在するのはおかしいし 914 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 17:30:55.67 ID:646uiMLL0.net] >>871 何言ってんだ？ 中身はただの単方向リンクリストだぞ。 リンク先が複数のこともあるが、それでも問題なく抜ける。 ただそれ以前に、俺は既に言ったとおり「記録されてないほうが問題」とするので、 CREATE INDEXを使うが。これなら理解出来るか？ だったら、このINDEX対象をちょうど全部含むようにリンクリストを新しく作り直せばいいだけ。 それがDELETEしたものと同じ物になる。これで理解出来るか？ 915 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 17:40:00.52 ID:5Oe/8sYX0.net] >>873 じゃあ抜き取ってみ ・commit 1「aaa を追加」 aaa ・commit 2「bbb を追加」 aaa bbb ・commit 3「bbb を ccc に置き換えた」 aaa ccc ここからcommit2を抜き取ったときの commit3の修正内容をよく読んでみろ 916 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 17:44:37.25 ID:W/77BOuWM.net] >>873 残念だけどそこから間違ってる Gitのコミットのリストは単方向リンクリストではない なのでリストの途中のコミットを削除したり途中に追加できない 917 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 17:58:44.17 ID:646uiMLL0.net] >>874 ああコミットメッセージについては考えてなかったが、 俺ならそのままぐちゃっと貼り付けるけど。 つまり、 ・commit 1「aaa を追加」 aaa ・commit 3「bbb を追加」「bbb を ccc に置き換えた」 aaa ccc になる。 918 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:03:19.55 ID:646uiMLL0.net] >>875 親が複数あるだけの単方向リストだよ。 まあこれを単方向リストと呼ぶかは微妙だから、ツリーと言った方が通じたか？ ツリーが複数重なり合った状態になってるだけだよ。 単線の A<-B<-C なら A<-C になる。これは自明だよな。 マージの場合、(BがADのマージ結果ね） A<-B<-C D<-| を A<-C D<-| にする。 919 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:18:30.70 ID:5Oe/8sYX0.net] >>876 ようやく理解したか。 だからお前がやってるのはただのバックアップを取ってるだけだっていってんだよ バージョン管理というのは何をどう変えたかという変化を記録するものだ スナップショットじゃねーんだよ、あーほ 920 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:19:21.47 ID:5Oe/8sYX0.net] >>876 bbbの話がないのだから、 書き間違えなのか全く区別がつかない バグコミットメッセージだな 921 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:21:44.83 ID:5Oe/8sYX0.net] >>873 > ただそれ以前に、俺は既に言ったとおり「記録されてないほうが問題」とするので、 だからお前のテキストエディタでの変更内容を全部記録するって言ってるんだろ？ ファイルを保存するたびにコミットするんだろお前は？ バージョン管理で記録するのはソースコードの修正履歴であって お前個人の作業履歴じゃねーんだよ 使い物にならないゴミコミットを作るな 922 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:26:48.37 ID:646uiMLL0.net] >>878 ああ履歴についての認識が違うんだな。了解した。 履歴は、 俺： スナップショット＝「点」の並び 君： 変更した線の並びで、それはcommitメッセージに現れる。 それだと、commitメッセージが間違ってる場合はどうしようもなくなるだろ。 あくまでソースコードが重要で、どこをどう変えたかはdiff取れば済むだけの話、 commitメッセージなんて目安に過ぎないんだよ。 Gitもこちらの立場に近く、VCSとしては珍しく(と聞いているが俺はそこまで詳しくないが） 差分ではなく本体を記録するだろ。 923 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:31:31.07 ID:5Oe/8sYX0.net] >>881 > 履歴は、 > 俺： スナップショット＝「点」の並び だから、それはバックアップで言うって最初から言ってるだろ お前が完全に間違ってるんだよ > それだと、commitメッセージが間違ってる場合はどうしようもなくなるだろ。 修正しろよ。それが出来るように作られているだろ > commitメッセージなんて目安に過ぎないんだよ。 はっｗ　バージョン管理の素人が。 コミットメッセージの重要性を知らない時点で終わってるよ 924 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:32:44.57 ID:646uiMLL0.net] >>880 > ファイルを保存するたびにコミットするんだろお前は？ そこまではしないが、1日10回とか平気ですることもあるし、それが問題だとも思わない。 この辺はポリシーだし、好きなようにすればいいと思うがね。 間違いなく言えるのは、俺は美しいソースコードを目指しているのであって、 美しいコミット履歴を目指しているわけではないんだよ。 そしてコミット履歴が過剰なら、落とせばいいだけだろ、という話。 無い履歴からは生成することは不可能なのだから、大きすぎる粒度より、小さすぎる粒度の方がいいに決まってる。 所詮commitメッセージなんて当てにならないし、diffが取れれば全く問題ない。 925 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:32:45.04 ID:5Oe/8sYX0.net] > Gitもこちらの立場に近く、VCSとしては珍しく(と聞いているが俺はそこまで詳しくないが） > 差分ではなく本体を記録するだろ。 だから最初からバージョン管理は差分を記録するものであり gitの優れた点が、発想の転換で 本体を記録することで差分を表現することにした点なんだろ 実装の話とごっちゃにするな そういうところが技術的に未熟なんだよ 926 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:33:34.01 ID:5Oe/8sYX0.net] >>883 > そこまではしないが、1日10回とか平気ですることもあるし、それが問題だとも思わない。 そりゃお前が素人だから問題であることに気づいてないだけ 誰もやってないからね > この辺はポリシーだし、好きなようにすればいいと思うがね。 お前が未熟だから反論できずにポリシーってことにしようとしてる 927 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:33:50.55 ID:zDjINlW+0.net] >>877 分散バージョン管理ではですね、リポジトリのコピーがばらばらに複数存在することが前提なので、 あるひとつのリポジトリのコミット履歴が A<-B<-C で、他のリポジトリではこれが A<-C になっているという状況は不味いんですよ なのでGitではそれができないようにデータ構造が設計されています 928 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:34:49.14 ID:5Oe/8sYX0.net] > 間違いなく言えるのは、俺は美しいソースコードを目指しているのであって、 > 美しいコミット履歴を目指しているわけではないんだよ。 コミット履歴は「使うもの」だって分かってないようだな 一部のコミットだけ抜き取って 他のブランチに組み込む 使うものだ お前はただ見れればいいと思ってる バージョン管理を理解してない 929 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:35:50.16 ID:5Oe/8sYX0.net] >>883 > 所詮commitメッセージなんて当てにならないし、diffが取れれば全く問題ない。 お前が作るコミットがクソだから、使いものにならなくなっているだけだなｗ 930 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:39:58.47 ID:646uiMLL0.net] >>882 まあ君と仕事することは無さそうだから別に問題ないけど、 > 修正しろよ。それが出来るように作られているだろ コミットメッセージをいくら修正したところでそもそも意味無いんだよ。 管理してるのはメッセージじゃなくてソースコードなんだから。 それで、重要なコメントはソースコード上に書いてるから、diff取れれば十分なんだよ。 コミットメッセージは、あくまでGit上から探し出すラベルでしかなくて、何をやったかはdiffで見るし、それ以外にないよ。 > はっｗ　バージョン管理の素人が。 > コミットメッセージの重要性を知らない時点で終わってるよ まあ俺はGitの達人になりたいわけでもないんで、これで問題ないよ。 931 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:40:40.33 ID:5Oe/8sYX0.net] > コミットメッセージをいくら修正したところでそもそも意味無いんだよ。 それはお前だけの感想ですねｗ 932 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:41:08.69 ID:5Oe/8sYX0.net] > まあ俺はGitの達人になりたいわけでもないんで、これで問題ないよ。 バージョン管理の素人だって言ってる お前、他の人と一緒に仕事ができないよｗ 933 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:41:43.46 ID:5Oe/8sYX0.net] > コミットメッセージは、あくまでGit上から探し出すラベルでしかなくて、何をやったかはdiffで見るし、それ以外にないよ。 途中を抜いといて、何をやったかなんてわかるわけ無いだろｗｗｗ 934 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:43:50.28 ID:5Oe/8sYX0.net] >>889 こうやってコミット履歴をちゃんと見れて なんの変更をしたのかわかるようになるまで頑張れよ https://github.com/freebsd/freebsd-src/commits お前のコミットは汚すぎて 使い物にならんのだわ 935 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:44:39.97 ID:646uiMLL0.net] >>884 > gitの優れた点が、発想の転換で > 本体を記録することで差分を表現することにした点なんだろ これは違う。 というかね、どっちを記録したところで、正常に動いていればどのみち任意の履歴を取り出せるから関係ないんだ。 ただ、ファイルシステム等がぶっ壊れて、断片的にしか取り出せなくなったときに、Gitみたいに本体を記録してる方が断然強い。 だから基本は「一番大事なもの」で記録するようにしなければいけない、という観点だったのだけど、 まあこれはフォールトトレラントにしろという話で、ちょっと蛇足ではあったね。 あまり関係ないからこの話は終わりで。 936 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:45:34.09 ID:5Oe/8sYX0.net] > これは違う。 だーかーら、素人のお前の意見なんか聞いてない 937 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:50:58.69 ID:5Oe/8sYX0.net] > ただ、ファイルシステム等がぶっ壊れて、断片的にしか取り出せなくなったときに、 gitは速度のためにスナップショットにしてると書いています https://git-scm.com/book/ja/v2/%E4%BD%BF%E3%81%84%E5%A7%8B%E3%82%81%E3%82%8B-Git%E3%81%AE%E5%9F%BA%E6%9C%AC 938 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:53:08.44 ID:5Oe/8sYX0.net] https://www.techpit.jp/courses/33/curriculums/34/sections/286/parts/965 なぜスナップショットとして記録するのか スナップショットとして記録することで、複数人で開発する時のスピードを上げることができます。 詳しくは後ほど解説しますが、複数人での開発の際、並行して開発できるよう、 Gitではブランチというものを切って、バージョンを枝分かれさせて開発していきます。 このブランチでバージョンを枝分かれさせる際や、ブランチを統合(マージ)する際にスナップショットだと非常に作業が速くできます。 Gitがデータを差分というかたちで持っていると、ブランチを切ってマージする時に差分をいちいち計算しなければなりません。 しかしスナップショットで保存しておけば、差分の計算をしなくて済む分、とても速くブランチを切ったりマージできるようになります。 ちなみに、Git以前のバージョン管理ツールの多くは差分としてデータを保存していて、ブランチを切るのに大変時間がかかっていました。 大規模なプロジェクトになると数十秒かかったりすることもありました。 Gitだとこの作業が一瞬でできます。こういった事情があって、Linuxの作者のリーナス・トーバルズは 当時、大規模開発であったLinuxカーネル開発のバージョン管理システムを自作しました。これがGitのスタートです。 939 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:56:37.48 ID:646uiMLL0.net] >>886 ああなるほど、ブロックチェーンよろしく親のhashデータも自分のhashに入ってるのか。 しかしそれは、改竄がばれるだけで、リンクを繋ぎ直すことが出来ないわけではないね。 というかね、それは本体ツリーの話で、 余分なcommitはrepoから消せ！とする君らにとっては問題だが、 俺みたいに、スカスカのINDEXでbranchを再構成するのはその場合にも全く問題ないはず。 ところで、 実は今もbranchの実体がどこにあるのか見えてない。 見る限り .git/logs/refs/heads/各branchにしかなさそうなのだけど、ここかね？ これだと毎回reflogを動的に解釈することになるが。 実装としておかしくはないが、普通はこうはしないので、ちょっと不可解だ。 なおオブジェクトツリーにはbranchのデータは無く、branchは各オブジェクトへのリンクの入った配列だと見てる。 だからシャローコピーでしかなく、後からでもいくらでも作れるだろ、という話。 940 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 19:03:07.94 ID:5Oe/8sYX0.net] > 後からでもいくらでも作れるだろ、という話。 だから速度重視だって言ってる 941 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 19:03:54.30 ID:5Oe/8sYX0.net] >>898 君、ほんと知らないなら黙ってたほうがいいよ 恥ずかしいだけだから 942 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 19:05:11.02 ID:5Oe/8sYX0.net] >>898 > 余分なcommitはrepoから消せ！とする君らにとっては問題だが、 余分なコミットじゃなくて、 コミットとして使えないものにする バグコミットを消せと言ってるだけ 943 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 19:21:59.71 ID:zDjINlW+0.net] >>898 まあもう面倒臭くなってきたので全部説明しちゃうが 結果的に親のhashが自分のhashに含まれることになるのだけど、実際には親のhashは自分のコミットオブジェクトに含まれている その自分のコミットオブジェクトから計算して求めるのが自分のhash 親の祖先に変更があれば自分のコミットオブジェクトの作り直しになってhashも計算し直すことになりそれはもう自分ではない ブランチの実体はコミットオブジェクトのハッシュひとつだけ それで事足りる ず〜〜〜と思っているんだがどう考えてもお前のブランチへの理解はオカシイ 内部的な構造の話ではなくてユーザとして使う上でも問題があるような酷い理解に見える だから >>815 みたいな謎発言がでてくる DBのINDEXみたいなもの？とかの謎解釈で突き進まれてもついていけない 944 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 20:06: ] [ここ壊れてます] 945 名前：13.91 ID:646uiMLL0.net mailto: >>902 前半の内容は知ってるし、そのつもりで898を書いてる。 それはtutorial2に書いてあったから。 そこのhash値も混ぜてるかどうかは関知してなかっただけ。 ちなみにtutorlal2には「ここのhash値とは違うから、各自のhash値をコピペしてね」 と書いてあるが、実際は同じhash値が生成される。 だからどこまで混ぜ込んでるのかよくわからなった。 名前と時間も混ぜ込んでるぜ！と書いてあるが、どう見てもそうじゃない。 ただまあ、親ハッシュは混ぜ込んでるのは理解した。 > ブランチの実体はコミットオブジェクトのハッシュひとつだけ それは俺の最初の理解、「点」なんだよ。815の通り。エントリポイントだけ、というわけだろ。 ただそれだと、オブジェクトツリーは辿れるが、 master @{1}で「master branch上の」一つ前、という経路情報に変換することが出来ない。 つまり、HEAD~! != @{1} とするには、何らかの情報が何処かに必要なんだよ。 そして今のところ、reflogしかないので、そこを動的に辿ってるのか？みたいなことになってる。 だから「reflogを偽造」(843)なんて話になる。 言い換えると、エントリポイントからだと、親は辿れるが、 親が複数現れたとき(マージ）に、どちらから来たのか分からないのと、 fast-forwardマージでオブジェクトは一本道でもbranch上では飛ばしている場合に、その情報がないんだよ。 これはどこに格納されてるんだ？ [] [ここ壊れてます] 946 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 20:19:07.74 ID:646uiMLL0.net] すまん、分かると思うが、 HEAD~1 != @{1} 947 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 20:45:45.41 ID:zDjINlW+0.net] >>903 reflogのhashは、HEADが変わるような操作をしたときに、その操作の結果のHEADのhashを追記していくだけのログだよ このログがその後のgitの動作に影響を与えることはない HEAD@{0}が常に最新の操作に対応したhashに更新される だからたとえばmasterとfirstという二つのブランチを交互にcheckoutすればこんな感じになる $ git reflog 0956cde (HEAD -> first) HEAD@{0}: checkout: moving from master to first be7e7d7 (master) HEAD@{1}: checkout: moving from first to master 0956cde (HEAD -> first) HEAD@{2}: checkout: moving from master to first be7e7d7 (master) HEAD@{3}: checkout: moving from first to master 0956cde (HEAD -> first) HEAD@{4}: checkout: moving from master to first be7e7d7 (master) HEAD@{5}: checkout: moving from first to master 最後にcheckout firstしたので HEAD -> first になってる 948 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 20:59:53.75 ID:646uiMLL0.net] >>905 reflogがその形式なのは知ってる。 ただ、頭のポイントだけだと、903で言ったとおり、経路情報にならないだろ。 例えば、815の場合、再記するが、 impl5@feature5, merged to develop and master, add tag of "Version1". impl4@feathre4 impl3@feature3 impl2@feature2, merged to develop, add tag of "Version0". impl1@feathre1 impl0@feature0 initial@master, develop これで、master上で git diff @{1}　では、initial commit との差分 git diff HEAD~1　では、　impl4との差分が出るんだよ。 これが、master->impl5のエントリポイント情報だけだと出来ないから、 maseterはinitial->impl5に移動しましたよ、という経路情報が何処かに必要なんだ。 それで、git reflog では、 どこにswitchして、commit して、mergeした、という履歴が全部出るから、 （多分だが各HEADのreflogを全てcatして時系列にソートしてる） 解釈すれば可能ではあるけど、そんな面倒なことするか？普通はstaticにシャローコピーだろ、というのと、 reflog は gc されるので、reflogを頼りにする実装は不適切だし、 俺的にbranchを消したり復活させたりする使い方はヤバそうなんだよ。 だからその辺を確認してる。 それで、後で任意のオブジェクト群でbranchを作れるのなら、この辺心配ないのだけど、そうではなさそうだし。 949 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 21:04:51.93 ID:646uiMLL0.net] ちなみに、843の記事では、Git内のcontrib内のスクリプトが、 branchをreflogを参考に復活させるらしいので、reflog内の情報で足りてはいるらしい 950 名前：。 確かに目で見た限りそうだが、 でもそれだとreflogをgcするのは割と狂気の沙汰だから、おかしいよなーと思ってて。 [] [ここ壊れてます] 951 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 21:06:47.08 ID:646uiMLL0.net] ごめん、書き方が悪かった。 907は、gc対象となるreflogを本番情報として持つのは狂気の沙汰だなーということ。 復活させるときにそこにしか手がかりがないのは仕方ないとして、 生きてるbranchは普通はツリー情報をstaticに持ってるはずだが、見あたらないんだよ。 952 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 21:15:14.62 ID:zDjINlW+0.net] >>906 そのリポジトリがどういう構造になっているかわけわからん git show-branch してみろ 953 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 21:26:43.61 ID:646uiMLL0.net] >>909 すまぬ、確かに今見てればちょっとおかしい。 もう一度作るから30分ほどお待ちを。 954 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 21:51:56.84 ID:646uiMLL0.net] >>909 結果 $ git show-branch ! [develop] impl5 * [master] impl5 -- +* [develop] impl5 $ git branch develop * master 955 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 21:52:24.93 ID:646uiMLL0.net] >>909 $ git diff HEAD~1 diff --git a/test.txt b/test.txt index 3585d98..bbddc42 100644 --- a/test.txt +++ b/test.txt @@ -4,3 +4,4 @@ impl1 impl2 impl3 impl4 +impl5 $ git diff @{1} diff --git a/test.txt b/test.txt index e79c5e8..bbddc42 100644 --- a/test.txt +++ b/test.txt @@ -1 +1,7 @@ initial +impl0 +impl1 +impl2 +impl3 +impl4 +impl5 956 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 21:53:21.88 ID:646uiMLL0.net] >>909 再現コード #!/bin/bash -x # git init echo 'initial' > test.txt git add test.txt git commit -m 'initial' git branch develop for (( i=0 ; i<6 ; i++ )); do git branch feature$i git switch feature$i echo "impl"$i >> test.txt git add test.txt git commit -m "impl"$i git switch develop git merge feature$i git branch -d feature$i done git switch master git merge develop 957 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 22:01:15.70 ID:646uiMLL0.net] >>909 ちなreflog $ git reflog 1a804d9 (HEAD -> master, develop) HEAD@{0}: merge develop: Fast-forward b0325fc HEAD@{1}: checkout: moving from develop to master 1a804d9 (HEAD -> master, develop) HEAD@{2}: merge feature5: Fast-forward ba4e962 HEAD@{3}: checkout: moving from feature5 to develop 1a804d9 (HEAD -> master, develop) HEAD@{4}: commit: impl5 ba4e962 HEAD@{5}: checkout: moving from develop to feature5 ba4e962 HEAD@{6}: merge feature4: Fast-forward a32e11d HEAD@{7}: checkout: moving from feature4 to develop ba4e962 HEAD@{8}: commit: impl4 a32e11d HEAD@{9}: checkout: moving from develop to feature4 a32e11d HEAD@{10}: merge feature3: Fast-forward 8d9924f HEAD@{11}: checkout: moving from feature3 to develop a32e11d HEAD@{12}: commit: impl3 8d9924f HEAD@{13}: checkout: moving from develop to feature3 8d9924f HEAD@{14}: merge feature2: Fast-forward 0f78740 HEAD@{15}: checkout: moving from feature2 to develop 8d9924f HEAD@{16}: commit: impl2 0f78740 HEAD@{17}: checkout: moving from develop to feature2 0f78740 HEAD@{18}: merge feature1: Fast-forward 47792a3 HEAD@{19}: checkout: moving from feature1 to develop 0f78740 HEAD@{20}: commit: impl1 47792a3 HEAD@{21}: checkout: moving from develop to feature1 47792a3 HEAD@{22}: merge feature0: Fast-forward b0325fc HEAD@{23}: checkout: moving from feature0 to develop 47792a3 HEAD@{24}: commit: impl0 b0325fc HEAD@{25}: checkout: moving from master to feature0 b0325fc HEAD@{26}: commit (initial): initial 958 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 22:02:09.13 ID:646uiMLL0.net] >>909 ついでに一応、終了時のtest.txt $ cat test.txt initial impl0 impl1 impl2 impl3 impl4 impl5 959 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 22:05:21.84 ID:zDjINlW+0.net] >>911-915 これ全部FFマージやってるから結果的にdevelopブランチとmasterブランチが同じものになるぞ 960 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 22:09:56.21 ID:zDjINlW+0.net] mergeを全部merge --no-ffにするとマージした構造がわかるようになるし、最後にdevelopとmasterが別のものになる どっちのマージにするかは現場の運用しだい 961 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 22:10:47.10 ID:zDjINlW+0.net] git log --graph --branches --oneline とかするとわかりやすい 962 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 22:11:46.51 ID:646uiMLL0.net] >>916 ああ、それがrebaseしないと履歴が無くなるとかいう話か？ 実はそれはまだ確認中だが、とりあえず本件についてはこれでいいし、 俺的には多分こうなる。(基本的にmasterはdevelopの後を追うだけ) けしか� 963 名前：轤�か？ それはさておき、本件、HEAD~1 と @{1} が違うものだという経路情報は、 どこにあるのか分かれば教えてくれ。 [] [ここ壊れてます] 964 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 22:22:33.37 ID:zDjINlW+0.net] HEAD~1と@{1}は全然関係無いよ？ HEAD~1は今のHEADの一番目の親のhash 親が複数いるときにはHEAD^1とかHEAD^2とかで指定する @{1}はひとつ前の操作によってHEADになったhashだから、どういう操作したかで変わり、リポジトリの構造とは関係無い 965 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 22:30:34.81 ID:zDjINlW+0.net] >>914 で説明すると、 @{0}は最後のコミットで、FFマージした結果masterとdevelopがこのhash=1a804d9になった @{1}はgit commit -m 'initial'の結果できた最初のコミット(最後のマージ操作の前のmaster)で、最後にこれにdevelopをマージするためcheckoutしたらこれになってる 966 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 22:35:17.82 ID:646uiMLL0.net] >>920 > @{1}はひとつ前の操作によってHEADになったhashだから、どういう操作したかで変わり、リポジトリの構造とは関係無い だから、それは「そのbranchの」一つ前の操作なんだよ。 結果、diffは、masterブランチでは>>912で、HEAD~1 != @{1} だが、 developブランチでは、以下になって、 HEAD~1 == @{1}　なんだよ。 $ git diff HEAD~1 diff --git a/test.txt b/test.txt index 3585d98..bbddc42 100644 --- a/test.txt +++ b/test.txt @@ -4,3 +4,4 @@ impl1 impl2 impl3 impl4 +impl5 $ git diff @{1} diff --git a/test.txt b/test.txt index 3585d98..bbddc42 100644 --- a/test.txt +++ b/test.txt @@ -4,3 +4,4 @@ impl1 impl2 impl3 impl4 +impl5 だからmasterブランチをdevelopにmergeしかしない運用をした場合、 masterブランチは @{n} でn回前のリリースが検索出来、存在価値が出てくる、という見立てだが、間違ってるか？ (@はcommit履歴だと思ってるが、まさか操作履歴か？なら確かに意味無いし、先頭情報しか要らないし、reflogしかなくても納得だが) 967 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 22:40:04.85 ID:zDjINlW+0.net] 最終的にお前のリポジトリは git merge develop でこうなっているはずだ $ git log --graph --branches --oneline * 1a804d9 impl5 (HEAD -> master, develop) * xxxxxxx impl4 * xxxxxxx impl3 * xxxxxxx impl2 * xxxxxxx impl1 * xxxxxxx impl0 * b0325fc initial 最後のひとつ前の git switch master をやったときにはこうなっていたはず * 1a804d9 impl5 (develop) * xxxxxxx impl4 * xxxxxxx impl3 * xxxxxxx impl2 * xxxxxxx impl1 * xxxxxxx impl0 * b0325fc initial (HEAD -> master) だから HEAD@{0} = 1a804d9 で、HEAD@{1} = b0325fc 968 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 22:46:20.49 ID:646uiMLL0.net] >>921 @はやっぱcommit履歴だよな？ エントリポインタだけだと、commit履歴に出来ないんだよ。 今回はfast-forwardマージしてるから、 init<-0<-1<-2<-3<-4<-5 = master, develop で、単にエントリポイントだけなら master も develop も同じ 5 で区別がない。 当たり前だが両方とも HEAD~1 は4を指してる。 ただ、@{1}は、commit履歴だから、masterでは init を指し、developでは4を指す。 この、commit履歴情報はどこに記録されてるの？というのが俺の質問。 >>923 そこは理解出来てるはず。上記の通り。 問題はcommit履歴がどこにあるか。 969 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 22:50:12.27 ID:zDjINlW+0.net] >>922 masterブランチをdevelopブランチにマージする方法が git switch masterとgit merge developの連続実行だけではないし、 HEAD@{n}は適当なタイミングでGCされるから、 HEAD@{n}をそんな用途に使う奴はいない 970 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 22:52:10.49 ID:zDjINlW+0.net] >>924 commit履歴がどこにあるか説明するのに使いたいから、git log --graph --branches --oneline してくれ 971 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 22:54:11.54 ID:zDjINlW+0.net] @はcommit履歴じゃなくて、reflogの履歴 972 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 22:57:39.34 ID:646uiMLL0.net] >>926 $ git log --graph --branches --oneline * 1a804d9 (HEAD -> master, develop) impl5 * ba4e962 impl4 * a32e11d impl3 * 8d9924f impl2 * 0f78740 impl1 * 47792a3 impl0 * b0325fc initial 973 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 23:01:41.48 ID:zDjINlW+0.net] @{n}はカレントブランチのreflog履歴になるはず reflog履歴はブランチ毎に存在するので master@{n}とdevelop@{n}は違うハッシュになってるはず git reflog masterとgit reflog developで比べてみればわかる 974 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 23:04:26.02 ID:646uiMLL0.net] >>917,926 ちな --no-ff 版、 今出すと余計に混乱するかもだが。 $ git log --graph --branches --oneline * a5aaf72 (HEAD -> master, develop) Merge branch 'feature5' into develop |\ | * e03bcd0 impl5 |/ * 324df68 Merge branch 'feature4' into develop |\ | * c2634c4 impl4 |/ * 68ed20a Merge branch 'feature3' into develop |\ | * 5e12b99 impl3 |/ * 608e5d7 Merge branch 'feature2' into develop |\ | * 4660e46 impl2 |/ * 3924eae Merge branch 'feature1' into develop |\ | * 138d83f impl1 |/ * 7db4424 Merge branch 'feature0' into develop |\ | * 8877414 impl0 |/ * ec041f9 initial 975 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 23:08:22.79 ID:646uiMLL0.net] >>929 $ git reflog master 1a804d9 (HEAD -> master, develop) master@{0}: merge develop: Fast-forward b0325fc master@{1 976 名前：}: commit (initial): initial $ git reflog develop 1a804d9 (HEAD -> master, develop) develop@{0}: merge feature5: Fast-forward ba4e962 develop@{1}: merge feature4: Fast-forward a32e11d develop@{2}: merge feature3: Fast-forward 8d9924f develop@{3}: merge feature2: Fast-forward 0f78740 develop@{4}: merge feature1: Fast-forward 47792a3 develop@{5}: merge feature0: Fast-forward b0325fc develop@{6}: branch: Created from master ってことは、commit履歴はreflogにしか無いって事か？ ならbrahchを消すとreflogも消されてcommit履歴が消えるが、マジ？ これだとbranchの復活は本質的に無理なことになってしまう。 (他branchに断片的には残ってるんだけどさ） [] [ここ壊れてます] 977 名前：デフォルトの名無しさん [2022/11/05(土) 23:09:25.37 ID:zDjINlW+0.net] >>928 impl5のコミットオブジェクトの hash = 1a804d9 impl5のコミットオブジェクトの中には親のコミットオブジェクトimpl4の hash = ba4e962 が格納されている impl4のコミットオブジェクトの hash = ba4e962 impl4のコミットオブジェクトの中には親のコミットオブジェクトimpl3の hash = a32e11d が格納されている impl3のコミットオブジェクトの hash = a32e11d impl3のコミットオブジェクトの中には親のコミットオブジェクトimpl2の hash = 8d9924f が格納されている impl2のコミットオブジェクトの hash = 8d9924f impl2のコミットオブジェクトの中には親のコミットオブジェクトimpl1の hash = 0f78740 が格納されている impl1のコミットオブジェクトの hash = 0f78740 impl1のコミットオブジェクトの中には親のコミットオブジェクトimpl0の hash = 47792a3 が格納されている impl0のコミットオブジェクトの hash = 47792a3 impl0のコミットオブジェクトの中には親のコミットオブジェクトinitialの hash = b0325fc が格納されている initialのコミットオブジェクトの hash = b0325fc initialのコミットオブジェクトはルートなので親のコミットオブジェクトが存在しない つまり impl5のコミットオブジェクトの hash = 1a804d9 からたどっていけば、コミット履歴が全部わかる 親が複数存在する場合には複数の親のhashを格納する 978 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 23:11:25.45 ID:zDjINlW+0.net] >>930 ￥で表示されるとちょっと見にくいが、慣れれば見やすい 979 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 23:14:09.84 ID:zDjINlW+0.net] >>931 逆だ。コミットのつながりはコミットオブジェクトの中にしかない >>932 みたいにね それを説明してるのが >>902 980 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 23:16:52.31 ID:zDjINlW+0.net] >>930は最後のdevelopのマージが --no-ff になってないな 最後のも --no-ff にするともっと面白いぞ 981 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 23:18:09.46 ID:646uiMLL0.net] >>932 ごめん、それは分かってる。 それはグローバル履歴＝gitオブジェクトを辿った履歴、だろ。 問題は、masterのcommitには b0325fc と 1a804d9 しかない、という情報が、 今のところ master の reflogにしか見あたらないんだよ。 だから、各branchを消したら、それ以前の gitオブジェクト は全部辿れるが、commit履歴は消失してしまう。 今のmasterみたいに、fast-forwardマージで中間をすっ飛ばしてきた、 という情報が無くなってしまうんだよ。 だから、branchを消す前の状態に完全には戻せない、という話。 だから、常識的に考えればもうちょっとましな何処かに保持してるはずなんだけど、無いんだ。 982 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 23:21:56.96 ID:646uiMLL0.net] >>935 ほい $ git log --graph --branches --oneline * 2fb59f1 (HEAD -> master) Merge branch 'develop' |\ | * 25e1b95 (develop) Merge branch 'feature5' into develop | |\ | | * 4b27393 impl5 | |/ | * 9bfb8cc Merge branch 'feature4' into develop | |\ | | * c2a5b7d impl4 | |/ | * 02d2308 Merge branch 'feature3' into develop | |\ | | * f6d1cf7 impl3 | |/ | * 81e18bb Merge branch 'feature2' into develop | |\ | | * 01c3871 impl2 | |/ | * 5b57f48 Merge branch 'feature1' into develop | |\ | | * 0fe34d2 impl1 | |/ | * 6272da6 Merge branch 'feature0' into develop | |\ |/ / | * fe1b132 impl0 |/ * 832f464 initial 983 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 23:23:27.84 ID:zDjINlW+0.net] >>936 FFマージしたらその情報は消滅するな --no-ff で全部マージすれば複数親のハッシュをもってるコミットオブジェクトの1番目だけたどればいける ^1 だけみていくね git log にはそれをやるオプションがあるはず >>930をそのオプションで表示すればこんな風に表示されるはず $ git log --graph --branches --oneline --オプション忘れた探せ * a5aaf72 (HEAD -> master, develop) Merge branch 'feature5' into develop * 324df68 Merge branch 'feature4' into develop * 68ed20a Merge branch 'feature3' into develop * 608e5d7 Merge branch 'feature2' into develop * 3924eae Merge branch 'feature1' into develop * 7db4424 Merge branch 'feature0' into develop * ec041f9 initial 984 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 23:26:10.78 ID:zDjINlW+0.net] >>937 だとこう表示されるはず $ git log --graph --branches --oneline --オプション忘れた探せ * 2fb59f1 (HEAD -> master) Merge branch 'develop' * 832f464 initial 985 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 23:35:28.93 ID:646uiMLL0.net] >>938 $ git log --graph --branches --oneline --first-parent * a5aaf72 (HEAD -> master, develop) Merge branch 'feature5' into develop * 324df68 Merge branch 'feature4' into develop * 68ed20a Merge branch 'feature3' into develop * 608e5d7 Merge branch 'feature2' into develop * 3924eae Merge branch 'feature1' into develop * 7db4424 Merge branch 'feature0' into develop * ec041f9 initial >>939 $ git log --graph --branches --oneline --first-parent * 2fb59f1 (HEAD -> master) Merge branch 'develop' | * 25e1b95 (develop) Merge branch 'feature5' into develop | * 9bfb8cc Merge branch 'feature4' into develop | * 02d2308 Merge branch 'feature3' into develop | * 81e18bb Merge branch 'feature2' into develop | * 5b57f48 Merge branch 'feature1' into develop | * 6272da6 Merge branch 'feature0' into develop |/ * 832f464 initial 986 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 23:41:19.40 ID:zDjINlW+0.net] >>939がそう表示されるのは、--no-ff マージの手順が何か普通とちがうからかもしれん >>939みたいに表示させるマージの手順もあるはずだから工夫してみるんだな 987 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 23:41:56.11 ID:646uiMLL0.net] >>938 なるほど了解した。 データ側に混ぜ込んでて、保持したければ --no-ff で使えってことか。 そもそも同じハッシュなら同じgitオブジェクトにリンクするようになってるのだし、 (つまり見た目が膨らんでるだけで実際の容量は 988 名前：大して食わない） --no-ff がデフォのほうがよかった気がするが。 まあとにかく了解した。長々とありがとう。 [] [ここ壊れてます] 989 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 00:38:34.83 ID:UPUgwCSv0.net] FFがデフォじゃなと使いにくい気がするのだがｗ 990 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) mailto:sage [2022/11/06(日) 09:32:37.27 ID:OfQ8ymDc0.net] >>943 ffがデフォのメリットって何だ？特にないと思うが。見た目すっきり、か？ ただまあ、デフォだし、サル先生他も特に何も言ってないので、ffでの運用が多数派なのだろう。 --no-ffはcommitオブジェクトが別に作られるだけで、 スナップショットに比べたらゴミなので全体としては大して増えない。 commit履歴はgitオブジェクトツリー内に混ぜ込まれ、完全に保持される。 ffの場合は、commit履歴情報はreflogにしか無いので、branchを削除したら基本的に失われる。 そしてreflogもgc対象なので、Linusはcommit履歴は基本的に保持する必要がないとの立場なのだろう。 また、branchを削除しろといいつつffなのは、その人達もcommit履歴は要らない、と考えていることになる。 ただこれは奇妙な実装だ。 カーナビを考えれば分かるが、当たり前だが地図情報とルート情報は別なのだ。混ぜ込むのはあり得ない。 commit履歴が要らないってのは、経路(線)は不問で、目的地(点)に着いてるかどうかだけだ、と言っているわけ。 それはバージョン管理の達人()にとっては、違うんだろ。バージョン管理は「線」であると！ ただ、Linusも「点」の立場だね。まあプログラマ的にはこれで正しいんだよ。 コンピューターは今現在のソースコードしか見てなくて、どの経路を辿ったかなんて関係ない。 だからどういう紆余曲折(「線」)があったかではなく、結局は前回の「点」と今回の「点」のdiffだけが価値を持つ。 そしてLinusの個人的ツールであるGitも、この流れなわけだ。 とはいえ俺はルート情報はまた別に重要だと思うから、保持したい。 混ぜ込まれてる場合は後からbranchを追加することが絶対に出来ない。 まあ開発ツールとしては別経路から同じ点に到達しました！なんてのは現実的にあり得ないから、 偽造を防ぐ為にもこれでいいのかもしれんが、一般的に考えればこの実装は奇妙だ。 ちなみに一般文書、例えばEULA(EndUserLicenseAgreement)とかの隙を潰していくタイプの法務文書等は、 別経路だが最終到達時点は同じ、ということが普通にあり得るはず。 だからやっぱりGitはソースコード向けにしか出来てない、ということは認識しておくべきだろう。 991 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) mailto:sage [2022/11/06(日) 09:32:57.06 ID:OfQ8ymDc0.net] あと、Gitのドキュメントは全般的によく出来ているが、branchは「線だ！」と言ってるのは不適切だ。 Gitのドキュメントは密結合状態、つまりGitをよく知ってる人向けに書かれているので、 同様に内部実装を見せる形で書くのが正しく、 つまり、「branchは『線』のように見せてますが、実は『点』です！」と言わないと誤解される。俺がそうだが。 これは解像度が統一されてないから起こった問題だ。 一般のマニュアルは疎結合状態、 つまりそのツールについて内部実装なんて全く知らないし知る由もない人向けに書かれるから、 『見た目』線であれば「線」とずっと言い張り、内部実装を曝露してはいけない。 この場合、あくまでユーザーから見たら常に「線」であり、内部がどうであれ「線」としてしか見えないから誤解を生む余地はない。 Gitの場合は内部も見せた上でドキュメントとして外面仕様も説明することになってて、 それが外面仕様なのか内部実装なのか、 またbranchのように外面仕様と内部実装が� 992 名前：ﾙなってて隠蔽しきれてない場合とか、(--no-ffの有無で観測可能) それは正しく説明しなければならない。 密結合なら、上記の通り、「『線』として見せてますが実は『点』です！」と書くべきだ。 とはいえ全般的にドキュメントはしっかり書かれている。これ自体は素晴らしい。 ただ、そもそも仕様がグダグダ過ぎるし、 或いはユーザーにどこまで見せ、どこからは見せないのか、仕様を管理する感覚がまるでない。 おそらく上層部の連中に仕様管理の経験者がおらず、グダグダになってしまってる。 とはいえ、再度言うが、ドキュメントはよく書いてる方だよ。 [] [ここ壊れてます] 993 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) mailto:sage [2022/11/06(日) 09:33:22.07 ID:OfQ8ymDc0.net] ただこれだと、branchを「線」として扱おうとしたら動作が不安定になるわけで、 おそらくfilter-branchが不安定なのはこの辺に起因してる。 そしてドキュメントの何処か(多分showかlog)に、 「これには実はpitfallがあって、マージに遭遇した場合に分岐するから云々」とかいう (当時の俺にとって)謎の記述が挿入されてたのも納得がいく。 commit履歴を保持してないから確定的動作が出来ないんだよ。 これははっきり言って仕様の欠陥で、commit履歴も完全に保持する仕様だったら自然と回避出来てた。 現仕様では、filter-branchの実装をいくら頑張ったところでどうにもならない。 代わりのfilter-repoも、動作は同様に糞だろうよ。安定して使えるものではないはず。 ここら辺はちょっと惜しいね。Gitが素晴らしいのは、「伽藍とバザール」での > 9. 賢いデータ構造と間抜けなコードのほうが、その逆よりずっとまし。 を体現してるからであって、つまり根っこがしっかりしてるから上部は雑草でも問題なかったんだが、 この点は根っこが駄目だから、上部(filter-branch)が機能しない。 ここら辺はちゃんと仕様の大切さを理解してる奴が仕切らないと駄目なのだが、 おそらくGitの連中も、仕様を捏ねてる連中は手を動かしてないと見なし、嫌ってるのだろう。 だから仕様を捏ねることすらしてない。 ただ、それは結局は遠回りでしかない。 今のGitだと、filter-branchも、filter-repoも、その次に出てくる何かも、まともに動作するはずがない。 駄目な仕様だと実装をいくら頑張ってもどうにもならない、と知ってる奴が、ちゃんと仕切らないといけないんだけどね。 ただこれは、それを知らない奴にとってはムカつく奴でしかなく、そいつらを排除した結果、Gitは暴走中、というわけだ。 Linusがcommit履歴も大切に考える奴だったら違ってたが、惜しいね。 994 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 10:57:26.83 ID:FBkt/oHG0.net] 長々と無駄な長文と大量投稿でスレを穢すんじゃねー。 単に既存のバージョン管理ツールと、git の考え方の違いが理解できてないだけじゃねーか。 ・git はパッチ管理ツール、作業履歴管理ツールじゃない。 ・ソフトウェアはパッチとパッチを当てる順番で構成されている。 1000回唱えろ。この思想が気に要らなければそもそも git 使うな。 995 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 10:59:15.02 ID:OfQ8ymDc0.net] >>943 と思ったが、ffじゃないとhashが違うからウザいな。別物扱いだから、一々確認いるし。 オブジェクトツリーはffの方がいい。 ただこれだとcommit履歴が無く、俺的にはまずいので、別に保存したい。 ソースと混ざるとウザイので、可能なら分離したい。 ドキュメントによるとマルチルートも出来るらしいが、これはどうやってやるんだ？ > Each project must have at least one root. A project can also have multiple roots, though that isn’t common (or necessarily a good idea). 996 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 1 ] [ここ壊れてます] 997 名前：1:04:28.51 ID:OfQ8ymDc0.net mailto: >>947 > ・git はパッチ管理ツール、作業履歴管理ツールじゃない。 ああ非常に納得出来る。Gitはmerge特化型だ。 確かにそれを日々の業務(非merge)に使おう、というのがフィットしないんだろうよ。 しかし世の中の一般人のGitの使い方は後者だろ。 [] [ここ壊れてます] 998 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 11:33:11.11 ID:sj15aRfA0.net] ということにしたいのですね。 999 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 11:46:16.67 ID:FBkt/oHG0.net] >>949 お前の狭い世間なんて知るか お前は話題の電動ドリル買ってきて釘打つのに不便ガンガンってやりながら文句言ってるのと同じレベル そもそもマニュアルもちゃんと読めてないだろ。root と route を間違える英語レベル 背伸びして git 学ぶ前に高校に進学して英語学んだ方が近道だぞ 1000 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 11:51:22.62 ID:OfQ8ymDc0.net] >>950 いや事実だよ。 Linusは確かにmergeしかしないんだろうけど。 だけどその、mergeするパッチを書く奴は、それを一発で書けたわけがないんだ。 何日もかけて、何回も直して、そこに到達してる。 この過程のサポートがGitにはない。 別branchで作業してもmerge時にhash値が組み込まれるから、 確かに俺がやろうとしてる「日々の進捗」をcommitされると除去出来ずウザイんだろうさ。 しかしパッチのコードは必ずGit-repoをクローンしてから出発するのだから、 Gitにこのサポートが無く、パッチを当てる人はいきなり完成したパッチを書け！勿論でバッグ済みだぞ！みたいな構造なのがおかしい。 すくなくとも、捨てbranch機能があって、そこで日々の作業を終わらせた結果、 mergeするときには本ブランチでその結果がいきなり生えたように見せる機能 (捨てbranchとmergeしても中身の結果だけもらって親にはしない） みたいな機能が必要なんだよ。 ただまあ、これは今でも手動だと出来た気はするが。 だからまあ、確かにパッチ管理ツールであって、 ソフトウェア開発時のバージョン管理ツールではないんだろうさ。 だけど、今、全世界のGitで、mergeコミットと通常のcommit、どっちが多いか考えれば、自明だろ。 一つのパッチを作るまでにも何回もcommitが必要なのだから。 1001 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 12:07:06.70 ID:FBkt/oHG0.net] >>952 アホか。共同開発が全く理解できてねーじゃねーか。 お前の試行錯誤の記録を push しようとしてんじゃねーよ。 手元で試行錯誤して実装できたら、それを元に綺麗なパッチに書き直す作業するんだよ。 そして完成した綺麗なパッチ群のみを共有リポジトリに公開するんだよ。 1002 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 12:19:51.48 ID:OfQ8ymDc0.net] >>948 一応見つけた。 git worktree らしい。 複数のbranchを同時に開く機能で、DBで言うATTACHっぽい。 1003 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 12:20:57.36 ID:JyiC8cnE0.net] 試行錯誤はすべて記録に残すべき →じゃあテキストエディタで保存するたびに記録するべきっていうのか？ こういう話なので無視すんなよ？ｗ 1004 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 12:21:44.03 ID:JyiC8cnE0.net] バージョン管理はソースコードの変更履歴を残すのであって 作業履歴を残すものじゃないっていうのが分かってなさすぎ 1005 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 12:30:26.14 ID:OfQ8ymDc0.net] >>953 それはいいんだけどさ、その肝心のパッチを書く人へのサポートがまるでないだろ。 出発点がgit clone で、その上で作業して、終われば pull request する前提なのにさ。 そしてOSSではなく一般企業等で使ってる奴は、 当たり前だが日々の作業のバックアップや巻き戻し出来るシステムが必要で、そう使ってる。 だから、Gitが難しすぎるというのは、目的外使用だから意味が分かりにくい、というのはあるね。 Indexもマージの時には� 1006 名前：�った方が便利なんだろうしさ。(ただのcommitには邪魔でしかない） しかし確かに、Linusに言わせれば、全く問題ないんだろうさ。彼はmergeしかしないしね。 そして他のVCSよりまし、という理由でGitを使う奴は、混乱するんだろうさ。VCSと聞いてきたのだからね。 確かにパッチ管理システムだよGitは。ソースコード生成時のサポートシステムではない。 [] [ここ壊れてます] 1007 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 12:32:16.81 ID:OfQ8ymDc0.net] >>955 > こういう話なので無視すんなよ？ｗ 無視する/しない以前に、何が言いたいのか分からないから反応しようがないんだよ。 1008 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 12:42:58.45 ID:sj15aRfA0.net] >>957 > それはいいんだけどさ、その肝心のパッチを書く人へのサポートがまるでないだろ。 rebase あるよ。 元のローカルブランチを消さないでおけば記録もぜんぶ残るし。よかったね。 1009 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 12:43:13.14 ID:FBkt/oHG0.net] >>957 git ほどパッチを書くのに向いてるツールは他にないぞ。 index 無しでどうやってパッチの分割とかするんだよ？ 1010 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 12:53:16.71 ID:OfQ8ymDc0.net] >>960 最初から一つずつ書けば分割の必要ないし、 Index無くてもdiffの出力を絞ってpatchに食わせれば普通に分割出来るだろ。 1011 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 13:02:38.08 ID:JyiC8cnE0.net] >>958 書いてあるとおりじゃん。 試行錯誤の履歴を全部取れというなら、テキストエディタで保存するごとに gitでコミットしなければならないはずだ お前の主張はそういうことなんだから、それをちゃんとやれってこと 1012 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 13:04:02.78 ID:JyiC8cnE0.net] >>961 コミットがメチャクチャなのに、どうやってdiffとってパッチできると思ってるの？ そのdiffには関係がない修正が大量に入ってるだろ 1013 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 13:37:22.28 ID:FBkt/oHG0.net] >>961 なんも分かってないことを露呈しているな。 A,B,C,D,Eとコミットした後に Cはc1,c2,c3に分割すべきで、BとEは一つにすべきで、Aは不要だったと気づいたらどうすんの？ こういうのがお手軽にできて綺麗なパッチ群に整理できるのがパッチ管理ツールである git の利点なんだ。 そういうのやったことないだろ？ 1014 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 13:39:49.06 ID:az1H5JFk0.net] >>954 脊髄反射で理解したつもりになって書いてるだろ正解率が著しく低い git worktreeは一つのリポジトリに追加のワークツリーを用意して、異なるブランチをそれぞれ別のワークツリーにcheckoutできるようにする機能 DBのATTACHとは全然違う マルチルートは普通に作ったリポジトリをfetchやpushで合成してmerge --allow-unrelated-historiesすればできる でもこれはかなり特殊な用途に使うもので普段使いするようなものではない 1015 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) mailto:sage [2022/11/06(日) 13:46:46.96 ID:OfQ8ymDc0.net] >>965 実は今し方ドキュメント読んで、これは違うと書こうとしたところだった。 wor,ktreeはstashの代わりで、同時作業用ではないね。 > マルチルートは普通に作ったリポジトリをfetchやpushで合成して ああこれは俺の要求とは違うね。 まあ、もう地味に.git/.xxx/に転がそうと思案中。 1016 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 13:57:15.91 ID:OfQ8ymDc0.net] >>963,964 お前らunixコマンドの使い方知らないだろ。 patch/merge/diff3はgit以前からあるコマンドで、多分初期Gitはそのまま使ってたと思うが。 具体的な使い方は以下。 今、元 fileA に対して、変更後 fileC になってるが、実は中間の fileB が欲しかったとする。このとき、 cp fileA fileB diff fileA fileC | less -N; // ここで該当行を確認する。例えば10-20行目なら、 diff fileA fileC | sed -n '10,20 p' | patch fileB これでfileBが得られるんだよ。これ以上色々複雑な時用に diff3 とか merge もある。 だからパッチの分割はすぐ出来るんだよ。 1017 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 14:05:27.55 ID:az1H5JFk0.net] >>967 そういう作業を必要で 1018 名前：無くすためにgitが生まれた patchの提出をgitの分散リポジトリ上で可能とするためにね 963とか964が行ってるpatchというのは、いわゆるpatchファイルのことではなく、ブランチ上に存在する差分の事 そのpatchを整理するのに index や rebase がある [] [ここ壊れてます] 1019 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 14:19:49.14 ID:FBkt/oHG0.net] もしかして、もしかすると、git では「パッチ＝コミット」っていうことすら理解できてないのだろうか。 まさかそんな人はいないよね。単に言動が変な人なだけだよね。 1020 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 14:25:32.34 ID:OfQ8ymDc0.net] >>968 知ってるよ。 ただまあ、確かにパッチ管理ツールだ。 プログラマはこれをソースコード管理ツールとして使おうとするから問題なのだろう。 バックアップが取れて、履歴が戻れれば何でもいいんだが、mergeも出来るから便利だからね。 なお俺は > ブランチ上に存在する差分の事 も所詮はdiffだ、という立場だよ。だから元のunixコマンドで何とでもなるし、 それをシェルスクリプトで集大成したのが初期Gitだろ。 1021 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 14:31:58.60 ID:FBkt/oHG0.net] >>970 ちがうぞ。最初からパッチ管理ツールとして設計されるぞ。 そしてパッチ管理ツールなんだから、パッチの出力機能さえあれば良いんだぞ。 それ以外の差分が欲しかったら別の外部ツール使えば良いんだぞ。それこそ基本だろ 1022 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 14:33:28.64 ID:OfQ8ymDc0.net] >>969 各commmit「点」でdiff取ったときに落ちる情報って何？ ああcommitメッセージか？そんなのは知らんし要らんよ、って立場。 つか、commitメッセージガーなんて言い訳にならないから、 どのみちソースコードを確認するしかないんだよ。 commitメッセージはその手がかりとラベルに過ぎない。これが俺、というか多分普通のプログラマの立場。 お前らはcommitメッセージが間違ってたら、そいつに責任を負わせられるんだろうさ。 ソースコード読めないからね。 ソースコード読める奴ならこんな言い訳効かないんだよ、何でお前が上にいるんだ！監督する為だろ！になる。 さすがに素通しはヤバい。 そしてどう見てもヤバいパッチを素通ししてるから、なんじゃあこりゃあ？ってなってる。 1023 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 14:36:33.55 ID:OfQ8ymDc0.net] >>971 ああそれが diff のデフォルト出力をさせない理由だな。 651から一周回ったが、なるほど色々状況は理解出来たよ。賛同はしないが。 1024 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 14:45:12.77 ID:FBkt/oHG0.net] >>972 だからお前の考えてるような作業履歴管理ツールじゃないんだから、あきらめて他所へ行け。 gitはパッチ管理ツール。そしてパッチは何時、誰が、何のために作成したかが重要情報なんだよ。それを管理してるんだよ。 ソースコードの保管するツールじゃねーぞ。 1025 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 14:49:22.34 ID:OfQ8ymDc0.net] >>974 そこは違うんだな。 みんな結局自分でやるのも作るのも面倒だから、既に動いてるツールを使ってるだけだよ。 Gitの機能のサブセットで十分にカバー出来るのなら、Git使えばいいだけ。 1026 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 14:56:19.71 ID:OfQ8ymDc0.net] >>974 だからな、前言ったように、ブッ込んでおけば後で取り出せるバケツでしかないんだよ。 そのバケツにゴテゴテ付いてるから難しそうだが、要らない機能は使わなければいいだけ。 ただ、履歴保持の範囲を知らずに使って、実は記録されていませんでは困るから、使う前に調べてる。 1027 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 15:45:34.08 ID:o7v4FvnP0.net] https://www.praha-inc.com/lab/posts/commit-message そもそもコミットメッセージは何のためにあるのでしょうか？ コミットログのうちコードの変更履歴には「コードをどのように変更したか」という情報が含まれていますが、「コードを何故変更したのか」という情報はコミットメッセージを読まないと分かりません。機能追加、バグ修正、パフォーマンスのためなど、変更した理由は様々なものが考えられます。 もちろんコードを変更した本人に聞けば変更した意図はわかると思いますが、変更した本人にいつ� 1028 名前：ﾅも聞ける状況であるとは限りません。 「何故コードを変更したのか」という情報が欲しい時のためにコミットメッセージが存在します。 加えて、コミットメッセージは基本的に他人が読むものです。 他人というと同僚やコントリビューターなどが挙げられると思いますが、この「他人」には未来の自分も含んでいます。自分が書いたコミットメッセージを数ヶ月先の自分が読む場合、過去の自分のコミットメッセージを未来の自分が読むことになります。 つまり、コミットメッセージは自分以外の人のために存在するのです。 [] [ここ壊れてます] 1029 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 15:52:02.65 ID:az1H5JFk0.net] まあこいつは分散バージョン管理の難しさを理解できていない 一人でしかプログラム組んだことがないのだろう gitのややこしいと感じる仕様のほとんどは分散リポジトリ管理に起因していて、分散リポジトリ管理の問題をできるだけ明示的にシンプルに解決しようという意図で設計されている 1030 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 15:55:03.47 ID:JyiC8cnE0.net] ほんとなぁ、POSIX原理主義だからユニケージだかUSP研究所だかしらんが 例のあいつも、バージョン管理のツールを、バックアップツールとしてしか考えてねぇ だからとりあえずファイルを入れておけば差分はdiffで見れるだろとか 訳のわからんことを言い出す ある時点とある時点の差を見たいんじゃねーんだよ ある修正にどのような差分があるかを記録＝コミットしたいわけで その記録なしに差分だけみれても役に立たないっつーの そこが根本的に違うというか、バージョン管理の役目がわかってない 1031 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 16:10:07.15 ID:az1H5JFk0.net] 「ブッ込んでおけば後で取り出せるバケツ」など言っているが、 必要とされていたのは内容を同期できる複数のバケツで、 なおかつバケツ同士が常にオンラインで通信しているわけではない そういう問題に取り組んだ結果だ 1032 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 16:12:28.94 ID:az1H5JFk0.net] そういう魔法のバケツを生み出すために、ただのバケツならできることがgitでは制限されていたりもする ユーザから見て不自由のない完全な魔法のバケツを生み出そうとしたプロジェクトは複雑すぎてことごとく失敗してきた 1033 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 16:14:37.71 ID:JyiC8cnE0.net] バケツの中に入っている袋詰めの塩や砂糖を、一つづつ取り出したいのであって バケツの中に全部入ってるから、遠心分離機でも使って 取り出せばいいだろうじゃないんだよなｗ 1034 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 16:36:01.68 ID:az1H5JFk0.net] 前スレは消費に1年半かかってるのに、このスレは半年ぐらいで終わりだな 次スレ立ててみるけど失敗したらゴメン 1035 名前：デフォルトの名無しさん [2022/11/06(日) 16:41:37.94 ID:az1H5JFk0.net] 次スレ Git 19 mevius.5ch.net/test/read.cgi/tech/1667720427/ 1036 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 19:18:45.16 ID:OfQ8ymDc0.net] 相変わらずお前ら盛大に勘違いしてるが、とりあえず、 × Gitはパッチ管理ツールである ○ Gitはパッチ適用ツールである ○ Gitはパッチ記録ツールである としよう。管理は出来てない。何を管理すべきか分かってないから。 commitメッセージなんてただのラベルに過ぎない。 1037 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 19:19:20.86 ID:OfQ8ymDc0.net] 例えば今回俺が送った再現コード、あれはどこに配置されるのだ？ >>977の通り、「何故この変更を行ったのか」の完全情報がそこにある。 まさか捨てたりしないよな？ バグパッチに於いて、重要な物から順に、 1. そのバグを修正するコード 2. そのバグを再現するコード ： 10000, commitメッセージ だ。どんなに丁寧にcommitメッセージを書いたところで、「それ、あなたの感想ですよね？」でしかない。 肝心なところを書き間違ってるかもしれないし、信用も出来ない。 この点、再現コードは情報が完全で、全ての情報を過不足無く含んでいて、曖昧さもない。 だからcommitメッセージの情報価値なんて再現コードと比べたらゴミ以下で、 再現コードに対してのリンクで十分なんだよ。つまり、 ○年○月○日に○○から送られてきた○○のバグ(メモリリーク 1038 名前：)を修正する。 詳細はXXXX で、XXXXのところ、Git流ならSHA1ハッシュで、 その中に再現コードと詳細、今回なら全員のメールの全文を入れておくのがバグ管理だよ。 これで、「何故この変更を行ったのか」の完全情報が保たれる。 そして、再現コードは今後ずっとregressionテストに使う資産にする。 そうすれば、少なくとも過去と同じバグはリリース前に見つかる。 [] [ここ壊れてます] 1039 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 19:20:02.27 ID:OfQ8ymDc0.net] こうなってないだろ。一回パッチ当てて動きました！満足です！じゃないんだよ。 繰り返すが、commitメッセジーをいくら丁寧に書いても意味無い。 再現コードに比べたら本当にゴミ以下。 逆に、再現コードに辿り着けるのなら、後はラベルが正しく付いてれば十分なんだ。 それ以上の情報は、commitメッセージのテキストではなく、 再現コードとバグ報告＝完全情報を見た方がいいから。 で、GitHubはまあこれに近いよ。 そもそもバグ報告自体Webだし、少なくともIssueからバグの完全情報に当たれる。 Gitはどうなの？ 今回の俺と同様の、過去のバグ報告の再現コードを生かせてるのか？ ならそういうディレクトリがあって、 bug_patches/XXXXXなハッシュが名前になってるディレクトリに再現コードその他がブチ込まれてて、 出荷前(というのもおかしいが)には全部一通り通せ、となってるはずだけど、 どう見てもそうなってないでしょ。 パッチ当てたから満足です、で終わってる。 こんなのでバグが収束するはずがない。 同じ連中が書いてるのだから、放置したら同レベルのバグを繰り返す。 だから本来は何故こんなバグが発生したのか？からコード構造を見直して、 そもそもそうならないようにするのだけど、そういう学びもないし、(だから基本すら出来てない) regressionテストのネタにもしないのだから、今後ともバグだらけだよ。 ああ、Gitの達人揃いだから、「記録」は出来てるのだろうよ。だけどそれは「管理」ではない。 ただ、これがバザール流だ！と来るなら、はーそうですかー(棒)だよ。 目も手も数が違うし、俺には何が最適か分からんし。 1040 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 19:20:37.38 ID:OfQ8ymDc0.net] ちなみにchromeの連中は気持ち悪いほどregressionテストしてるぞ。 本来は、ああするべきなんだろうよ。 regressionテスト自体はタダ(スクリプトで自動実行)だからね。 バグ「管理」というのなら、原因を究明して、少なくとも同じバグが出ないようにしないといけない。 それはcommitメッセージをいくら丁寧に詳細に書いても、達成出来るものではない。 分かりやすく言うとな、「体調管理」と言われれば、少なくとも同じ原因で風邪を引かないようにするだろ。 なら、「バグ管理」なら、最低限レビューしてregressionテストしないと駄目だよ。 それはcommitメッセージ云々では出来ない。だからパッチ「適用」「記録」ツール。 1041 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 19:24:47.08 ID:VM2X6i580.net] >>985 > commitメッセージなんてただのラベルに過ぎない。 その言葉からお前がわかってないのが明らかなんだけど？ 1042 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 19:26:23.98 ID:VM2X6i580.net] >>988 うん。だからそのchromeはここまで徹底してコミットを管理してる それを見習え https://github.com/chromium/chromium/commits/main 1043 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 19:27:42.33 ID:VM2X6i580.net] regressionする際にもコミットを管理するのは重要で コミット単位で戻してテストする 動かないコードをコミットすることはない お前みたいにテキストエディタで修正するたびにコミットとかしない 1044 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 19:28:57.43 ID:VM2X6i580.net] なんでchromeのコミットメッセージが こんなに詳しく書かれているのか、その理由を考えたら？ 1045 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 19:32:31.47 ID:VM2X6i580.net] バージョン管理はソースコードの変更履歴を管理するものなので そこにバグ管理という別の概念を持ち出すのも頭悪い バグ管理は別のツールでやれ 1046 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 19:55:47.23 ID:sj15aRfA0.net] >>986 > 例えば今回俺が送った再現コード、あれはどこに配置されるのだ？ 修正コミットのログから URL で辿れるようになるかな。 https://public-inbox.org/git/20221102220142.574890-2-szeder.dev@gmail.com/ 1047 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 20:08:52.18 ID:OfQ8ymDc0.net] >>994 それは鯖に置いてるだけだろ。まあそれはそれで十分で、（この意味では最初のMLでも十分) 問題は、 1. .git上、つまりソースコード改変ツリーから簡単に辿れるよう、 commitメッセージにそのリンクは落とされている(落とされる予定）なのか？ そうじゃないと>>977が達成出来ないだろ。 2. そしてregressionテストパターンとして登録され、今後ずっと実行されるのか？ 3. そもそも根本の原因はソースコードの程度が酷いことであり、レビューしろよマジで だよ。 レイヤーの考え方がない奴等ばかりなので通じないかもしれないが、 gitは適用/記録という下層レイヤーであって、バグ/パッチ「管理」は上位レイヤーの戦略だから、 gitで「管理」出来ると思ってるのが間違いなんだよ。記録は出来るが、管理は出来ない。 gitで出来るのは上の1だけだね。 だからcommitメッセージは勿論丁寧に書くべきなんだけど、丁寧に書けばいいわけでもないんだ。 それでバグやパッチが減るわけでもないから。 目的と手段の混同はどの界隈でもあるけど、ここの連中も大概だよ。 [] [ここ壊れてます] 1049 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 20:11:50.13 ID:OfQ8ymDc0.net] >>994 と思ったがすまん、見落とした。 > 修正コミットのログ つまりこれ、コミットメッセージそのものなのか？ ちょっと確認したいんだが、どこ見ればいいんだ？GitのGitHubから？ 1050 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 20:22:10.42 ID:sj15aRfA0.net] >>996 そう。コミットメッセージを含めてML上でレビュー中。まだ本体リポジトリには入ってない。 挙がってるレビューコメントを受けてそのうち第２弾が投稿されて取り込まれるんじゃないかな。 君もソースコードの質が気になるなら修正を送ってくれていいんだよ。さぁさぁ。 1051 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 20:38:50.28 ID:OfQ8ymDc0.net] >>997 つまりあれがそのままに近い状態で入るのか？ まあそれは見守るとして、本来はちゃんとラベルを付け替えないとまずい。 俺が送った段階では高い確率で「free忘れによるメモリリーク」と推定出来たが、 断定は出来なかったので、単に「メモリ食いすぎ」としてる。 だから、メモリリークだと「断定」出来た人が概略を書き直さないといけない。 が、まあ、これは多分為されるだろう。見守るよ。 > 君もソースコードの質が気になるなら修正を送ってくれていいんだよ。さぁさぁ。 これは本質的に無理だ。多分俺、というか、いわゆるCコードを拒絶すると思うよ。 間違いなく、連中は自己の能力に自信持ってて、傲慢で、言うこと聞かない連中だ。 世の中のCコードなんて、基本通りやってる物でほぼ全部だから、見たこと無いわけが無い。 それが何故そうなってるか理解出来ない、 つまり、王道を王道と理解出来ない奴等だからデタラメやってるわけで、 言うこと聞く連中ならそうはならない。 通常だと、やらせるだけやらせて、でもどうにももうダメポなときに、 そもそもお前のコードがおかしい、ここをこう直せ、なら簡単にメモリリークは抑えられる、とすると効くのだろうけど、 問題はバザールで、無限にモグラ叩き出来てしまって、実際にそれでやろうとしてることだよ。 マジかー、って、ちょっと驚きだが、まあ観戦だ。 ああちなみに、俺以外の誰でも、まともなC書ける奴なら、ちょっと引くコードだよ。 だからそこら辺の奴等に書かせても、もっとましなコードになるよ。そして俺もその程度だし。 というか単発のコードでそんなに技量の差なんて出ないし。 1052 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 20:40:54.42 ID:VM2X6i580.net] >>998 お前がちゃんとやれって言われるだけだよ お前雑なんだよ。無能なのに張り切るな。空回りしてるぞｗ 1053 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 20:46:49.73 ID:wlljBD17M.net] 質問いいすか？ 1054 名前：1001 [Over 1000 Thread.net] このスレッドは１０００を超えました。 新しいスレッドを立ててください。 life time: 197日 17時間 21分 4秒 1055 名前：過去ログ ★ [[過去ログ]] ■ このスレッドは過去ログ倉庫に格納されています

---

---

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

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