[過去ﾛｸﾞ] Git 18 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
959: (ﾜｯﾁｮｲ 515f-pSqO) 2022/11/06(日)12:42 ID:sj15aRfA0(2/4) AAS
>>957
> それはいいんだけどさ、その肝心のパッチを書く人へのサポートがまるでないだろ。
rebase あるよ。
元のローカルブランチを消さないでおけば記録もぜんぶ残るし。よかったね。
960(1): (ﾜｯﾁｮｲ debb-qVfh) 2022/11/06(日)12:43 ID:FBkt/oHG0(4/8) AAS
>>957
git ほどパッチを書くのに向いてるツールは他にないぞ。
index 無しでどうやってパッチの分割とかするんだよ？
961(2): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)12:53 ID:OfQ8ymDc0(10/24) AAS
>>960
最初から一つずつ書けば分割の必要ないし、
Index無くてもdiffの出力を絞ってpatchに食わせれば普通に分割出来るだろ。
962: (ﾜｯﾁｮｲ b114-pSqO) 2022/11/06(日)13:02 ID:JyiC8cnE0(3/6) AAS
>>958
書いてあるとおりじゃん。
試行錯誤の履歴を全部取れというなら、テキストエディタで保存するごとに
gitでコミットしなければならないはずだ
お前の主張はそういうことなんだから、それをちゃんとやれってこと
963(1): (ﾜｯﾁｮｲ b114-pSqO) 2022/11/06(日)13:04 ID:JyiC8cnE0(4/6) AAS
>>961
コミットがメチャクチャなのに、どうやってdiffとってパッチできると思ってるの？
そのdiffには関係がない修正が大量に入ってるだろ
964(1): (ﾜｯﾁｮｲ debb-qVfh) 2022/11/06(日)13:37 ID:FBkt/oHG0(5/8) AAS
>>961
なんも分かってないことを露呈しているな。
A,B,C,D,Eとコミットした後に Cはc1,c2,c3に分割すべきで、BとEは一つにすべきで、Aは不要だったと気づいたらどうすんの？
こういうのがお手軽にできて綺麗なパッチ群に整理できるのがパッチ管理ツールである git の利点なんだ。
そういうのやったことないだろ？
965(1): (ﾜｯﾁｮｲ 09e4-chQ5) 2022/11/06(日)13:39 ID:az1H5JFk0(1/7) AAS
>>954
脊髄反射で理解したつもりになって書いてるだろ正解率が著しく低い
git worktreeは一つのリポジトリに追加のワークツリーを用意して、異なるブランチをそれぞれ別のワークツリーにcheckoutできるようにする機能
DBのATTACHとは全然違う
マルチルートは普通に作ったリポジトリをfetchやpushで合成してmerge --allow-unrelated-historiesすればできる
でもこれはかなり特殊な用途に使うもので普段使いするようなものではない
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 もある。
だからパッチの分割はすぐ出来るんだよ。
968(1): (ﾜｯﾁｮｲ 09e4-chQ5) 2022/11/06(日)14:05 ID:az1H5JFk0(2/7) AAS
>>967
そういう作業を必要で無くすためにgitが生まれた
patchの提出をgitの分散リポジトリ上で可能とするためにね
963とか964が行ってるpatchというのは、いわゆるpatchファイルのことではなく、ブランチ上に存在する差分の事
そのpatchを整理するのに index や rebase がある
969(1): (ﾜｯﾁｮｲ debb-qVfh) 2022/11/06(日)14:19 ID:FBkt/oHG0(6/8) AAS
もしかして、もしかすると、git では「パッチ＝コミット」っていうことすら理解できてないのだろうか。
まさかそんな人はいないよね。単に言動が変な人なだけだよね。
970(1): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)14:25 ID:OfQ8ymDc0(13/24) AAS
>>968
知ってるよ。
ただまあ、確かにパッチ管理ツールだ。
プログラマはこれをソースコード管理ツールとして使おうとするから問題なのだろう。
バックアップが取れて、履歴が戻れれば何でもいいんだが、mergeも出来るから便利だからね。
なお俺は
> ブランチ上に存在する差分の事
も所詮はdiffだ、という立場だよ。だから元のunixコマンドで何とでもなるし、
それをシェルスクリプトで集大成したのが初期Gitだろ。
971(1): (ﾜｯﾁｮｲ debb-qVfh) 2022/11/06(日)14:31 ID:FBkt/oHG0(7/8) AAS
>>970
ちがうぞ。最初からパッチ管理ツールとして設計されるぞ。
そしてパッチ管理ツールなんだから、パッチの出力機能さえあれば良いんだぞ。
それ以外の差分が欲しかったら別の外部ツール使えば良いんだぞ。それこそ基本だろ
972(1): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)14:33 ID:OfQ8ymDc0(14/24) AAS
>>969
各commmit「点」でdiff取ったときに落ちる情報って何？
ああcommitメッセージか？そんなのは知らんし要らんよ、って立場。
つか、commitメッセージガーなんて言い訳にならないから、
どのみちソースコードを確認するしかないんだよ。
commitメッセージはその手がかりとラベルに過ぎない。これが俺、というか多分普通のプログラマの立場。
お前らはcommitメッセージが間違ってたら、そいつに責任を負わせられるんだろうさ。
ソースコード読めないからね。
ソースコード読める奴ならこんな言い訳効かないんだよ、何でお前が上にいるんだ！監督する為だろ！になる。
さすがに素通しはヤバい。
そしてどう見てもヤバいパッチを素通ししてるから、なんじゃあこりゃあ？ってなってる。
973: (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)14:36 ID:OfQ8ymDc0(15/24) AAS
>>971
ああそれが diff のデフォルト出力をさせない理由だな。
651から一周回ったが、なるほど色々状況は理解出来たよ。賛同はしないが。
974(2): (ﾜｯﾁｮｲ debb-qVfh) 2022/11/06(日)14:45 ID:FBkt/oHG0(8/8) AAS
>>972
だからお前の考えてるような作業履歴管理ツールじゃないんだから、あきらめて他所へ行け。
gitはパッチ管理ツール。そしてパッチは何時、誰が、何のために作成したかが重要情報なんだよ。それを管理してるんだよ。
ソースコードの保管するツールじゃねーぞ。
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
だからな、前言ったように、ブッ込んでおけば後で取り出せるバケツでしかないんだよ。
そのバケツにゴテゴテ付いてるから難しそうだが、要らない機能は使わなければいいだけ。
ただ、履歴保持の範囲を知らずに使って、実は記録されていませんでは困るから、使う前に調べてる。
977(2): (ﾜｯﾁｮｲ 515f-nsye) 2022/11/06(日)15:45 ID:o7v4FvnP0(1) AAS
外部ﾘﾝｸ:www.praha-inc.com
そもそもコミットメッセージは何のためにあるのでしょうか？
コミットログのうちコードの変更履歴には「コードをどのように変更したか」という情報が含まれていますが、「コードを何故変更したのか」という情報はコミットメッセージを読まないと分かりません。機能追加、バグ修正、パフォーマンスのためなど、変更した理由は様々なものが考えられます。
もちろんコードを変更した本人に聞けば変更した意図はわかると思いますが、変更した本人にいつでも聞ける状況であるとは限りません。
「何故コードを変更したのか」という情報が欲しい時のためにコミットメッセージが存在します。
加えて、コミットメッセージは基本的に他人が読むものです。
他人というと同僚やコントリビューターなどが挙げられると思いますが、この「他人」には未来の自分も含んでいます。自分が書いたコミットメッセージを数ヶ月先の自分が読む場合、過去の自分のコミットメッセージを未来の自分が読むことになります。
つまり、コミットメッセージは自分以外の人のために存在するのです。
978: (ﾜｯﾁｮｲ 09e4-chQ5) 2022/11/06(日)15:52 ID:az1H5JFk0(3/7) AAS
まあこいつは分散バージョン管理の難しさを理解できていない
一人でしかプログラム組んだことがないのだろう
gitのややこしいと感じる仕様のほとんどは分散リポジトリ管理に起因していて、分散リポジトリ管理の問題をできるだけ明示的にシンプルに解決しようという意図で設計されている
979: (ﾜｯﾁｮｲ b114-pSqO) 2022/11/06(日)15:55 ID:JyiC8cnE0(5/6) AAS
ほんとなぁ、POSIX原理主義だからユニケージだかUSP研究所だかしらんが
例のあいつも、バージョン管理のツールを、バックアップツールとしてしか考えてねぇ
だからとりあえずファイルを入れておけば差分はdiffで見れるだろとか
訳のわからんことを言い出す
ある時点とある時点の差を見たいんじゃねーんだよ
ある修正にどのような差分があるかを記録＝コミットしたいわけで
その記録なしに差分だけみれても役に立たないっつーの
そこが根本的に違うというか、バージョン管理の役目がわかってない
980: (ﾜｯﾁｮｲ 09e4-chQ5) 2022/11/06(日)16:10 ID:az1H5JFk0(4/7) AAS
「ブッ込んでおけば後で取り出せるバケツ」など言っているが、
必要とされていたのは内容を同期できる複数のバケツで、
なおかつバケツ同士が常にオンラインで通信しているわけではない
そういう問題に取り組んだ結果だ
981: (ﾜｯﾁｮｲ 09e4-chQ5) 2022/11/06(日)16:12 ID:az1H5JFk0(5/7) AAS
そういう魔法のバケツを生み出すために、ただのバケツならできることがgitでは制限されていたりもする
ユーザから見て不自由のない完全な魔法のバケツを生み出そうとしたプロジェクトは複雑すぎてことごとく失敗してきた
982: (ﾜｯﾁｮｲ b114-pSqO) 2022/11/06(日)16:14 ID:JyiC8cnE0(6/6) AAS
バケツの中に入っている袋詰めの塩や砂糖を、一つづつ取り出したいのであって
バケツの中に全部入ってるから、遠心分離機でも使って
取り出せばいいだろうじゃないんだよなｗ
983: (ﾜｯﾁｮｲ 09e4-chQ5) 2022/11/06(日)16:36 ID:az1H5JFk0(6/7) AAS
前スレは消費に1年半かかってるのに、このスレは半年ぐらいで終わりだな
次スレ立ててみるけど失敗したらゴメン
984: (ﾜｯﾁｮｲ 09e4-chQ5) 2022/11/06(日)16:41 ID:az1H5JFk0(7/7) AAS
次スレ
Git 19
2chｽﾚ:tech
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メッセージを書いたところで、「それ、あなたの感想ですよね？」でしかない。
肝心なところを書き間違ってるかもしれないし、信用も出来ない。
この点、再現コードは情報が完全で、全ての情報を過不足無く含んでいて、曖昧さもない。
だからcommitメッセージの情報価値なんて再現コードと比べたらゴミ以下で、
再現コードに対してのリンクで十分なんだよ。つまり、
○年○月○日に○○から送られてきた○○のバグ(メモリリーク)を修正する。
詳細はXXXX
で、XXXXのところ、Git流ならSHA1ハッシュで、
その中に再現コードと詳細、今回なら全員のメールの全文を入れておくのがバグ管理だよ。
これで、「何故この変更を行ったのか」の完全情報が保たれる。
そして、再現コードは今後ずっとregressionテストに使う資産にする。
そうすれば、少なくとも過去と同じバグはリリース前に見つかる。
987: (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)19:20 ID:OfQ8ymDc0(20/24) AAS
こうなってないだろ。一回パッチ当てて動きました！満足です！じゃないんだよ。
繰り返すが、commitメッセジーをいくら丁寧に書いても意味無い。
再現コードに比べたら本当にゴミ以下。
逆に、再現コードに辿り着けるのなら、後はラベルが正しく付いてれば十分なんだ。
それ以上の情報は、commitメッセージのテキストではなく、
再現コードとバグ報告＝完全情報を見た方がいいから。
で、GitHubはまあこれに近いよ。
そもそもバグ報告自体Webだし、少なくともIssueからバグの完全情報に当たれる。
Gitはどうなの？
今回の俺と同様の、過去のバグ報告の再現コードを生かせてるのか？
ならそういうディレクトリがあって、
bug_patches/XXXXXなハッシュが名前になってるディレクトリに再現コードその他がブチ込まれてて、
出荷前(というのもおかしいが)には全部一通り通せ、となってるはずだけど、
どう見てもそうなってないでしょ。
パッチ当てたから満足です、で終わってる。
こんなのでバグが収束するはずがない。
同じ連中が書いてるのだから、放置したら同レベルのバグを繰り返す。
だから本来は何故こんなバグが発生したのか？からコード構造を見直して、
そもそもそうならないようにするのだけど、そういう学びもないし、(だから基本すら出来てない)
regressionテストのネタにもしないのだから、今後ともバグだらけだよ。
ああ、Gitの達人揃いだから、「記録」は出来てるのだろうよ。だけどそれは「管理」ではない。
ただ、これがバザール流だ！と来るなら、はーそうですかー(棒)だよ。
目も手も数が違うし、俺には何が最適か分からんし。
988(1): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)19:20 ID:OfQ8ymDc0(21/24) AAS
ちなみにchromeの連中は気持ち悪いほどregressionテストしてるぞ。
本来は、ああするべきなんだろうよ。
regressionテスト自体はタダ(スクリプトで自動実行)だからね。
バグ「管理」というのなら、原因を究明して、少なくとも同じバグが出ないようにしないといけない。
それはcommitメッセージをいくら丁寧に詳細に書いても、達成出来るものではない。
分かりやすく言うとな、「体調管理」と言われれば、少なくとも同じ原因で風邪を引かないようにするだろ。
なら、「バグ管理」なら、最低限レビューしてregressionテストしないと駄目だよ。
それはcommitメッセージ云々では出来ない。だからパッチ「適用」「記録」ツール。
上下前次1-新書関写板覧索設栞歴
あと 14 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.013s