[過去ﾛｸﾞ] Git 18 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
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だが、これはこれで間違った使われ方も多いが）
741(1): (ﾜｯﾁｮｲ d9e4-Xmag) 2022/11/01(火)09:16 ID:kz7RaJ2H0(3/5) AAS
長々とご苦労さんだがお前SHA-256対応の意味が理解できてないよ
742(1): (ﾜｯﾁｮｲ 497b-vCJ4) 2022/11/01(火)09:26 ID:Jzc3CN/20(7/8) AAS
>>741
俺は以下記事の理解書いてる。
俺が書いた事の意味が分からないのは君の問題。
外部ﾘﾝｸ:www.infoq.com
ただ、初めてOOPを示されていきなり意義を理解出来る奴はほぼ居ないのも事実。
でも、君は確実に老害扱いされてると思うよ。
743: (ﾜｯﾁｮｲ f15f-iYvO) 2022/11/01(火)09:32 ID:WFTKMpG40(1) AAS
なんだか知らんけど5chでうだうだ言ってて何になるの
744(1): (ﾜｯﾁｮｲ d9e4-Xmag) 2022/11/01(火)09:36 ID:kz7RaJ2H0(4/5) AAS
>>742
君はその記事の意味することを理解できてないね
コミットオブジェクトの構造とか役目を理解出来てないと難しいかもしれない
745(2): (ﾜｯﾁｮｲ 497b-vCJ4) 2022/11/01(火)09:57 ID:Jzc3CN/20(8/8) AAS
>>744
そう思いたいんだろうけど、残念ながらそうじゃない。
少なくとも君はソフトウェア階層やOOPの基本事項について全く理解出来てない。
だから今、老害と言われ続けるか、再び学び直して熟練者と言われるかの分水嶺にいるだけ。
俺は君に何も強制することは出来ないが。
確かに俺はGit初心者なので、記事の理解は間違ってるかもしれない。
でも、ハッシュの中身や長さが変わったり混在したところで、
正しく構成されてるソフトウェアなら数行の変更で対応可能なのは事実だよ。
そして君と同様の人達によってGitが作られているのであれば、
そりゃそうなってなくて苦労するんだろうさ。
まあいいけどね。もう水掛け論だから終わりにしようぜ。これ以上やってもお互い得る物もないし。
746: (ﾜｯﾁｮｲ 8b8f-5UCg) 2022/11/01(火)10:12 ID:ju8ytuSJ0(2/2) AAS
> GITは、すべてのファイルオブジェクトとコミットの識別と整合性チェックをSHA-1に強く依存しています
こう書いてあるのになんで無視するんだろう
747(1): (ﾜｯﾁｮｲ d9e4-Xmag) 2022/11/01(火)10:29 ID:kz7RaJ2H0(5/5) AAS
>>745
数行で対応ｗ
それが出来ないgithubは無能集団なんですねｗ
糞MSに買われちゃうぐらいだから仕方ないか
748: (ｵｯﾍﾟｹ Src5-8VyY) 2022/11/01(火)12:34 ID:lDKItQe4r(1) AAS
Git初心者に語らせると頓珍漢な文章が生まれるという好例
749(1): (ﾜｯﾁｮｲ 8bbb-VzUj) 2022/11/01(火)12:39 ID:QdibabTL0(2/2) AAS
>>745
お前日本語読めなさそうだな
ましてやリンク先にある英語とかかけらも理解できてないだろ
混在とかじゃないぞ。二つを同時につけて「安全」に相互変換するということだぞ
安全にすることが目的でSHA-256を使えば解決みたいな話じゃない
お前みたいなのが目的と手段を取り違えるタイプの典型
OOPとかアホなプログラマでも理解できる単純なことなわけないだろ
そんなんで済むならとっくに終わってる
まずは常識で考えろ
できないなら黙って勉強しろ
750: (ﾜｯﾁｮｲ 699f-1Eu/) 2022/11/01(火)18:29 ID:/+vO/8+o0(1) AAS
長文すげー
751: (ﾜｯﾁｮｲ 497b-vCJ4) 2022/11/02(水)05:40 ID:n+gr/3CY0(1/2) AAS
>>749
どうであれ同じだよ。
複数付けようが、何をどう組み合わせようが、
抽象化の向こうの実体については知らないし、取り扱うコードも存在してないから、
同じバイナリで動作するんだよ。それが抽象化と隠蔽で、これはOOPの基本中の基本。
752: (ﾜｯﾁｮｲ 497b-vCJ4) 2022/11/02(水)05:41 ID:n+gr/3CY0(2/2) AAS
んー、お前ら完全に化石だわ。若い奴からは確実に馬鹿にされてるよ。
というか、現在において有名OSSにこんな化石居住区が存在してたことにびっくりだわ。
>>747
数行ってのは誇張ではなく、実際にそんなもんなんだよ。
例えばMMDは3DVision対応に20-30行と言ってるが、
> そのため、樋口氏がMMDの3D Vision対応に要したのは、20～30行程度の簡単なコーディングのみだった。
> 外部ﾘﾝｸ[html]:pc.watch.impress.co.jp
この樋口氏はVer5->7でDirectX対応してて、その時もインタビュー受けてて(ググッても出てこないが)
確か「よくよく確認して、実際に変更する必要があるのは2-3行だったのでほっとしました」
とか言ってたはず。
これは特殊ケースではなく、こうなるように設計するんだよ。
これに対してGitはマニュアル見てもそういう思想が全く見あたらず、「頑張ればいいよね」で終わってる。
だから糞なソースも「頑張って」修正して何とかするんだ、のノリだ。
ソフトウェア工学はそんなのは20年前にクリアしてて、今は、
A. どうすれば変更に対して強くなるか（仕様変更があってもソースコードを変更せずに済むか）
B. どうすればそもそもソースコードを記述する必要すらなく出来るのか(全ての状況に対し同じバイナリで対応する)
C. どうすれば出来るだけ早い段階でバグを検出出来るか
とか移ってて、大体馬鹿がCに対して悪ノリしてるからLinusがこき下ろす事態になるのだが、
ABはちゃんとやらないと話にならないよ。
だからまあ、次のGitは「勉強をがんばらなくてすむGit」で、
実装で一番簡単な方法は、Gitをバックエンドに使ってシェルスクリプトでラップすることだよ。これらは既に言ったが。
でも君らは「頑張らなくちゃいけない」「頑張るべきものだ」と思っちゃってるみたいだから、
今のGitプロジェクトからはこれは出てこないだろう。
となると、上記のようにして簡単に実装したNext-Gitに成果をかっさらわれ続ける事態になると思うよ。
ちょうどGNU/Linuxの形に似てるが。
あれはLinusが悪いわけではないし、ストールマンも別になんとも思ってないようだけど。
753: (ﾜｯﾁｮｲ c114-Tk+f) 2022/11/02(水)06:01 ID:z+vraLDY0(1/2) AAS
> これは特殊ケースではなく、こうなるように設計するんだよ。
> これに対してGitはマニュアル見てもそういう思想が全く見あたらず、「頑張ればいいよね」で終わってる。
それあなたの感想ですよね？
gitはソースコード1行程度で変更終わりですよ
754: (ﾜｯﾁｮｲ c114-Tk+f) 2022/11/02(水)06:03 ID:z+vraLDY0(2/2) AAS
> 実装で一番簡単な方法は、Gitをバックエンドに使ってシェルスクリプトでラップすることだよ。これらは既に言ったが。
シェルスクリプトは移植性低いって分かってる？
シェルスクリプトでラップしようものなら
Linuxでは動くがFreeBSDでは動かないってことが
しょっちゅう発生する
シェルスクリプトで頑張るものじゃない
755(1): (ﾜｯﾁｮｲ d9e4-Xmag) 2022/11/02(水)07:01 ID:S2ENS6Jw0(1) AAS
git の一部機能は git コマンドを使ったスクリプトで実装されていたんだけど、多くのユーザーの要望に応える形でそれらのC言語化進めてる
756: (JP 0H8d-8VyY) 2022/11/02(水)09:34 ID:33j+wJW8H(1) AAS
シェルでラップw
USPから悪い影響でも受けたか？
757: (ﾜｯﾁｮｲ 8bbb-VzUj) 2022/11/02(水)10:35 ID:sFE/M4aa0(1) AAS
OOPなんて初心者プログラマ訓練ギブスってことを理解できなくてアホ理論展開しているやつがいてｗ
上下前次1-新書関写板覧索設栞歴
あと 245 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.024s