Git 18

[過去ﾛｸﾞ] Git 18 (1002ﾚｽ)
上下前次1-新
抽出解除必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞あぼーん

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

944: (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)09:32 ID:OfQ8ymDc0(1/24) AAS
>>943
ffがデフォのメリットって何だ？特にないと思うが。見た目すっきり、か？
ただまあ、デフォだし、サル先生他も特に何も言ってないので、ffでの運用が多数派なのだろう。

--no-ffはcommitオブジェクトが別に作られるだけで、
スナップショットに比べたらゴミなので全体としては大して増えない。
commit履歴はgitオブジェクトツリー内に混ぜ込まれ、完全に保持される。

ffの場合は、commit履歴情報はreflogにしか無いので、branchを削除したら基本的に失われる。
そしてreflogもgc対象なので、Linusはcommit履歴は基本的に保持する必要がないとの立場なのだろう。
また、branchを削除しろといいつつffなのは、その人達もcommit履歴は要らない、と考えていることになる。

ただこれは奇妙な実装だ。
省14

945: (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)09:32 ID:OfQ8ymDc0(2/24) AAS
あと、Gitのドキュメントは全般的によく出来ているが、branchは「線だ！」と言ってるのは不適切だ。
Gitのドキュメントは密結合状態、つまりGitをよく知ってる人向けに書かれているので、
同様に内部実装を見せる形で書くのが正しく、
つまり、「branchは『線』のように見せてますが、実は『点』です！」と言わないと誤解される。俺がそうだが。
これは解像度が統一されてないから起こった問題だ。
一般のマニュアルは疎結合状態、
つまりそのツールについて内部実装なんて全く知らないし知る由もない人向けに書かれるから、
『見た目』線であれば「線」とずっと言い張り、内部実装を曝露してはいけない。
この場合、あくまでユーザーから見たら常に「線」であり、内部がどうであれ「線」としてしか見えないから誤解を生む余地はない。
Gitの場合は内部も見せた上でドキュメントとして外面仕様も説明することになってて、
省9

946: (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)09:33 ID:OfQ8ymDc0(3/24) AAS
ただこれだと、branchを「線」として扱おうとしたら動作が不安定になるわけで、
おそらくfilter-branchが不安定なのはこの辺に起因してる。
そしてドキュメントの何処か(多分showかlog)に、
「これには実はpitfallがあって、マージに遭遇した場合に分岐するから云々」とかいう
(当時の俺にとって)謎の記述が挿入されてたのも納得がいく。
commit履歴を保持してないから確定的動作が出来ないんだよ。
これははっきり言って仕様の欠陥で、commit履歴も完全に保持する仕様だったら自然と回避出来てた。
現仕様では、filter-branchの実装をいくら頑張ったところでどうにもならない。
代わりのfilter-repoも、動作は同様に糞だろうよ。安定して使えるものではないはず。
ここら辺はちょっと惜しいね。Gitが素晴らしいのは、「伽藍とバザール」での
省11

948(1): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)10:59 ID:OfQ8ymDc0(4/24) AAS
>>943
と思ったが、ffじゃないとhashが違うからウザいな。別物扱いだから、一々確認いるし。
オブジェクトツリーはffの方がいい。

ただこれだとcommit履歴が無く、俺的にはまずいので、別に保存したい。
ソースと混ざるとウザイので、可能なら分離したい。
ドキュメントによるとマルチルートも出来るらしいが、これはどうやってやるんだ？
> Each project must have at least one root. A project can also have multiple roots, though that isn’t common (or necessarily a good idea).

949(1): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)11:04 ID:OfQ8ymDc0(5/24) AAS
>>947
> ・git はパッチ管理ツール、作業履歴管理ツールじゃない。
ああ非常に納得出来る。Gitはmerge特化型だ。
確かにそれを日々の業務(非merge)に使おう、というのがフィットしないんだろうよ。

しかし世の中の一般人のGitの使い方は後者だろ。

952(1): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)11:51 ID:OfQ8ymDc0(6/24) AAS
>>950
いや事実だよ。
Linusは確かにmergeしかしないんだろうけど。

だけどその、mergeするパッチを書く奴は、それを一発で書けたわけがないんだ。
何日もかけて、何回も直して、そこに到達してる。
この過程のサポートがGitにはない。
別branchで作業してもmerge時にhash値が組み込まれるから、
確かに俺がやろうとしてる「日々の進捗」をcommitされると除去出来ずウザイんだろうさ。
しかしパッチのコードは必ずGit-repoをクローンしてから出発するのだから、
Gitにこのサポートが無く、パッチを当てる人はいきなり完成したパッチを書け！勿論でバッグ済みだぞ！みたいな構造なのがおかしい。
省9

954(1): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)12:19 ID:OfQ8ymDc0(7/24) AAS
>>948
一応見つけた。 git worktree らしい。
複数のbranchを同時に開く機能で、DBで言うATTACHっぽい。

957(2): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)12:30 ID:OfQ8ymDc0(8/24) AAS
>>953
それはいいんだけどさ、その肝心のパッチを書く人へのサポートがまるでないだろ。
出発点がgit clone で、その上で作業して、終われば pull request する前提なのにさ。

そしてOSSではなく一般企業等で使ってる奴は、
当たり前だが日々の作業のバックアップや巻き戻し出来るシステムが必要で、そう使ってる。
だから、Gitが難しすぎるというのは、目的外使用だから意味が分かりにくい、というのはあるね。
Indexもマージの時にはあった方が便利なんだろうしさ。(ただのcommitには邪魔でしかない）

しかし確かに、Linusに言わせれば、全く問題ないんだろうさ。彼はmergeしかしないしね。
そして他のVCSよりまし、という理由でGitを使う奴は、混乱するんだろうさ。VCSと聞いてきたのだからね。
確かにパッチ管理システムだよGitは。ソースコード生成時のサポートシステムではない。

958(1): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)12:32 ID:OfQ8ymDc0(9/24) AAS
>>955
> こういう話なので無視すんなよ？ｗ
無視する/しない以前に、何が言いたいのか分からないから反応しようがないんだよ。

961(2): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)12:53 ID:OfQ8ymDc0(10/24) AAS
>>960
最初から一つずつ書けば分割の必要ないし、
Index無くてもdiffの出力を絞ってpatchに食わせれば普通に分割出来るだろ。

966: (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)13:46 ID:OfQ8ymDc0(11/24) AAS
>>965
実は今し方ドキュメント読んで、これは違うと書こうとしたところだった。
wor,ktreeはstashの代わりで、同時作業用ではないね。

> マルチルートは普通に作ったリポジトリをfetchやpushで合成して
ああこれは俺の要求とは違うね。

まあ、もう地味に.git/.xxx/に転がそうと思案中。

967(1): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)13:57 ID:OfQ8ymDc0(12/24) AAS
>>963,964
お前らunixコマンドの使い方知らないだろ。
patch/merge/diff3はgit以前からあるコマンドで、多分初期Gitはそのまま使ってたと思うが。

具体的な使い方は以下。
今、元 fileA に対して、変更後 fileC になってるが、実は中間の fileB が欲しかったとする。このとき、

cp fileA fileB
diff fileA fileC | less -N; // ここで該当行を確認する。例えば10-20行目なら、
diff fileA fileC | sed -n '10,20 p' | patch fileB

これでfileBが得られるんだよ。これ以上色々複雑な時用に diff3 とか merge もある。
だからパッチの分割はすぐ出来るんだよ。

970(1): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)14:25 ID:OfQ8ymDc0(13/24) AAS
>>968
知ってるよ。

ただまあ、確かにパッチ管理ツールだ。
プログラマはこれをソースコード管理ツールとして使おうとするから問題なのだろう。
バックアップが取れて、履歴が戻れれば何でもいいんだが、mergeも出来るから便利だからね。

なお俺は
> ブランチ上に存在する差分の事
も所詮はdiffだ、という立場だよ。だから元のunixコマンドで何とでもなるし、
それをシェルスクリプトで集大成したのが初期Gitだろ。

972(1): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)14:33 ID:OfQ8ymDc0(14/24) AAS
>>969
各commmit「点」でdiff取ったときに落ちる情報って何？
ああcommitメッセージか？そんなのは知らんし要らんよ、って立場。

つか、commitメッセージガーなんて言い訳にならないから、
どのみちソースコードを確認するしかないんだよ。
commitメッセージはその手がかりとラベルに過ぎない。これが俺、というか多分普通のプログラマの立場。
お前らはcommitメッセージが間違ってたら、そいつに責任を負わせられるんだろうさ。
ソースコード読めないからね。

ソースコード読める奴ならこんな言い訳効かないんだよ、何でお前が上にいるんだ！監督する為だろ！になる。
さすがに素通しはヤバい。
省1

973: (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)14:36 ID:OfQ8ymDc0(15/24) AAS
>>971
ああそれが diff のデフォルト出力をさせない理由だな。
651から一周回ったが、なるほど色々状況は理解出来たよ。賛同はしないが。

975: (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)14:49 ID:OfQ8ymDc0(16/24) AAS
>>974
そこは違うんだな。
みんな結局自分でやるのも作るのも面倒だから、既に動いてるツールを使ってるだけだよ。
Gitの機能のサブセットで十分にカバー出来るのなら、Git使えばいいだけ。

976: (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)14:56 ID:OfQ8ymDc0(17/24) AAS
>>974
だからな、前言ったように、ブッ込んでおけば後で取り出せるバケツでしかないんだよ。
そのバケツにゴテゴテ付いてるから難しそうだが、要らない機能は使わなければいいだけ。
ただ、履歴保持の範囲を知らずに使って、実は記録されていませんでは困るから、使う前に調べてる。

985(1): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)19:18 ID:OfQ8ymDc0(18/24) AAS
相変わらずお前ら盛大に勘違いしてるが、とりあえず、

× Gitはパッチ管理ツールである
○ Gitはパッチ適用ツールである
○ Gitはパッチ記録ツールである

としよう。管理は出来てない。何を管理すべきか分かってないから。
commitメッセージなんてただのラベルに過ぎない。

986(1): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)19:19 ID:OfQ8ymDc0(19/24) AAS
例えば今回俺が送った再現コード、あれはどこに配置されるのだ？
>>977の通り、「何故この変更を行ったのか」の完全情報がそこにある。
まさか捨てたりしないよな？

バグパッチに於いて、重要な物から順に、

1. そのバグを修正するコード
2. そのバグを再現するコード
：
10000, commitメッセージ

だ。どんなに丁寧にcommitメッセージを書いたところで、「それ、あなたの感想ですよね？」でしかない。
肝心なところを書き間違ってるかもしれないし、信用も出来ない。
省10

987: (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)19:20 ID:OfQ8ymDc0(20/24) AAS
こうなってないだろ。一回パッチ当てて動きました！満足です！じゃないんだよ。
繰り返すが、commitメッセジーをいくら丁寧に書いても意味無い。
再現コードに比べたら本当にゴミ以下。
逆に、再現コードに辿り着けるのなら、後はラベルが正しく付いてれば十分なんだ。
それ以上の情報は、commitメッセージのテキストではなく、
再現コードとバグ報告＝完全情報を見た方がいいから。

で、GitHubはまあこれに近いよ。
そもそもバグ報告自体Webだし、少なくともIssueからバグの完全情報に当たれる。
Gitはどうなの？
今回の俺と同様の、過去のバグ報告の再現コードを生かせてるのか？
省13

988(1): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)19:20 ID:OfQ8ymDc0(21/24) AAS
ちなみにchromeの連中は気持ち悪いほどregressionテストしてるぞ。
本来は、ああするべきなんだろうよ。
regressionテスト自体はタダ(スクリプトで自動実行)だからね。

バグ「管理」というのなら、原因を究明して、少なくとも同じバグが出ないようにしないといけない。
それはcommitメッセージをいくら丁寧に詳細に書いても、達成出来るものではない。

分かりやすく言うとな、「体調管理」と言われれば、少なくとも同じ原因で風邪を引かないようにするだろ。
なら、「バグ管理」なら、最低限レビューしてregressionテストしないと駄目だよ。
それはcommitメッセージ云々では出来ない。だからパッチ「適用」「記録」ツール。

995: (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)20:08 ID:OfQ8ymDc0(22/24) AAS
>>994
それは鯖に置いてるだけだろ。まあそれはそれで十分で、（この意味では最初のMLでも十分)
問題は、

1. .git上、つまりソースコード改変ツリーから簡単に辿れるよう、
commitメッセージにそのリンクは落とされている(落とされる予定）なのか？
そうじゃないと>>977が達成出来ないだろ。
2. そしてregressionテストパターンとして登録され、今後ずっと実行されるのか？
3. そもそも根本の原因はソースコードの程度が酷いことであり、レビューしろよマジで

だよ。
レイヤーの考え方がない奴等ばかりなので通じないかもしれないが、
省6

996(1): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)20:11 ID:OfQ8ymDc0(23/24) AAS
>>994
と思ったがすまん、見落とした。

> 修正コミットのログ

つまりこれ、コミットメッセージそのものなのか？
ちょっと確認したいんだが、どこ見ればいいんだ？GitのGitHubから？

998(1): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)20:38 ID:OfQ8ymDc0(24/24) AAS
>>997
つまりあれがそのままに近い状態で入るのか？
まあそれは見守るとして、本来はちゃんとラベルを付け替えないとまずい。

俺が送った段階では高い確率で「free忘れによるメモリリーク」と推定出来たが、
断定は出来なかったので、単に「メモリ食いすぎ」としてる。
だから、メモリリークだと「断定」出来た人が概略を書き直さないといけない。

が、まあ、これは多分為されるだろう。見守るよ。

> 君もソースコードの質が気になるなら修正を送ってくれていいんだよ。さぁさぁ。
これは本質的に無理だ。多分俺、というか、いわゆるCコードを拒絶すると思うよ。
間違いなく、連中は自己の能力に自信持ってて、傲慢で、言うこと聞かない連中だ。
省11

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

ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ AAｻﾑﾈｲﾙ

ぬこの手ぬこTOP 0.058s