Git 18

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

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

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を生成してたコードになってるって事だよ。
それはマジで糞だよ。(まあ、でも直せば済む話ではあるんだけどさ)

736: (ﾜｯﾁｮｲ 497b-vCJ4) 2022/11/01(火)03:19 ID:Jzc3CN/20(3/8) AAS
>>732,733
これをDIと呼ぶのか？はさておき、DIでバグが増えるなんて事はないよ。
そして、get_hash()でのオーバーヘッドは関数呼び出し一回でしかなく、
それで致命的に遅くなるなんて事もないよ。
というか、GitのマージってI/Oバウンドだと思ってるが違うのか？

737(1): (ﾜｯﾁｮｲ d9e4-Ojdt) 2022/11/01(火)03:55 ID:kz7RaJ2H0(2/5) AAS
>>735
ただ単純にハッシュアルゴリズムをSHA-1からSHA-256に変更するわけじゃないぞ
既存のSHA-1リポジトリも全部(リベース状態にすることなしに)SHA-256で運用できるようにしたりするんだよ
gitの開発はリポジトリのフォーマットの継続性をとても重視してる

738: (ﾜｯﾁｮｲ 497b-vCJ4) 2022/11/01(火)08:06 ID:Jzc3CN/20(4/8) AAS
>>737
同じだよ。
正しく構成されてる場合は何種類混在しても全く問題ないし、簡単に変更可能だ。
つかマジでそれオブジェクト指向(OOP)の基本中の基本だから。

ただ、混在なら、Cで一般的に使われてるSIZEOFの#defineでは対応出来ないが、
Linusのコードなら、Cでは一般的に禁止されてる小文字マクロで
普通にそこら辺の関数もマクロだらけの可能性があり、(linuxカーネルコードがそう）
この場合は、#define内のマクロ定義を一箇所変更するだけで対応可能ではある。

が、まあ、マクロ云々の話は本来はNGとされてて他言語では厳禁だから、いわゆる正しい方策を示すと、
全体の関数はハッシュの中身が何か知らない状態で記述するんだよ。
get_hash()でハッシュのポインタを貰いました、中身は知りませんので具体的な操作はできません、
なので一々投げ返して操作して貰いますがよろしいですね？とする。

739: (ﾜｯﾁｮｲ 497b-vCJ4) 2022/11/01(火)08:06 ID:Jzc3CN/20(5/8) AAS
と書くと意味不明だが、この場合は要は貰ったポインタを一々投げ返して操作してもらう。
具体的には、

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って何？みたいな質問が掲示板上でもやたらでてくるわけでさ。

740: (ﾜｯﾁｮｲ 497b-vCJ4) 2022/11/01(火)08:51 ID:Jzc3CN/20(6/8) AAS
補足。

分からなければ「OOP 抽象化」でググって色々読んでみてくれ。
死ぬほどでてくるはず。マジで基本中の基本だから。
ハッシュを交換することに手こずるようなら、その『コード』は間違いなく糞だ。(Git自体が糞と言っているわけではない）
ただ、修正すればいいだけ、要は漏れなく上記のようにしてしまえばいいだけではあるが。

正しく構成すれば、Hash変更なんて簡単に出来るし、
そもそもそうなってないコードなんてOOPでは存在を許されてない。
（そうとは書けないように構成されてる。
それを強制的にやらせるシステムの一つがprivateだが、これはこれで間違った使われ方も多いが）

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

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

ぬこの手ぬこTOP 0.026s