Git 18

[過去ﾛｸﾞ] Git 18 (1002ﾚｽ)
上下前次 1-新
通常表示 512ﾊﾞｲﾄ分割ﾚｽ栞

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

770: デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4) [sage] 2022/11/03(木) 13:22:38.17 ID:AHw2USmo0

>>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してて、邪魔でしかない状態で使ってる。

http://mevius.5ch.net/test/read.cgi/tech/1650651945/770

780: デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4) [sage] 2022/11/03(木) 16:18:44.28 ID:AHw2USmo0

>>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コマンドはスルーだからな)

http://mevius.5ch.net/test/read.cgi/tech/1650651945/780

815: デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4) [sage] 2022/11/04(金) 18:19:31.52 ID:XH5wI1Z90

そして、どうやらGitはブランチローカルという感覚がないらしく？
どのブランチにいても同じ結果が出るのはどうなのよ？---(B)

具体的には、この場合、
masterブランチでは、HEAD~1はinitialを指し、(master上での一つ前)
developブランチでは、HEAD~1はimpl2を指すべき(develop上での一つ前)
だと思うのだが、どこにいてもHEAD~1はimpl4を指してしまう。
つまり、HEAD~Nの探索先はグローバルであり、それは.git/objects下のツリーそのものらしい。

つかね、masterブランチにいた場合、
git diff HEAD~1 HEAD で前回のリリースと今回のリリースの違い
git diff HEAD~2 HEAD で前々回のリリースと今回のリリースの違い
git log ではmasterブランチ上のリリースした物のcommitログだけに絞られて表示
じゃないと実用的な意味がないと思うんだけどさ。
masterにはmergeしかしない運用なら通常は漏れなくタグが打たれ、「点」のアクセスはタグで出来る。
よって残るは「線」のアクセスだが、ブランチは「線」になってない。
実装はよく知らんが、ブランチを切って増えるのは以下の2つで、
.git/refs/heads は先頭「点」、
.git/logs/refs/heads はlogだから、「線」の為の物が無さそう。

本来ブランチはDBで言うINDEXで、CREATE INDEX develop ON git_tree WHERE branch='develop';
みたいなもので、これが「線」だと思うんだけどさ。
実際は「点」なのでHEADしか見えておらず、HEAD~1をブランチによって切り替えられない。
と思うのだが、理解間違ってる？

ここは多分仕様変更した方がいい。(直感的でないし、意味が分からない)
けど今更出来ないだろうから、Gitの仕様の綻びの一つで、next-gitで修正されるべき案件だろうね。

http://mevius.5ch.net/test/read.cgi/tech/1650651945/815

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

あと 161 ﾚｽあります
ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ AAｻﾑﾈｲﾙ

ぬこの手ぬこTOP 0.018s