Git 18

[過去ﾛｸﾞ] Git 18 (1002ﾚｽ)
上下前次 1-新

このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索歴削→次ｽﾚ栞削→次ｽﾚ過去ﾛｸﾞﾒﾆｭｰ

706(1): (ﾜｯﾁｮｲ d9e4-Xmag) 2022/10/31(月)20:46 ID:GzQExg5g0(3/10) AAS
>>693
gitのバージョン管理されているファイルツリーはdiffコマンドがそのまま解釈できるような形式でファイルシステム上に存在しないからファイル単位で変換して外部関数呼び出すとか馬鹿だな
さらにgit内部で保持されるファイルの差分情報をdiffの出力みたいな字句解析が必要なバイト配列で取り扱うのも馬鹿げてる
このファイル差分抽出は間違いなくgitの核心的機能これが無ければVCSとして機能しない

707: (ﾜｯﾁｮｲ 6914-Tk+f) 2022/10/31(月)20:49 ID:oV1LtMOH0(19/19) AAS
>>705
POSIX原理主義者はPOSIXを理解してないよ。

708: (ﾜｯﾁｮｲ d9e4-Xmag) 2022/10/31(月)20:55 ID:GzQExg5g0(4/10) AAS
>>698
-uをサポートする前は、patch作るなら-cのコンテクスト形式だろ
-cなら-uとハンクの精度は変わらん

709(1): (ﾜｯﾁｮｲ 497b-vCJ4) 2022/10/31(月)21:08 ID:J+3pjzxx0(16/22) AAS
>>706
そこら辺の機能はGit以前から完全に機能してるんだよ。
> diffが作られてしばらくは、ソフトウェアコードや技術文書のマークアップのソース部分の変更箇所を比較する、
> プログラムのデバッグ出力の検証、ファイルシステム中のファイル一覧の比較といった使い方が一般的であった。
> ed用の出力により、ファイルへの一連の変更をひとまとめにしてファイル容量を節約するというアイデアが出てきた。
> Source Code Control System（SCCS）はそのようなアイデアを実装したものとして1970年代後半に実装がなされた。
> 外部ﾘﾝｸ:ja.wikipedia.org
だからそれはGitのアイデアでも全然無く、Git以前からdiffとedを組み合わせれば誰でも出来る物だった。
勿論diffの出力がキモだから出来るだけ--minimumなのは目指すとしても、
それはdiffを改善すべき話で、Git本体が対応する話ではない。

てかこの辺のソフトウェア階層の話が通じないところを見ると、割と階層無しの文化＝本当にCしか知らない感じだな。
例えばJSとかでは、扱うデータの先がDBなのか、ローカルファイルなのか、メモリ上のStringなのかを
上位のコードは区別しないで済むようにコーディングすることが普通で、
と言うか実際はそうしか出来なくて、強制的にそうさせられるわけだが、
形式的には、ネットワークでもローカルファイルでもメモリ上のStringでも、
プログラミングモデル側からは全部読み書き出来る状態になってから制御が渡される。
(メモリ上に展開し終えてから渡されるイメージ、なおこれをRubyでは上手いこと遅延読み出しにしてたりするが)
CでI/Oを分離するにしても普通はそうするし、実際、Gitでもそうなってる。
でないと git log -L で全展開の倍ほどメモリ食うとかあり得ないし。

最終段のI/Oは普通はそうやって上位のコードと分離するもので、Gitもcat-fileでそうなってる。
ただ、それを交換出来ないので、テキストやDBに保存したい奴に対応出来てないだけ。
これはGitの構造の問題だよ。
それでsshを別に実装しますとか、かなり馬鹿げた方針だ。
少なくともJS知ってればそうはならない。

710: (ﾜｯﾁｮｲ 497b-vCJ4) 2022/10/31(月)21:09 ID:J+3pjzxx0(17/22) AAS
Webの連中は馬鹿なのも事実だけど、馬鹿でも上手く行くように色々上手く出来てるのも事実なんだよ。
Ｃの連中は一度Webをやってみると凄く勉強になると思うよ。俺もそうだったし。
ただしWebはかなり糞なのも事実だが。

711(1): (ﾜｯﾁｮｲ d9e4-Xmag) 2022/10/31(月)21:15 ID:GzQExg5g0(5/10) AAS
>>709
マージやリベースでやってる差分抽出は最終段のI/Oじゃないし
C言語でシンプルに実装されてるgitをMSが作る馬鹿みたいに重いツールにしないでくれよ

712(1): (ﾜｯﾁｮｲ d9e4-Xmag) 2022/10/31(月)21:34 ID:GzQExg5g0(6/10) AAS
BitKeeperを元にGitを実装したリーナスはBitKeeper以前のVCSを糞みたいに言ってるんだよね
外部ﾘﾝｸ[html]:ezoeryou.github.io
edとdiffを使ったようなVCSは眼中になかった

713(1): (ﾜｯﾁｮｲ 497b-vCJ4) 2022/10/31(月)21:39 ID:J+3pjzxx0(18/22) AAS
>>711
だから普通は、内部的に圧縮されたファイルへのアクセスは、
1. 単純にメモリ展開する
2. 何らかのプロキシオブジェクトでエミュレートする
のどちらかで、大概前者だしGitでもそうなってる。
だからここで速度低下とかは関係ない話だ。
(なお後者は/dev/zeroとか/dev/randomとかと言えば分かるだろう)
そこを他の言語、PHP/JS/Go/Rustのどれかを知ってれば、
そこでオブジェクトにしてI/O分離してマルチターゲットにしてしまうのも常識。
これを思いつけない/知らないのだから多分本当にCしか知らない連中だけでやってるよ。
君からもそれを感じる。

ちなみに重くなる/ならないなら、SQLiteは大量の小さいファイルならファイルよりも速いぜ！とか言ってるし、
他DBと違ってローカルだから試してみると面白いかもよ。
外部ﾘﾝｸ[html]:www.sqlite.org

714(1): (ﾜｯﾁｮｲ d9e4-Xmag) 2022/10/31(月)21:52 ID:GzQExg5g0(7/10) AAS
>>713
内部的に圧縮されたファイル？
「ファイルツリーはdiffコマンドがそのまま解釈できるような形式でファイルシステム上に存在しない」
これを勘違いしたのかな？
ファイルじゃなくてファイルツリーね
gitのディレクトリーのツリー構造を保持する方法独特だからその各ファイルをdiff取ってもらうためにツリーをtraverseするインターフェースを提供する必要が有る
ファイル単位の差分抽出なんて複雑な処理でもないんだからそれをやってもらうためにそれよりはるかに複雑なインターフェースを設計するとか無駄以外の何物でもないな

715(1): (ﾜｯﾁｮｲ 497b-vCJ4) 2022/10/31(月)21:54 ID:J+3pjzxx0(19/22) AAS
>>712
ただそれはedとdiffが問題だったわけではないだろうし、
仮にそうだったとしても、正しくソフトウェアを構成していればすぐに交換可能で、全く問題にならないんだよ。
その辺がソフトウェア階層の意識がないなあと思うところだよ。
Cはそういう世界でもあるけどさ。

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

それでLinusが言ってるように、キモは
> 問題はコード量ではなくて、どのようにデータを扱うかだった。
> 初期の実際のコード量は、かなり少ない。基本的な考え方が正しいかどうかにかかっている。開発を始める前からそのアイディアについて考察していたわけだ。
であって、要はツリーコントロールであって、I/Oではないだろ。

716(1): (ﾜｯﾁｮｲ 497b-vCJ4) 2022/10/31(月)22:11 ID:J+3pjzxx0(20/22) AAS
>>714
ああ、ファイルと勘違いしていたのは事実だが、それでも意味は同じだよ。

> gitのディレクトリーのツリー構造を保持する方法独特だからその各ファイルをdiff取ってもらうためにツリーをtraverseするインターフェースを提供する必要が有る
勿論その通りだが、つまりこれはファイルシステムであって、その先に隠蔽出来るんだよ。
NTFSかext4かbitlockerを使ってるか圧縮DISKかをアプリは気にしないだろ。
それはOSがファイルシステムの違いを隠蔽してくれるから。これと同じ。
同様に、 cat-file で末端のファイルの形式の違いは隠蔽出来て、
ファイルシステムドライバ（とでも言うべきか？)で、ツリー詳細構造の違いは隠蔽出来るんだよ。
そしてそれは当然Gitにも入ってる。
だからその上位からはGit形式のファイルツリー/オブジェクトツリーを
普通のファイルシステム/オブジェクトと同じように見せることは可能なんだよ。
そして実際にそうしてるはずだよ。

だからな、自分が管轄してる階層以外の所は、はっきり言って関係ないしコードからも見えないんだよ。
Cの場合はその辺の階層意識が希薄で、実際君との空回りもこれだが、Gitもこの辺は正しく実装されてるはず。

717(3): (ﾜｯﾁｮｲ d9e4-Xmag) 2022/10/31(月)22:17 ID:GzQExg5g0(8/10) AAS
>>716
cat-fileは単にblobの中身を表示するコマンドってだけで、逆をやるblobを作るコマンドが用意されてるわけじゃない
つまりここでソフトウェア的に階層がきれいに分かれてるわけじゃない
ここを置き換えて自由な圧縮アルゴリズムを使えるようになっていたとしたら
Libgit2 みたいな別実装のライブラリが出現する余地もなかっただろう
ここは変にインターフェース階層なんて用意しなくて正解
gitはツールであるとともにフォーマットでもあるんだよ
フォーマットに自由なオプションが用意されているとか別の実装を作る側としては悪夢でしかない

718: (ﾌﾞｰｲﾓ MMeb-wVCK) 2022/10/31(月)22:33 ID:DiR+92tnM(1) AAS
そう、このクレーマーはGitのデータモデルやデータフォーマットとしての側面を見落としてる
確固とした優れたデータモデルを持つってのは立派なUNIX哲学の一つなんだけどねえ

719: (ﾜｯﾁｮｲ 8bbb-VzUj) 2022/10/31(月)22:39 ID:h5Hfu9WR0(6/9) AAS
>>715
いいから、お前に git は向いてないから消えろ。git は万人向けじゃない。
自分で納得がいくものを作ってそれを使え。
どうせ多人数がかかわるようなプロジェクトとかには縁がないだろから、一人で寂しく使ってろ。

720(2): (ﾜｯﾁｮｲ 497b-vCJ4) 2022/10/31(月)22:41 ID:J+3pjzxx0(21/22) AAS
>>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は上から下まで全管轄出来るんだけど、無駄にやりすぎてるコードになりがちなのも事実。
なまじ出来るものだからやっちゃうのだけど、それは正しい構成ではないんだよ。

721: (ﾜｯﾁｮｲ 8bbb-VzUj) 2022/10/31(月)22:45 ID:h5Hfu9WR0(7/9) AAS
>>720
糞理論いいから、まずは作って見せろ。

722(1): (ﾜｯﾁｮｲ d9e4-Xmag) 2022/10/31(月)22:50 ID:GzQExg5g0(9/10) AAS
>>720
そんな入れ替え可能な階層分けが必要なら最初から全部C言語以外で作ればよかったんだよ
でもリーナスはC言語を選んでほぼunixシステムコールを直接叩く方式で実装した

hqなんかの方がお前の好みに近いだろうけど、hqは廃れてgit全盛となった
むかしはこのスレにもhq信者が盛んにチョッカイかけに来たもんだけど、いまは何してるんだろうな

723: (ﾜｯﾁｮｲ 8bbb-VzUj) 2022/10/31(月)22:55 ID:h5Hfu9WR0(8/9) AAS
もはや名前すらちゃんと覚えてもらえてない hg さん。

724(2): (ﾜｯﾁｮｲ 497b-vCJ4) 2022/10/31(月)22:59 ID:J+3pjzxx0(22/22) AAS
>>717
あーだからな、フレームワークを一度使ってみれば勉強になると思うよ。

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

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

>>722
つかなんか勘違いしてると思うが、階層を分けたら遅くなるとかではないんだよ。
(厳密に言えば関数コールが1つ入るからその分は遅くなるが)

725: (ﾜｯﾁｮｲ 8bbb-VzUj) 2022/10/31(月)23:00 ID:h5Hfu9WR0(9/9) AAS
>>724
いいからお前は自分で作れ git 使う必要はないぞ

726(1): (ﾜｯﾁｮｲ d9e4-Xmag) 2022/10/31(月)23:25 ID:GzQExg5g0(10/10) AAS
>>724
結局gitがどういう方式で実装されているかなんてことよりファイルフォーマットの方が重要ってことだ
だからgitの実装とファイルフォーマットを切り離すようなインターフェース階層は必要無いしだれも実装しない
必要無いものを実装すれば余計なメンテの手間もかかる

727: (ﾜｯﾁｮｲ 531d-rkLt) 2022/10/31(月)23:25 ID:Sz6pT8cp0(1) AAS
すごい勢いでスレ消費してるな…

>>676
1回のコミットで整理っていうのは、1つのコミットにまとめるってことかな？
それとも1回のコマンドで済ませたいってことかな(何度もcherry-pickしたくない)？

merge squashじゃあかんかね。
連続してない部分的なコミットをまとめるならrebase squashでもいいよ。
連続してないコミットなら、rebase -i使えばいいよ。いらないコミットはdropできるよ。
rebaseするときは、元のブランチ消えるから、必要なら復帰用にブランチ作っておくといいよ。

728(1): (ﾜｯﾁｮｲ 497b-vCJ4) 2022/11/01(火)00:01 ID:Jzc3CN/20(1/8) AAS
>>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マクロで実体を呼ぶかラッパを呼ぶか簡単に切換可能なので、
実際どうするかはともかく、ソースコードはメンテしておくべきだよ。

729(1): (ﾜｯﾁｮｲ d9e4-Xmag) 2022/11/01(火)00:33 ID:kz7RaJ2H0(1/5) AAS
>>728
現状の.git/* の形式が十分にシンプル明解でこれが共通I/Fになっている
すでにこの共通I/Fに沿っていろいろな実装が存在している
結果これを変更するための内部的なI/F階層が必要とされていない
内部的な構造としてはそんなことよりSHA-1をSHA-256に変更することの方が重要で実験的実装が進んでいる
切り口が違うからお前の言うような階層をつくってもハッシュの形式の変更には対応できない
そんなくだらないことに割く労力は無い

730: (ﾜｯﾁｮｲ a95f-Tk+f) 2022/11/01(火)00:33 ID:1wY/uhrP0(1) AAS
長いからまとめたよ。
「俺は実装しないけど、俺以外の誰かが俺の推測に沿うように実装しておくべきなんだ。俺は実装しないけど。」

731: (ﾜｯﾁｮｲ 8b8f-5UCg) 2022/11/01(火)01:23 ID:ju8ytuSJ0(1/2) AAS
なんでgitの話でフレームワークの話が出て来んのかな

732(1): (ﾜｯﾁｮｲ 7997-uk66) 2022/11/01(火)01:46 ID:Mxyz6tUC0(1/2) AAS
無限の自由度の代わりに組み合わせ爆発が生じてエッジケースでバグが出まくり、というのは嫌だという設計思想なんじゃないかな
確かにWeb系でDIするのは当たり前だけど、RDBMSやビジネスロジック以外はトラブってもいいWeb系と違ってgitでトラブル続発したら困るし。
ファイルシステムみたいなものでは。

733(1): (ﾜｯﾁｮｲ 7997-uk66) 2022/11/01(火)01:52 ID:Mxyz6tUC0(2/2) AAS
あと大体git自体が膨大なLinuxカーネルのVCSとしてかなり高速に、確実に動作する必要があったという大前提があるだろう。
そこを無視して汎用的にはこっちの方がいいってのは違うんじゃないかな。
汎用的な用途としてのVCSが欲しいならばpost-gitを作るしかないと思うよ。

734: (ﾜｯﾁｮｲ 8bbb-VzUj) 2022/11/01(火)02:08 ID:QdibabTL0(1/2) AAS
そもそも汎用性がある方が良いというのから幻想
道具は利用目的にあっているかどうかが全て十徳ナイフありがたがるやつは素人

735(1): (ﾜｯﾁｮｲ 497b-vCJ4) 2022/11/01(火)03:17 ID:Jzc3CN/20(2/8) AAS
>>729
それも根本的に間違ってる。
ハッシュはハッシュでレイヤーを切るから、正しく構成されてるソフトウェアなら、
ハッシュを変更するのはハッシュ生成関数内だけで済むんだよ。

具体的には、全体は get_hash() を呼んでハッシュを受け取るようにしておいて、
その get_hash() 内でSHA-1かSHA-256かmd5かを変更するだけにするんだよ。
というかこんなの当たり前すぎてお前らが理解出来てないのにびびる。
オブジェクト指向では基本中の基本とされてることだぞ。
お前らプログラマじゃねえだろマジで。プログラマなら、ちょっと勉強し直さないとヤバいぜ。

ただこれは、本質的に「返ってくるオブジェクトのサイズは予想出来ない」事になり、
C的な「返ってくるオブジェクトのサイズは呼ぶ前に完全に予期出来ている（だいたい固定）」の世界にはフィットしない。
C++とかはデストラクタで、その他言語はGCで対応するのが常策だが、
これに関してはバイナリにハードコードで問題ないから#defineでいい。

ただC++だと#defineは悪とされてるから、絶対にデストラクタでやるんだ！いやスマポだ！みたいな奴も居て、
それを勧めてくるからLinusはブチ切れてるわけだが。
だけどハッシュサイズなんて動的に変化すること無いのだから、#defineで全く問題ない。
そしてそれに手こずってる時点で、#defineでの切換すら出来ない、
全体がそれぞれで勝手にSHA-1を生成してたコードになってるって事だよ。
それはマジで糞だよ。(まあ、でも直せば済む話ではあるんだけどさ)

上下前次 1-新書関写板覧索設栞歴

あと 267 ﾚｽあります
ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ

ぬこの手ぬこTOP 0.023s