[過去ﾛｸﾞ] Git 18 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
713(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4) [sage] 2022/10/31(月) 21:39:28.36 ID:J+3pjzxx0(18/22) AAS
>>711
だから普通は、内部的に圧縮されたファイルへのアクセスは、
1. 単純にメモリ展開する
2. 何らかのプロキシオブジェクトでエミュレートする
のどちらかで、大概前者だしGitでもそうなってる。
だからここで速度低下とかは関係ない話だ。
(なお後者は/dev/zeroとか/dev/randomとかと言えば分かるだろう)
そこを他の言語、PHP/JS/Go/Rustのどれかを知ってれば、
そこでオブジェクトにしてI/O分離してマルチターゲットにしてしまうのも常識。
これを思いつけない/知らないのだから多分本当にCしか知らない連中だけでやってるよ。
君からもそれを感じる。
ちなみに重くなる/ならないなら、SQLiteは大量の小さいファイルならファイルよりも速いぜ！とか言ってるし、
他DBと違ってローカルだから試してみると面白いかもよ。
https://www.sqlite.org/fasterthanfs.html
714(1): デフォルトの名無しさん (ﾜｯﾁｮｲ d9e4-Xmag) [sage] 2022/10/31(月) 21:52:54.41 ID:GzQExg5g0(7/10) AAS
>>713
内部的に圧縮されたファイル？
「ファイルツリーはdiffコマンドがそのまま解釈できるような形式でファイルシステム上に存在しない」
これを勘違いしたのかな？
ファイルじゃなくてファイルツリーね
gitのディレクトリーのツリー構造を保持する方法独特だからその各ファイルをdiff取ってもらうためにツリーをtraverseするインターフェースを提供する必要が有る
ファイル単位の差分抽出なんて複雑な処理でもないんだからそれをやってもらうためにそれよりはるかに複雑なインターフェースを設計するとか無駄以外の何物でもないな
715(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4) [sage] 2022/10/31(月) 21:54:31.60 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) [sage] 2022/10/31(月) 22:11:44.63 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) [sage] 2022/10/31(月) 22:17:17.34 ID:GzQExg5g0(8/10) AAS
>>716
cat-fileは単にblobの中身を表示するコマンドってだけで、逆をやるblobを作るコマンドが用意されてるわけじゃない
つまりここでソフトウェア的に階層がきれいに分かれてるわけじゃない
ここを置き換えて自由な圧縮アルゴリズムを使えるようになっていたとしたら
Libgit2 みたいな別実装のライブラリが出現する余地もなかっただろう
ここは変にインターフェース階層なんて用意しなくて正解
gitはツールであるとともにフォーマットでもあるんだよ
フォーマットに自由なオプションが用意されているとか別の実装を作る側としては悪夢でしかない
718: デフォルトの名無しさん (ﾌﾞｰｲﾓ MMeb-wVCK) [sage] 2022/10/31(月) 22:33:44.64 ID:DiR+92tnM(1) AAS
そう、このクレーマーはGitのデータモデルやデータフォーマットとしての側面を見落としてる
確固とした優れたデータモデルを持つってのは立派なUNIX哲学の一つなんだけどねえ
719: デフォルトの名無しさん (ﾜｯﾁｮｲ 8bbb-VzUj) [sage] 2022/10/31(月) 22:39:17.91 ID:h5Hfu9WR0(6/9) AAS
>>715
いいから、お前に git は向いてないから消えろ。git は万人向けじゃない。
自分で納得がいくものを作ってそれを使え。
どうせ多人数がかかわるようなプロジェクトとかには縁がないだろから、一人で寂しく使ってろ。
720(2): デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4) [sage] 2022/10/31(月) 22:41:57.65 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) [sage] 2022/10/31(月) 22:45:45.36 ID:h5Hfu9WR0(7/9) AAS
>>720
糞理論いいから、まずは作って見せろ。
722(1): デフォルトの名無しさん (ﾜｯﾁｮｲ d9e4-Xmag) [sage] 2022/10/31(月) 22:50:56.79 ID:GzQExg5g0(9/10) AAS
>>720
そんな入れ替え可能な階層分けが必要なら最初から全部C言語以外で作ればよかったんだよ
でもリーナスはC言語を選んでほぼunixシステムコールを直接叩く方式で実装した
hqなんかの方がお前の好みに近いだろうけど、hqは廃れてgit全盛となった
むかしはこのスレにもhq信者が盛んにチョッカイかけに来たもんだけど、いまは何してるんだろうな
723: デフォルトの名無しさん (ﾜｯﾁｮｲ 8bbb-VzUj) [sage] 2022/10/31(月) 22:55:40.76 ID:h5Hfu9WR0(8/9) AAS
もはや名前すらちゃんと覚えてもらえてない hg さん。
724(2): デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4) [sage] 2022/10/31(月) 22:59:10.92 ID:J+3pjzxx0(22/22) AAS
>>717
あーだからな、フレームワークを一度使ってみれば勉強になると思うよ。
フレームワークは型に嵌められるのだけど、
その型はそれなりの奴が一生懸命考えた型だから、それなりなんだよ。
なるほどこうすればファイルもネットワークもDBも全部同じコードでいけるのか、とか分かるよ。
ファイルシステム構造も、末端のファイル自体も、
上位には関係ないように隠蔽出来るし、難しいことではない。
実際、Git cat-file はGitファイルシステムを隠蔽してる、とも言えるだろ。
>>722
つかなんか勘違いしてると思うが、階層を分けたら遅くなるとかではないんだよ。
(厳密に言えば関数コールが1つ入るからその分は遅くなるが)
725: デフォルトの名無しさん (ﾜｯﾁｮｲ 8bbb-VzUj) [sage] 2022/10/31(月) 23:00:32.54 ID:h5Hfu9WR0(9/9) AAS
>>724
いいからお前は自分で作れ git 使う必要はないぞ
726(1): デフォルトの名無しさん (ﾜｯﾁｮｲ d9e4-Xmag) [sage] 2022/10/31(月) 23:25:07.54 ID:GzQExg5g0(10/10) AAS
>>724
結局gitがどういう方式で実装されているかなんてことよりファイルフォーマットの方が重要ってことだ
だからgitの実装とファイルフォーマットを切り離すようなインターフェース階層は必要無いしだれも実装しない
必要無いものを実装すれば余計なメンテの手間もかかる
727: デフォルトの名無しさん (ﾜｯﾁｮｲ 531d-rkLt) [sage] 2022/10/31(月) 23:25:57.99 ID:Sz6pT8cp0(1) AAS
すごい勢いでスレ消費してるな…
>>676
1回のコミットで整理っていうのは、1つのコミットにまとめるってことかな？
それとも1回のコマンドで済ませたいってことかな(何度もcherry-pickしたくない)？
merge squashじゃあかんかね。
連続してない部分的なコミットをまとめるならrebase squashでもいいよ。
連続してないコミットなら、rebase -i使えばいいよ。いらないコミットはdropできるよ。
rebaseするときは、元のブランチ消えるから、必要なら復帰用にブランチ作っておくといいよ。
728(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4) [sage] 2022/11/01(火) 00:01:33.71 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) [sage] 2022/11/01(火) 00:33:10.99 ID:kz7RaJ2H0(1/5) AAS
>>728
現状の.git/* の形式が十分にシンプル明解でこれが共通I/Fになっている
すでにこの共通I/Fに沿っていろいろな実装が存在している
結果これを変更するための内部的なI/F階層が必要とされていない
内部的な構造としてはそんなことよりSHA-1をSHA-256に変更することの方が重要で実験的実装が進んでいる
切り口が違うからお前の言うような階層をつくってもハッシュの形式の変更には対応できない
そんなくだらないことに割く労力は無い
730: デフォルトの名無しさん (ﾜｯﾁｮｲ a95f-Tk+f) [sage] 2022/11/01(火) 00:33:26.41 ID:1wY/uhrP0(1) AAS
長いからまとめたよ。
「俺は実装しないけど、俺以外の誰かが俺の推測に沿うように実装しておくべきなんだ。俺は実装しないけど。」
731: デフォルトの名無しさん (ﾜｯﾁｮｲ 8b8f-5UCg) [sage] 2022/11/01(火) 01:23:19.93 ID:ju8ytuSJ0(1/2) AAS
なんでgitの話でフレームワークの話が出て来んのかな
732(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 7997-uk66) [] 2022/11/01(火) 01:46:22.68 ID:Mxyz6tUC0(1/2) AAS
無限の自由度の代わりに組み合わせ爆発が生じてエッジケースでバグが出まくり、というのは嫌だという設計思想なんじゃないかな
確かにWeb系でDIするのは当たり前だけど、RDBMSやビジネスロジック以外はトラブってもいいWeb系と違ってgitでトラブル続発したら困るし。
ファイルシステムみたいなものでは。
733(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 7997-uk66) [] 2022/11/01(火) 01:52:53.48 ID:Mxyz6tUC0(2/2) AAS
あと大体git自体が膨大なLinuxカーネルのVCSとしてかなり高速に、確実に動作する必要があったという大前提があるだろう。
そこを無視して汎用的にはこっちの方がいいってのは違うんじゃないかな。
汎用的な用途としてのVCSが欲しいならばpost-gitを作るしかないと思うよ。
734: デフォルトの名無しさん (ﾜｯﾁｮｲ 8bbb-VzUj) [sage] 2022/11/01(火) 02:08:49.56 ID:QdibabTL0(1/2) AAS
そもそも汎用性がある方が良いというのから幻想
道具は利用目的にあっているかどうかが全て十徳ナイフありがたがるやつは素人
735(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4) [sage] 2022/11/01(火) 03:17:45.94 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) [sage] 2022/11/01(火) 03:19:13.38 ID:Jzc3CN/20(3/8) AAS
>>732,733
これをDIと呼ぶのか？はさておき、DIでバグが増えるなんて事はないよ。
そして、get_hash()でのオーバーヘッドは関数呼び出し一回でしかなく、
それで致命的に遅くなるなんて事もないよ。
というか、GitのマージってI/Oバウンドだと思ってるが違うのか？
737(1): デフォルトの名無しさん (ﾜｯﾁｮｲ d9e4-Ojdt) [sage] 2022/11/01(火) 03:55:08.59 ID:kz7RaJ2H0(2/5) AAS
>>735
ただ単純にハッシュアルゴリズムをSHA-1からSHA-256に変更するわけじゃないぞ
既存のSHA-1リポジトリも全部(リベース状態にすることなしに)SHA-256で運用できるようにしたりするんだよ
gitの開発はリポジトリのフォーマットの継続性をとても重視してる
738: デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4) [sage] 2022/11/01(火) 08:06:29.98 ID:Jzc3CN/20(4/8) AAS
>>737
同じだよ。
正しく構成されてる場合は何種類混在しても全く問題ないし、簡単に変更可能だ。
つかマジでそれオブジェクト指向(OOP)の基本中の基本だから。
ただ、混在なら、Cで一般的に使われてるSIZEOFの#defineでは対応出来ないが、
Linusのコードなら、Cでは一般的に禁止されてる小文字マクロで
普通にそこら辺の関数もマクロだらけの可能性があり、(linuxカーネルコードがそう）
この場合は、#define内のマクロ定義を一箇所変更するだけで対応可能ではある。
が、まあ、マクロ云々の話は本来はNGとされてて他言語では厳禁だから、いわゆる正しい方策を示すと、
全体の関数はハッシュの中身が何か知らない状態で記述するんだよ。
get_hash()でハッシュのポインタを貰いました、中身は知りませんので具体的な操作はできません、
なので一々投げ返して操作して貰いますがよろしいですね？とする。
739: デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4) [sage] 2022/11/01(火) 08:06:50.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) [sage] 2022/11/01(火) 08:51:54.94 ID:Jzc3CN/20(6/8) AAS
補足。
分からなければ「OOP 抽象化」でググって色々読んでみてくれ。
死ぬほどでてくるはず。マジで基本中の基本だから。
ハッシュを交換することに手こずるようなら、その『コード』は間違いなく糞だ。(Git自体が糞と言っているわけではない）
ただ、修正すればいいだけ、要は漏れなく上記のようにしてしまえばいいだけではあるが。
正しく構成すれば、Hash変更なんて簡単に出来るし、
そもそもそうなってないコードなんてOOPでは存在を許されてない。
（そうとは書けないように構成されてる。
それを強制的にやらせるシステムの一つがprivateだが、これはこれで間違った使われ方も多いが）
741(1): デフォルトの名無しさん (ﾜｯﾁｮｲ d9e4-Xmag) [sage] 2022/11/01(火) 09:16:06.92 ID:kz7RaJ2H0(3/5) AAS
長々とご苦労さんだがお前SHA-256対応の意味が理解できてないよ
742(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4) [sage] 2022/11/01(火) 09:26:52.60 ID:Jzc3CN/20(7/8) AAS
>>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を示されていきなり意義を理解出来る奴はほぼ居ないのも事実。
でも、君は確実に老害扱いされてると思うよ。
743: デフォルトの名無しさん (ﾜｯﾁｮｲ f15f-iYvO) [sage] 2022/11/01(火) 09:32:09.77 ID:WFTKMpG40(1) AAS
なんだか知らんけど5chでうだうだ言ってて何になるの
744(1): デフォルトの名無しさん (ﾜｯﾁｮｲ d9e4-Xmag) [sage] 2022/11/01(火) 09:36:58.90 ID:kz7RaJ2H0(4/5) AAS
>>742
君はその記事の意味することを理解できてないね
コミットオブジェクトの構造とか役目を理解出来てないと難しいかもしれない
745(2): デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4) [sage] 2022/11/01(火) 09:57:34.79 ID:Jzc3CN/20(8/8) AAS
>>744
そう思いたいんだろうけど、残念ながらそうじゃない。
少なくとも君はソフトウェア階層やOOPの基本事項について全く理解出来てない。
だから今、老害と言われ続けるか、再び学び直して熟練者と言われるかの分水嶺にいるだけ。
俺は君に何も強制することは出来ないが。
確かに俺はGit初心者なので、記事の理解は間違ってるかもしれない。
でも、ハッシュの中身や長さが変わったり混在したところで、
正しく構成されてるソフトウェアなら数行の変更で対応可能なのは事実だよ。
そして君と同様の人達によってGitが作られているのであれば、
そりゃそうなってなくて苦労するんだろうさ。
まあいいけどね。もう水掛け論だから終わりにしようぜ。これ以上やってもお互い得る物もないし。
746: デフォルトの名無しさん (ﾜｯﾁｮｲ 8b8f-5UCg) [sage] 2022/11/01(火) 10:12:34.67 ID:ju8ytuSJ0(2/2) AAS
> GITは、すべてのファイルオブジェクトとコミットの識別と整合性チェックをSHA-1に強く依存しています
こう書いてあるのになんで無視するんだろう
747(1): デフォルトの名無しさん (ﾜｯﾁｮｲ d9e4-Xmag) [sage] 2022/11/01(火) 10:29:09.24 ID:kz7RaJ2H0(5/5) AAS
>>745
数行で対応ｗ
それが出来ないgithubは無能集団なんですねｗ
糞MSに買われちゃうぐらいだから仕方ないか
748: デフォルトの名無しさん (ｵｯﾍﾟｹ Src5-8VyY) [sage] 2022/11/01(火) 12:34:56.06 ID:lDKItQe4r(1) AAS
Git初心者に語らせると頓珍漢な文章が生まれるという好例
749(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 8bbb-VzUj) [sage] 2022/11/01(火) 12:39:40.93 ID:QdibabTL0(2/2) AAS
>>745
お前日本語読めなさそうだな
ましてやリンク先にある英語とかかけらも理解できてないだろ
混在とかじゃないぞ。二つを同時につけて「安全」に相互変換するということだぞ
安全にすることが目的でSHA-256を使えば解決みたいな話じゃない
お前みたいなのが目的と手段を取り違えるタイプの典型
OOPとかアホなプログラマでも理解できる単純なことなわけないだろ
そんなんで済むならとっくに終わってる
まずは常識で考えろ
できないなら黙って勉強しろ
750: デフォルトの名無しさん (ﾜｯﾁｮｲ 699f-1Eu/) [sage] 2022/11/01(火) 18:29:25.93 ID:/+vO/8+o0(1) AAS
長文すげー
751: デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4) [sage] 2022/11/02(水) 05:40:42.57 ID:n+gr/3CY0(1/2) AAS
>>749
どうであれ同じだよ。
複数付けようが、何をどう組み合わせようが、
抽象化の向こうの実体については知らないし、取り扱うコードも存在してないから、
同じバイナリで動作するんだよ。それが抽象化と隠蔽で、これはOOPの基本中の基本。
752: デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4) [sage] 2022/11/02(水) 05:41:43.29 ID:n+gr/3CY0(2/2) AAS
んー、お前ら完全に化石だわ。若い奴からは確実に馬鹿にされてるよ。
というか、現在において有名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が悪いわけではないし、ストールマンも別になんとも思ってないようだけど。
753: デフォルトの名無しさん (ﾜｯﾁｮｲ c114-Tk+f) [sage] 2022/11/02(水) 06:01:09.34 ID:z+vraLDY0(1/2) AAS
> これは特殊ケースではなく、こうなるように設計するんだよ。
> これに対してGitはマニュアル見てもそういう思想が全く見あたらず、「頑張ればいいよね」で終わってる。
それあなたの感想ですよね？
gitはソースコード1行程度で変更終わりですよ
754: デフォルトの名無しさん (ﾜｯﾁｮｲ c114-Tk+f) [sage] 2022/11/02(水) 06:03:01.35 ID:z+vraLDY0(2/2) AAS
> 実装で一番簡単な方法は、Gitをバックエンドに使ってシェルスクリプトでラップすることだよ。これらは既に言ったが。
シェルスクリプトは移植性低いって分かってる？
シェルスクリプトでラップしようものなら
Linuxでは動くがFreeBSDでは動かないってことが
しょっちゅう発生する
シェルスクリプトで頑張るものじゃない
755(1): デフォルトの名無しさん (ﾜｯﾁｮｲ d9e4-Xmag) [sage] 2022/11/02(水) 07:01:05.57 ID:S2ENS6Jw0(1) AAS
git の一部機能は git コマンドを使ったスクリプトで実装されていたんだけど、多くのユーザーの要望に応える形でそれらのC言語化進めてる
756: デフォルトの名無しさん (JP 0H8d-8VyY) [sage] 2022/11/02(水) 09:34:00.28 ID:33j+wJW8H(1) AAS
シェルでラップw
USPから悪い影響でも受けたか？
757: デフォルトの名無しさん (ﾜｯﾁｮｲ 8bbb-VzUj) [sage] 2022/11/02(水) 10:35:32.50 ID:sFE/M4aa0(1) AAS
OOPなんて初心者プログラマ訓練ギブスってことを理解できなくてアホ理論展開しているやつがいてｗ
758(1): デフォルトの名無しさん (ﾜｯﾁｮｲ fb66-Q7eZ) [sage] 2022/11/02(水) 14:42:23.54 ID:LlnSL/r70(1) AAS
OOPなんか、そん辺のサンデープログラマでもかなり深い所までメリットデメリット含め浸透してるがな。
関数指向やクロージャがある言語も同様で
もはや当たり前のようにハイブリッドになってて一部の原理主義者以外いい塩梅で使ってるから話題にはならん。
759: デフォルトの名無しさん (ｵｯﾍﾟｹ Src5-5UCg) [sage] 2022/11/02(水) 15:33:51.58 ID:4T0OIw/dr(1) AAS
OOPそれほど語るなら、お前の大好きなシェルスクリプトはみんなOOP意識して作られてるのかって感じだな
760: デフォルトの名無しさん (ﾌﾞｰｲﾓ MMdd-ntN1) [sage] 2022/11/02(水) 18:08:31.10 ID:mw55lzgRM(1) AAS
リーナスを中心としたOSSコミュニティの起源にタネンバウムとのモノリシックカーネル・マイクロカーネル論争があることを知らないのかな？
結果として無駄な抽象階層を積み重ねることの無意味さをLinuxカーネルの成功が証明してしまった
もちろんLinuxカーネルもファイルシステムとか必要なとこは抽象化されてるけどね
761: デフォルトの名無しさん (ｶﾞｯｸｼ 06dd-uk66) [] 2022/11/02(水) 18:41:51.51 ID:1AIcQZnX6(1) AAS
今どきの若い奴(というか最新の風潮)ってなんでもかんでもオブジェクト指向を徹底するって感じじゃないと思うけどなあ
それこそオブジェクト指向主義みたいなのが滅茶苦茶強かったのって20年前ぐらいじゃない？
WindowsもNTでマイクロカーネルにしたけどオーバーヘッドデカすぎて一部はカーネル空間に戻したりしたでしょ。
SIerの階層が深い開発なんかだとオブジェクト指向を徹底しないと事故が起こりそうだけど、そういうとこしか知らない人間なのか？
762: デフォルトの名無しさん (ｵｯﾍﾟｹ Src5-8VyY) [sage] 2022/11/02(水) 22:26:03.48 ID:KtYxSAYnr(1) AAS
何でもかんでもシェルでやろうとするやつは病気
名前を呼んではいけないあの開発手法とか推してそう
763(2): デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4) [sage] 2022/11/03(木) 05:47:24.09 ID:AHw2USmo0(1/17) AAS
>>755
それはどのプラットフォームで問題になったの？
賢い選択とは思えないけどね。
具体的なデメリットは既に666で挙げたとおり。
俺はシェルの互換性問題なんて有ったとは思えないけど、
(昔からsh《bsh》は互換性は高かったし、今はその後継のbashで統一されてる。
ああ確かにcsh/tcsh/ksh/zshはゴミだったし死滅したよ)
それが問題なら、GitのC化ではなく、直接シェルの互換性を上げるのが常策だよ。
互換性がC化で達成出来るのなら、
既にあるbash(多分C)ソースをコンパイルしただけのものを同梱し、
gsh(=gitsh)だ！これを使え！と強弁すれば済んだろ。
なんかやっぱり無能の働き者を地で行ってる気はする。
仕事を減らす努力をしてないよね。
764: デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4) [sage] 2022/11/03(木) 05:49:10.00 ID:AHw2USmo0(2/17) AAS
>>758
その通りだ。だからアマチュアの樋口Pも正しく対応出来てた。
だからこそ、このスレのこれまでのやりとりに驚いている。
今時初心者でも、他言語スレでもあり得ない流れだ。
で、パッチ出てきたけど、あれでは駄目だね。
彼等はC流のメモリ管理の方法を知らず、Gitは完全に糞コードで出来てる。
あれでは他にもメモリリークだらけだよ。
(ただこれも想定内っぽいし、
リークしたところでアプリとしては大した問題でもないのも事実だが)
彼等は、バグを直す努力はしているが、
バグが出にくいコードにする努力は全くしてない。
OOPもやりすぎると問題だが、何故彼等はそうするのかを学んで、
美味しいところだけ貰えばいいのにとは思うよ。
OOP原理主義者も、Gitプロジェクトやこのスレ民みたいなOOP排除原理主義者も、同様に問題だよ。
765: デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4) [sage] 2022/11/03(木) 06:07:03.27 ID:AHw2USmo0(3/17) AAS
ただ見る限りGit界隈は密結合主義のようだ。
つまり、Gitと知識的に密結合した、Gitに詳しい奴だけがGitを使うべきであり、
tutorial1が基本コマンドなら普通はtutorial2は応用コマンドのところ、
なんと内部データ構造の紹介になってるし、
(ただこれは俺には極めて有効に作用したが、普通はブーイングの嵐だろう)
766: デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4) [sage] 2022/11/03(木) 06:07:22.90 ID:AHw2USmo0(4/17) AAS
ソースコードも密結合、これは馬鹿除けだ！と言い放つ。
糞コードでもパッチの手数で勝負だ！カリスマLinusならモグラ叩き志願者は無限に募れる！
とまあ、他の誰も出来ないアプローチだね。
ただまあ、ソースコードを清潔に保つ目的は長期的メンテの為であり、
それは実際出来てるしいいだろ、と言われれば、はーそうですねー(棒)だが。
767: デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4) [sage] 2022/11/03(木) 06:07:59.96 ID:AHw2USmo0(5/17) AAS
これ見てたら、buggyな糞コードでもとりあえず動けば受け入れてどんどん改訂し、バグもパッチの手数で勝負するのと、
普通のプロジェクトがやってる、レビューして駄目なコードは最初からrejectするのと、
(つまり手間をかけてもrejectされる可能性があるからコードを投げるのを躊躇される)
どっちが良いのだろう？とは考えさせられるよ。
リソースが無限にあるOSSでは、前者の方がいいのだろうか？
LinusはBillJoyに対して「オープンソースを理解してない」と思ったらしいが、こういう事なのだろうか？
(この発言はLinus著作本にあるらしいが、俺は読めてない)
しかしこのアプローチでは、絶対に浄化はしない。
自分の糞を片づけるのは仕方ないとして、
他人の糞を片づけたがる奴はいないし、そもそもその界隈が掃除に価値を置いてない。
しかし糞コードならどんどん投げてもらえるし、それらを受け入れる限り、進化が止まることもない。
はーなんだかねー。なるほど研究者と色々衝突するのも分かる気はする。
そういや大昔「伽藍とバザール」読んだなーと思って今読み返してみたが、これがバザールなのか？
（NGにかかったので分割した）
768(1): デフォルトの名無しさん (ﾜｯﾁｮｲ d9e4-Ojdt) [sage] 2022/11/03(木) 10:41:57.59 ID:NhDXzDSd0(1/3) AAS
それだけ文句あるなら本家MLで言うか自分で作り直してみろよ軍師様
これだけ大口叩いておいて英語のMLでコミュニケーションとれないとかだったら笑うが
Git は世界中のプログラマが使ってる最重要プロジェクトで、これが改良されるとなれば世界中から絶賛される
769: デフォルトの名無しさん (ﾜｯﾁｮｲ 699f-1Eu/) [sage] 2022/11/03(木) 10:46:51.87 ID:odT0DHDr0(1) AAS
まだやってのか
暇そうだな
770(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4) [sage] 2022/11/03(木) 13:22:38.17 ID:AHw2USmo0(6/17) AAS
>>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%A0%E3%81%A3%E3%81%9F%E3%82%82%E3%81%AE
もあり、顧客自身が実装してるんだから、そりゃ商用VCSでは絶望的に仕様的に太刀打ち出来ない。
そしてソースコード戦略も違う。Gitはコードレビューとか無い世界なんじゃないかな？
それで回るってのがスゲエが、多分これは「伽藍とバザール」の衝撃を追体験しただけなのだろう。
ソースコードを綺麗にしたら、新機能の追加が断然早くはなるけど、それは同じ人数での話で、
ここも手数で勝負だ！と来られたら、為す術もない。
ソースコードなんて糞でいいんだ、人数さえ有れば！では、研究者とは対立するよ。
なるほどエンジニアリングの天才だというのも納得ではある。
だからまあ、Gitを根本的に覆すにはGitよりも良い仕様が必要で、これは本当に難しいんだろうさ。
ところで、やはり俺のワークフローではIndexが邪魔なので削除しようと思うんだけど、
そもそもあれはどう使う為に設計されたものなのだ？
多分Indexの存在が一番直感的でなく、『説明されてないと』間違える所だと思うんだが。
今のところadd直後にcommitしてて、邪魔でしかない状態で使ってる。
771(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 7997-uk66) [] 2022/11/03(木) 13:30:44.47 ID:9oLRzF140(1/4) AAS
index stageなかったら複数ファイルの変更を一度にcommitできないじゃん。コミット粒度の問題から、全部の変更をcommitしたいわけでもないし。
どのcommitを取ってきてもちゃんと動く状態にするのが普通だからどう考えてもいるでしょ。
772: デフォルトの名無しさん (ﾌﾞｰｲﾓ MMeb-ntN1) [sage] 2022/11/03(木) 13:52:50.16 ID:/4IN/B1bM(1) AAS
indexの意味がわかってない馬鹿が全然関係無いファイルをコミットしてリポジトリをブチ壊す
773(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4) [sage] 2022/11/03(木) 14:35:27.11 ID:AHw2USmo0(7/17) AAS
>>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 を真似して上記のようにするつもりだが、何かまずいかな？
774: デフォルトの名無しさん (ﾜｯﾁｮｲ 8b8f-5UCg) [sage] 2022/11/03(木) 14:40:47.35 ID:5PP47Osh0(1/3) AAS
git分からない思想も理解できないならSVN使えば？
775(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 7997-uk66) [] 2022/11/03(木) 14:46:46.91 ID:9oLRzF140(2/4) AAS
>>773
そりゃgitの設計思想で想定されたコミットの仕方をしていないからindex stageがいらないと感じるだけでしょ。
大多数は設計思想通りに使っているので、index stageが必要だと理解していると思うよ。
だから、「どう使うために設計された」かと聞かれれば、gitの思想通りにコミット粒度を適度に保つためだとしか言いようがない。
「俺は違うから俺はいらない」はそれはそうだろうが、だから何？って話になる。
776: デフォルトの名無しさん (ﾌﾞｰｲﾓ MMeb-ntN1) [sage] 2022/11/03(木) 15:04:33.12 ID:jVDh6EB5M(1) AAS
適当なタイミングで時系列に修正を記録していくものだと思ってる阿保には理解できないVCS
777(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4) [sage] 2022/11/03(木) 15:05:56.85 ID:AHw2USmo0(8/17) AAS
>>775
git add -u を複数回して粒度を上げて動くものだけcommitしてもいいのだけど、
俺の場合は10回に1回程度は2-3回前の変更とdiff取った方が見やすいことがあって、
その場合にhash控えておくのが面倒だし、gcされてたらさらに面倒だし、gc切るのもまた邪道だろうしで、
動かないのもcommitしてfeatureの途中は動きませんと割り切るのが一番ましかと思ってる。
まあでもありがとう。
粒度調整の為ならこちらの予想の範囲内ではあった。
778(1): デフォルトの名無しさん (ﾜｯﾁｮｲ a95f-Tk+f) [sage] 2022/11/03(木) 15:26:33.67 ID:O+O1uzzM0(1) AAS
>>777
> その場合にhash控えておくのが面倒だし、gcされてたらさらに面倒だし、gc切るのもまた邪道だろうしで、
N個前との diff は git diff HEAD~N でハッシュを控える必要もないし gc のくだりは何のこと言ってるのかわからない。
> 動かないのもcommitしてfeatureの途中は動きませんと割り切るのが一番ましかと思ってる。
ローカルブランチなら別に構わないけど、そのノリで作られたブランチをそのままレビューするのは効率悪い。
なのでマージ前のブランチをレビュー対象とする開発では push の際に整理することになるから、
都度整理の際にインデックスはとても有用。
他にも、作業中に全然関係ない typo 直したりするのにも使える。
779(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 8bbb-VzUj) [sage] 2022/11/03(木) 15:53:58.77 ID:HnXRQ5rf0(1) AAS
index の重要性が分からないやつが git 語ってて草。
素人向けに説明すると git の役目は他人に読んでもらうやすい分かり易いパッチを仕上げること。
個人で作る分にはそれほど関係ないが共同作業するには他人への分かり易さ、見た目は最重要といっていい。
料理に例えるならフライパンやまな板のまま出すんじゃなくて、皿に盛って食べ易くしてから出すのが基本。
ワークツリーがフライパンで、インデックスが皿。フライパンからでも直接食えるけど、綺麗に皿に盛って、そこで丁寧にチェックしてから提供すれば他人の作業効率が上がる。
780: デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4) [sage] 2022/11/03(木) 16:18:44.28 ID:AHw2USmo0(9/17) AAS
>>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コマンドはスルーだからな)
781(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4) [sage] 2022/11/03(木) 16:20:05.12 ID:AHw2USmo0(10/17) AAS
>>779
いやレビュー対象はcommit済みで、index上ではないだろ。
782: デフォルトの名無しさん (ﾜｯﾁｮｲ 8b8f-5UCg) [sage] 2022/11/03(木) 16:22:38.83 ID:5PP47Osh0(2/3) AAS
うんうんわかった
大人しくSVN使え
その方が君には向いている
783: デフォルトの名無しさん (ﾜｯﾁｮｲ d9e4-Ojdt) [sage] 2022/11/03(木) 17:18:17.27 ID:NhDXzDSd0(2/3) AAS
>>781
779はindex上でレビューするんじゃなくて、indexにいれた状態にしてからdiff --cachedでcommit前の確認をするってことじゃない？自分もそれやるよ
784(2): デフォルトの名無しさん (ﾜｯﾁｮｲ 8b14-Tk+f) [sage] 2022/11/03(木) 17:50:52.37 ID:e1pojM/n0(1/8) AAS
>>763
> (昔からsh《bsh》は互換性は高かったし、今はその後継のbashで統一されてる。
> ああ確かにcsh/tcsh/ksh/zshはゴミだったし死滅したよ)
FreeBSDにはbash入っとらんぞ
785: デフォルトの名無しさん (ﾜｯﾁｮｲ 8b14-Tk+f) [sage] 2022/11/03(木) 17:52:28.68 ID:e1pojM/n0(2/8) AAS
>>763
> 既にあるbash(多分C)ソースをコンパイルしただけのものを同梱し、
> gsh(=gitsh)だ！これを使え！と強弁すれば済んだろ。
bashだけじゃ足らんだろ
GNUコマンドも全部入れなきゃな！
786: デフォルトの名無しさん (ﾜｯﾁｮｲ 8b14-Tk+f) [sage] 2022/11/03(木) 17:53:10.48 ID:e1pojM/n0(3/8) AAS
>>770
> 仮に時間が十分にあったとしても、俺が改善出来るのはソースコードであって、アプリではない。
だからソースコードを改善しろってｗ
787(1): デフォルトの名無しさん (ﾌﾞｰｲﾓ MMeb-ntN1) [sage] 2022/11/03(木) 18:10:35.38 ID:3fLLADP3M(1) AAS
>>784
macもbsahやめたんだよね
GPLから逃げるために
788(3): デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4) [sage] 2022/11/03(木) 19:01:05.13 ID:AHw2USmo0(11/17) AAS
あと実は、masterの意義も分からないのだが。俺の場合は、
master: 今現在Web上で公開しているもの
develop: 今現在ローカル上でテストしているもの
feature: 今現在変更中のソースコード
と3つポインタが必要なのは分かる。
しかし、masterは常にdevelopとfast-forwardマージするなら、developにタグ打てば済む。
途中からのbranchも可能だし、hotfixするにしても問題ない。
branchケチる意味もないのも分かるが、それにしても無駄に多い気もする。
と思ってたら、俺にはサル先生方式位が適切な気がしてきた。
> ここでは統合ブランチとトピックブランチという二種類のブランチを使った運用方法について紹介します。
> https://backlog.com/ja/git-tutorial/stepup/02/
サル先生方式の統合ブランチにタグ打つだけと比べて、
masterとdevelopとして別に持っておいたら何が嬉しいの？
789(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4) [sage] 2022/11/03(木) 19:03:24.24 ID:AHw2USmo0(12/17) AAS
>>784
>>787
政治的案件をOSS側がフォローする必要ないと思うが…
790(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 8b14-Tk+f) [sage] 2022/11/03(木) 20:29:42.55 ID:e1pojM/n0(4/8) AAS
>>789
なに政治的案件の話にすり替えようとしてるんだよ
gitは環境依存が激しいシェルスクリプトに依存しないように
C言語で書いてるって話をしていただろ
791(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 8b14-Tk+f) [sage] 2022/11/03(木) 20:33:17.75 ID:e1pojM/n0(5/8) AAS
>>788
1系、2系の同時開発とかあるやろ
792(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 7933-Tk+f) [] 2022/11/03(木) 20:41:00.73 ID:vXMSDhes0(1/2) AAS
.gitignoreの書き方で質問
app.log, app.log.1, app.log.2みたいな感じで増えていくログファイルを無視したいのですがどう書けばいいですか？
793: デフォルトの名無しさん (ﾜｯﾁｮｲ 8b8f-5UCg) [sage] 2022/11/03(木) 20:41:54.93 ID:5PP47Osh0(3/3) AAS
>>788
なんだやっぱりブランチのことすら分かってなかったのか
794(1): デフォルトの名無しさん (ｶﾞｯｸｼ 06eb-lAaw) [sage] 2022/11/03(木) 20:48:29.66 ID:5fumPTTR6(1) AAS
>>792
*.log* でなにか被ったりする？
795: 792 (ﾜｯﾁｮｲ 7933-Tk+f) [] 2022/11/03(木) 20:58:19.76 ID:vXMSDhes0(2/2) AAS
logフォルダ作ってそれを無視することにしました
>>794
ごめんなさい！
796(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4) [sage] 2022/11/03(木) 21:00:04.22 ID:AHw2USmo0(13/17) AAS
>>791
あ、なるほど了解。
逆に言えば、同時開発する気がなければ要らないわけだな。
797(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 8b14-Tk+f) [sage] 2022/11/03(木) 21:04:46.26 ID:e1pojM/n0(6/8) AAS
>>796
今自分で「必要だ」って言ったってこと理解してるかい？
798(2): デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4) [sage] 2022/11/03(木) 21:15:11.85 ID:AHw2USmo0(14/17) AAS
>>790
C化しただけで環境依存が無くなるのなら、既にC化されてるbashでいいだろ。
Cコード上で何か小細工が必要なら、それは「互換性を上げる」名分でbashにcontributeすべきで、
Git側で吸収する案件ではない。
GPLから逃れたいってのも意味が分からん。
bashのコードを改変して新機能追加してmac_bachにしたら、そのコードを公開しないといけないが、
普通にbashを使って作業するだけなら関係ないから使えばいいだけ。
何か思惑有るんだろうけど、Gitがソースを汚してまでフォローする案件じゃないだろ。
> また、これ以外にも zsh や bash などのシェルが FreeBSD Ports Collection から利用可能です。
> https://docs.freebsd.org/ja/books/handbook/basics/
自分でインストールしろよ。
799(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 8b14-Tk+f) [sage] 2022/11/03(木) 21:16:20.05 ID:e1pojM/n0(7/8) AAS
だからなんでgit使うだけで
bash＋たくさんコマンド入れなきゃならんのだよ
800(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4) [sage] 2022/11/03(木) 21:22:26.35 ID:AHw2USmo0(15/17) AAS
>>797
必要なのはポインタであってブランチではないんだ。
というか、俺にとってはその時のスナップショットが復元出来れば何だっていいんだよ。
fast-forwardでは履歴が辿れないからrebaseで、みたいな話もあるからもうちょっと確認必要だが、
git flow は手動ではなくインストールして使え、そうすれば全部やってくれる、としてるところばかりで、
どうもmergeの時に色々判断して小細工してるようだが、何やってるのか書いてないから分からないんだ。
まあでも色々他の簡単なのもあるみたいだし、初心者だから出来るだけ単純なのにするよ。
801(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4) [sage] 2022/11/03(木) 21:25:51.42 ID:AHw2USmo0(16/17) AAS
>>799
逆に一体どんな環境でやってるのさ？
普通のunixコマンド一式すら入ってないのか？
そもそもGitなんてPCかそれに近い環境で動けば良くて、それ以外は考慮する必要ない気がするが。
802(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 8b14-Tk+f) [sage] 2022/11/03(木) 21:29:12.32 ID:e1pojM/n0(8/8) AAS
>>800
今話をしているのはお前が言ったこと
> 逆に言えば、同時開発する気がなければ要らないわけだな。
if (同時に開発する気がある) {
いる
} else {
いらない
}
自分で同時に開発する気があればいるって言っただろ自分で
803: デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4) [sage] 2022/11/03(木) 21:39:01.44 ID:AHw2USmo0(17/17) AAS
>>802
ん？どこを誤解されてるのかは分からんが、
俺は複数バージョンを同時開発する気はない。
ただ、リリース後にバグが発覚するする事はあるので、hotfixはする。
804: デフォルトの名無しさん (ﾜｯﾁｮｲ 7997-uk66) [] 2022/11/03(木) 23:10:44.38 ID:9oLRzF140(3/4) AAS
>>801
普通にSourceTreeとかでコマンド一杯を前提としているとは思えないが。
805(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 7997-uk66) [] 2022/11/03(木) 23:14:43.83 ID:9oLRzF140(4/4) AAS
>>788
少なくともCIで回すときは楽だろ。
Git初心者で視野狭すぎなのに、その視野の狭さを無視して「合理的に考えてこれが不要」ってのがあんたのスタイルのようだけど、
そうやってわざわざ視野の狭さから来る「不要」の主張をして反感を買ったレスで学びたいのか？
勉強したいなら、炎上スタイルは目障りなんでよしてほしいな。二言ぐらい余計なんだよ。
806(1): デフォルトの名無しさん (ﾜｯﾁｮｲ d9e4-Ojdt) [sage] 2022/11/03(木) 23:20:07.30 ID:NhDXzDSd0(3/3) AAS
>>798
以下は簡単に調べただけで、時系列の検証もしてないので、何か間違いあるかもしれない
macOSはbash,gcc,sambaをベースシステムにいれるのをやめた
これらはGPLv2からGPLv3にライセンスが変更されて、GPLv3に追加されたバイナリの取り扱いに関する条項がmacOSのセキュリティポリシーに合わなくなったのがその理由
linusはこのGPLv3の条項に批判的で、gitはGPLv2のままでいく可能性が高い
GPLv3のbashに依存するようgitを作り変えると、インストール方法をちょっと特殊にしないとgitもこのGPLv3の条項の制限をうけることになってしまうので、まあやらないだろうね
他のOSSに依存するとこういうのもあるから気を付けないといけない
807(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 8b8f-5UCg) [sage] 2022/11/04(金) 00:15:00.44 ID:SQ9pznPg0(1/2) AAS
> Cコード上で何か小細工が必要なら、それは「互換性を上げる」名分でbashにcontributeすべきで、
Git側で吸収する案件ではない。
頭おかしい
808(2): デフォルトの名無しさん (ｽｯｯﾌﾟ Sd33-wVCK) [sage] 2022/11/04(金) 00:54:15.51 ID:NvjwOVKTd(1) AAS
まあdevelopはいらないかな
mainブランチで開発すりゃいいよ
リリースブランチが必要なら別途releaseブランチを作ればよいのであって、デフォルトブランチは開発系の先端を指してる方が分かりやすい
809(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 8b14-Tk+f) [sage] 2022/11/04(金) 01:05:42.22 ID:EF7BixRC0(1/9) AAS
>>798
> Cコード上で何か小細工が必要なら、それは「互換性を上げる」名分でbashにcontributeすべきで、
gitの都合でbashに迷惑をかけるな
お前のやりそうなことだな
自分の都合で関係ないやつに迷惑をかける
810: デフォルトの名無しさん (ﾜｯﾁｮｲ 8b14-Tk+f) [sage] 2022/11/04(金) 01:06:39.03 ID:EF7BixRC0(2/9) AAS
>>808
初心者のお前の感想なんかどうでもいいよ
811: デフォルトの名無しさん (ﾜｯﾁｮｲ 1901-FQW+) [] 2022/11/04(金) 02:09:07.55 ID:v1xRwBrw0(1) AAS
GPLに賛同せずにGNU製品を使ってたってことだろね。
結局Linusもタダ乗り爺ってことでしょ。
812: デフォルトの名無しさん (ﾜｯﾁｮｲ 8bbb-VzUj) [sage] 2022/11/04(金) 02:50:33.29 ID:BbpXyzD40(1) AAS
ブランチの名前の付け方や使い方なんてほんとどうでも良い。チーム内で話し合え
git のブランチは全部等価
デフォルトで main / master 作られるけど
これも使いたくなけりゃ使わなくて良いし名前変えても良い
上下前次1-新書関写板覧索設栞歴
あと 190 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.036s