[過去ﾛｸﾞ] Git 18 (1002ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
660(1): (ﾜｯﾁｮｲ 497b-vCJ4) 2022/10/31(月)00:21 ID:J+3pjzxx0(1/22) AAS
>>859
そうか？ならマニュアルの
> to cancel the effect of --patch
の部分は明らかに不要だから削除要請出しといてくれ。
というか君の「昔」がどれ位か知らんが、Linusの言ってた？フォーマットが統一されてないってのは、
diffの各種オプションではなく、edやsharに対してだと思うぞ。
662: (ﾜｯﾁｮｲ 497b-vCJ4) 2022/10/31(月)07:08 ID:J+3pjzxx0(2/22) AAS
色々確認したが、Gitの現状認識としては651であってるっぽい。
そして外部ツール使うしかないが、これは環境設定無しでコマンドだけで出来る。（動作確認済み)
git difftool --extcmd=/usr/bin/diff <commit> <commit>
> 外部ﾘﾝｸ:qastack.jp
ついでにその中、
> Gitについて学ぶほど、それは1人の人、つまり元のプログラマーのために作られたものだと感じます。
これもよく言われてるようだが、俺も今回の件で同意だ。
合理性に欠ける判断をしているのだから色々文句言われるのも当然だ。
ただLinusは自分用に作った物を公開したら勝手に使われてるだけだから、知ったこっちゃ無いってのも分かる。
ただそれならそうと、いつもの調子でドキュメントにも書いててくれないと困るね。
合理的な構成を推定すると迷子になってしまう。
俺は絶対に diff -u 以外のフォーマットを許さない！絶対にだ！
とか書いてあれば、最初から諦めるので無駄に探す必要はなかった。
俺はLinusのこういった感情的な部分はわりと好きなのだが、まあ昨今の code of conduct では書いても消されるんだろうけども。
663(1): (ﾜｯﾁｮｲ 497b-vCJ4) 2022/10/31(月)10:11 ID:J+3pjzxx0(3/22) AAS
てかGitってまさかのモノリシックかよ！
こりゃ文句言われるのも分かるわ。完全に方向を間違ってる。
結果的に肥大化していったのだろうけど、現在の状況でこれは駄目だよ。
つかこれシェル化する方向のプロジェクトはないの？
子コマンド群のバイナリだけ貰いたいんだけどさ。
666: (ﾜｯﾁｮｲ 497b-vCJ4) 2022/10/31(月)13:21 ID:J+3pjzxx0(4/22) AAS
>>665
それが従来形式のdiffの出力をさせない理由なら、
現在のGitプロジェクトの思想は俺とまるで合わない。
今時モノリシックとか、多分じきにこのプロジェクトは頓挫するよ。
multicsの再来だね。(俺は使ったこと無いけど)
自覚症状もあるみたいだし。
> Git is a fast, scalable, distributed revision control system with an unusually rich command set
> unusually
> 外部ﾘﾝｸ:www.git-scm.com
ただまあ本当にdiffも内製しているようで、ちょっと驚きだよ。
ただwikiによると当初はローレベルエンジン＋シェルスクリプトで、これは俺の思想と合致してる。
windowsに移植する際にシェルスクリプトをCに書き換え、そこでモノリシック化したようだ。
それで環境変数を見るとか、完全に開発の方向性を間違ってる。
当初のシェルスクリプト方式ならdiffを呼ぶだけだから、シンボリックリンクで好きなのと簡単に交換出来た。
この場合、Git側にコードは全く必要ないし、ユーザー側に予備知識も必要ない。
それをモノリシックにしてしまったから、環境変数を読むコードを必要とし、
ユーザーはマニュアルを読むことを強制させられる。
お互いに完全に無駄だ。
このメンテナは、ソフトウェアアーキテクチャはどうあるべきか、全く理解出来てない。
今ですらGitは難しすぎると文句言われてるだろ。
コードを書く為にコード管理システムの勉強が必要とか、完全に本末転倒だし。
じきに巨大な躯体を支えきれなくなって、分割プロジェクトが発生すると思うぜ。
それが多分Next-gitになるのだろうよ。
つか、何でGitはモノリシックを選択してんの？全く意味ねえと思うぞマジで。
本当にdiffとかを絶対に交換させない為？ならマジで死ねでしかないね。
669: (ﾜｯﾁｮｲ 497b-vCJ4) 2022/10/31(月)15:04 ID:J+3pjzxx0(5/22) AAS
>>667
他よりましなだけだろ。
ただ俺が思うに、Gitはもっと簡単に出来て、
・勉強しないといけないGit(今)
・勉強しなくてもなんとなく使えちゃうGit(次世代)
に分離すると思うよ。次世代版の需要圧力はもう既に十分あるし。
実のところ、今のgitにラッパシェルスクリプト群を被せれば次世代版出来ちゃうし、
(勿論見た目だけだがそれが重要)
俺はそれ作って使おうかとも思案中。
Gitは業務プロセス名のコマンドだから、実際何が起こっているのか分かりにくいのが一番の問題だよ。
コマンド名変えるだけでも相当変わる。
670(1): (ﾜｯﾁｮｲ 497b-vCJ4) 2022/10/31(月)15:05 ID:J+3pjzxx0(6/22) AAS
>>668
それに辿り着くのにググったりマニュアルを読まないといけないのが問題なんだよ。
今のGitは世界中のプログラマに努力を強いてて、その犠牲の上に成り立ってる。
3時間程度あれば、再現コード付きのバグ報告が出来てしまう。
それをマニュアルを読むのに費やしてるのだから、無駄でしょ。
世界中のプログラマが3時間を世界が進歩する方向に費やせたら、Gitももっとよくなってたはずだよ。
675(1): (ﾜｯﾁｮｲ 497b-vCJ4) 2022/10/31(月)18:09 ID:J+3pjzxx0(7/22) AAS
>>671
OSSが世界中のプログラマからの元気玉なのは事実だろ
元気をマニュアルに消費されてなければ、もっと大きな元気玉になってただろうよ
678(1): (ﾜｯﾁｮｲ 497b-vCJ4) 2022/10/31(月)18:33 ID:J+3pjzxx0(8/22) AAS
>>672
> のべ何万人も十年以上使い続けた結果
それは言いすぎ。カーネルコミュニティって400人規模と聞いた覚えがある。
毎年全員入れ替わっても1万人規模だよ。
まあこれは本質ではないのでいいが。、
> 「馬鹿でも使えるものは馬鹿しか使わない」
これって誰の言葉だ？Linusが
> マジで、Cを選択する理由が「何もなかった」としてもだ、C++プログラマー避けになるというだけで、Cを使う大義名分になる。
> 外部ﾘﾝｸ[html]:cpplover.blogspot.com
と言ってるのは知ってるが。（しかもこれはGitの話らしい）
ちなみに俺はLinusの意見にも賛同する。プロジェクトに馬鹿が混入しないことは本当に重要なことだ。
ただ君と根本的に違うのは、「簡単は正義」と思ってることだ。
簡単に出来るのなら、簡単な方がいい。
馬鹿をふるい落とす為に敢えて難しい構造やコードにすることはない。
俺が見る限りLinusもそうしているわけではないが、君がそうしたいのは理解した。
まあ機会があれば実装して広めることになるかもしれない。
ただ俺は別のことをやろうとしてるから、Gitなんて動けば何でもいい程度でしかないので、優先順位は極めて低い。
あとたぶん、君は
> 文句言ってる暇があったらコード書いて変更した方が速い
の意味を誤解している。が、これは今言っても通じないと思う。
682(1): (ﾜｯﾁｮｲ 497b-vCJ4) 2022/10/31(月)18:50 ID:J+3pjzxx0(9/22) AAS
>>674
不可欠な機能ではあるが、核心的機能ではない。
事実として、Git内のdiffをGNUdiffに差し替えても、マージやリベースが出来なくなるわけではないだろ。
Gitは方針を間違ってる。
もし仮にGNUdiffのアルゴリズムが糞過ぎて出力が糞でマージが出来ないとしても、
アルゴリズム部分はGNUdiffにcontributeし、Gitがそのソースコードを使えばいいだけ。
Git内のdiffもGNUdiffからforkしたのだろうし、普通はこうすると思うけど。
別に実装すべきなのはフォーマッタで、--word-diffとかの部分だよ。
勿論GNUdiffに入れるのがベストだが、この辺は断られてもおかしくないし。
ただこれも人間用であって、マージする為に必要な機能部分ではないから、
君らから見てもGitではなくdiffに入れておけ、となるはずだが。
まあdiffに手を入れたくなるのは分かるが、それはソフトウェア開発ではやってはいけない方向で、
我慢してGNUdiffにcontributeしておく方が全体の長期的利益になるんだよ。
Gitがこの辺、アルゴリズムとViewをごちゃ混ぜに扱ってるのも気になる。
MVCとかまるで言われない世界ではあるけど、それでも基本として理解しておくべきだよ。
ビューを分離しておくことはものすごく重要だから。
685(1): (ﾜｯﾁｮｲ 497b-vCJ4) 2022/10/31(月)19:49 ID:J+3pjzxx0(10/22) AAS
ちなみに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.
> 外部ﾘﾝｸ:www.git-scm.com
このオプションが相当にヤバい。
これはデフォで
diff | less
となってる部分を、
diff --output-indicator-new='>' | less
とすれば幸せになれますよ、ということだが、これは
diff | sed 's/^\+/>/' | less
とすれば出来ることなので、gnuにこれを提案しても当然「そんなんイラネーよ」で終わってしまう。
Cで実装すべき案件ではないから。
そこで何故断られたのかを理解せず、だったらforkしますのノリなので、完全に無能の働き者だよ。
多分こいつらは本当にCしか書けない、Cしか知らない連中だ。
sed/awk/perl/python/rubyのどれかでも少しでも出来れば、この発想にはならない。
コントリビューターがこれを出してくるのも、メンテナがこれを止めないのも狂ってる。
プロジェクトにはいまだに正規表現を書けない老害しかいないと分かる。
だからこのオプションは、Linus的に言えば、常識的なプログラマー除けにはなってしまってるだろうよ。
688(1): (ﾜｯﾁｮｲ 497b-vCJ4) 2022/10/31(月)19:53 ID:J+3pjzxx0(11/22) AAS
>>684
どういう意味？
少なくともどのプラットフォームにもdiffはあるだろ。
693(1): (ﾜｯﾁｮｲ 497b-vCJ4) 2022/10/31(月)20:02 ID:J+3pjzxx0(12/22) AAS
>>686
> diffは環境依存するコマンド
は？
まあ仮にそうだったとして、Git内のdiffがあらゆる環境で同じdiffを生成するように小細工してるとでも？
ただまあこの場合、ぶっちゃけ、小細工出来る＝原因が分かってる≒多分Intサイズとかの違い、だから、
リモートリポジトリのマージで（俺は実際何を送ってくるのか知らんが）diffを送ってくるのなら、
それはマージ時点で鯖に問い合わせてdiffで済むかファイル本体を送らせてローカルでdiff取るかすればいいだけでしょ。
正直、原因究明して小細工するより後者の方が断然楽なので、合理的判断ならそうしてると思うけど。
>>691
前後したが上記。
>>689
その内部でマージやリベースを行う為のdiffをGNUdiffのdllコールと置き換えて、
マージやリベースが動かなくなるかって話だよ。普通に動くと思うけど。
696(2): (ﾜｯﾁｮｲ 497b-vCJ4) 2022/10/31(月)20:08 ID:J+3pjzxx0(13/22) AAS
>>692
> ユニファイド形式diffを最初に開発したのはウェイン・デイヴィソンで、
> 1990年8月のことであった（comp.sources.miscのVolume 14にunidiffとして投稿）。
> リチャード・ストールマンがGNUプロジェクトのdiffコマンドにこの機能を1ヶ月後に加え、
> 1991年1月リリースのGNU diff 1.15から使えるようになった。
> 外部ﾘﾝｸ:ja.wikipedia.org
ただそれ以前に、-uがある/ないはGitでマージ出来る/出来ないにはならないだろ。
それは完全に人間用であってさ。
697(1): (ﾜｯﾁｮｲ 497b-vCJ4) 2022/10/31(月)20:10 ID:J+3pjzxx0(14/22) AAS
>>694,695
だからファイル本体をダウンロードして、mergeするマシン上でdiff取ればいいだけだろ。
これでマシン依存をなくせるし、普通の実装だよ。
通じないのか？どうもお前の書き込みは頭が悪そうだし。ならここら辺で切り上げるが。
701(1): (ﾜｯﾁｮｲ 497b-vCJ4) 2022/10/31(月)20:38 ID:J+3pjzxx0(15/22) AAS
>>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に入れてるのを糞に言ってるが、保存先は本質ではないし、
適切なアーキテクチャであれば簡単に交換可能なものだ。
だから本来、こんな議論が発生する余地もないのだけど。
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はかなり糞なのも事実だが。
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
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もこの辺は正しく実装されてるはず。
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は上から下まで全管轄出来るんだけど、無駄にやりすぎてるコードになりがちなのも事実。
なまじ出来るものだからやっちゃうのだけど、それは正しい構成ではないんだよ。
724(2): (ﾜｯﾁｮｲ 497b-vCJ4) 2022/10/31(月)22:59 ID:J+3pjzxx0(22/22) AAS
>>717
あーだからな、フレームワークを一度使ってみれば勉強になると思うよ。
フレームワークは型に嵌められるのだけど、
その型はそれなりの奴が一生懸命考えた型だから、それなりなんだよ。
なるほどこうすればファイルもネットワークもDBも全部同じコードでいけるのか、とか分かるよ。
ファイルシステム構造も、末端のファイル自体も、
上位には関係ないように隠蔽出来るし、難しいことではない。
実際、Git cat-file はGitファイルシステムを隠蔽してる、とも言えるだろ。
>>722
つかなんか勘違いしてると思うが、階層を分けたら遅くなるとかではないんだよ。
(厳密に言えば関数コールが1つ入るからその分は遅くなるが)
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.032s