Git 18

[過去ﾛｸﾞ] Git 18 (1002ﾚｽ)
上下前次 1-新

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

938(2): (ﾜｯﾁｮｲ 09e4-chQ5) 2022/11/05(土)23:23 ID:zDjINlW+0(24/26) AAS
>>936
FFマージしたらその情報は消滅するな
--no-ff で全部マージすれば複数親のハッシュをもってるコミットオブジェクトの1番目だけたどればいける
^1 だけみていくね
git log にはそれをやるオプションがあるはず

>>930をそのオプションで表示すればこんな風に表示されるはず

$ git log --graph --branches --oneline --オプション忘れた探せ
* a5aaf72 (HEAD -> master, develop) Merge branch 'feature5' into develop
* 324df68 Merge branch 'feature4' into develop
* 68ed20a Merge branch 'feature3' into develop
* 608e5d7 Merge branch 'feature2' into develop
* 3924eae Merge branch 'feature1' into develop
* 7db4424 Merge branch 'feature0' into develop
* ec041f9 initial

939(2): (ﾜｯﾁｮｲ 09e4-chQ5) 2022/11/05(土)23:26 ID:zDjINlW+0(25/26) AAS
>>937 だとこう表示されるはず
$ git log --graph --branches --oneline --オプション忘れた探せ
* 2fb59f1 (HEAD -> master) Merge branch 'develop'
* 832f464 initial

940: (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/05(土)23:35 ID:646uiMLL0(37/38) AAS
>>938
$ git log --graph --branches --oneline --first-parent
* a5aaf72 (HEAD -> master, develop) Merge branch 'feature5' into develop
* 324df68 Merge branch 'feature4' into develop
* 68ed20a Merge branch 'feature3' into develop
* 608e5d7 Merge branch 'feature2' into develop
* 3924eae Merge branch 'feature1' into develop
* 7db4424 Merge branch 'feature0' into develop
* ec041f9 initial

>>939
$ git log --graph --branches --oneline --first-parent
* 2fb59f1 (HEAD -> master) Merge branch 'develop'
| * 25e1b95 (develop) Merge branch 'feature5' into develop
| * 9bfb8cc Merge branch 'feature4' into develop
| * 02d2308 Merge branch 'feature3' into develop
| * 81e18bb Merge branch 'feature2' into develop
| * 5b57f48 Merge branch 'feature1' into develop
| * 6272da6 Merge branch 'feature0' into develop
|/
* 832f464 initial

941: (ﾜｯﾁｮｲ 09e4-chQ5) 2022/11/05(土)23:41 ID:zDjINlW+0(26/26) AAS
>>939がそう表示されるのは、--no-ff マージの手順が何か普通とちがうからかもしれん
>>939みたいに表示させるマージの手順もあるはずだから工夫してみるんだな

942: (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/05(土)23:41 ID:646uiMLL0(38/38) AAS
>>938
なるほど了解した。
データ側に混ぜ込んでて、保持したければ --no-ff で使えってことか。

そもそも同じハッシュなら同じgitオブジェクトにリンクするようになってるのだし、
(つまり見た目が膨らんでるだけで実際の容量は大して食わない）
--no-ff がデフォのほうがよかった気がするが。

まあとにかく了解した。長々とありがとう。

943(2): (ﾜｯﾁｮｲ 527c-zlm6) 2022/11/06(日)00:38 ID:UPUgwCSv0(1) AAS
FFがデフォじゃなと使いにくい気がするのだがｗ

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履歴は要らない、と考えていることになる。

ただこれは奇妙な実装だ。
カーナビを考えれば分かるが、当たり前だが地図情報とルート情報は別なのだ。混ぜ込むのはあり得ない。
commit履歴が要らないってのは、経路(線)は不問で、目的地(点)に着いてるかどうかだけだ、と言っているわけ。
それはバージョン管理の達人()にとっては、違うんだろ。バージョン管理は「線」であると！
ただ、Linusも「点」の立場だね。まあプログラマ的にはこれで正しいんだよ。
コンピューターは今現在のソースコードしか見てなくて、どの経路を辿ったかなんて関係ない。
だからどういう紆余曲折(「線」)があったかではなく、結局は前回の「点」と今回の「点」のdiffだけが価値を持つ。
そしてLinusの個人的ツールであるGitも、この流れなわけだ。

とはいえ俺はルート情報はまた別に重要だと思うから、保持したい。
混ぜ込まれてる場合は後からbranchを追加することが絶対に出来ない。
まあ開発ツールとしては別経路から同じ点に到達しました！なんてのは現実的にあり得ないから、
偽造を防ぐ為にもこれでいいのかもしれんが、一般的に考えればこの実装は奇妙だ。
ちなみに一般文書、例えばEULA(EndUserLicenseAgreement)とかの隙を潰していくタイプの法務文書等は、
別経路だが最終到達時点は同じ、ということが普通にあり得るはず。
だからやっぱりGitはソースコード向けにしか出来てない、ということは認識しておくべきだろう。

945: (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/06(日)09:32 ID:OfQ8ymDc0(2/24) AAS
あと、Gitのドキュメントは全般的によく出来ているが、branchは「線だ！」と言ってるのは不適切だ。
Gitのドキュメントは密結合状態、つまりGitをよく知ってる人向けに書かれているので、
同様に内部実装を見せる形で書くのが正しく、
つまり、「branchは『線』のように見せてますが、実は『点』です！」と言わないと誤解される。俺がそうだが。
これは解像度が統一されてないから起こった問題だ。
一般のマニュアルは疎結合状態、
つまりそのツールについて内部実装なんて全く知らないし知る由もない人向けに書かれるから、
『見た目』線であれば「線」とずっと言い張り、内部実装を曝露してはいけない。
この場合、あくまでユーザーから見たら常に「線」であり、内部がどうであれ「線」としてしか見えないから誤解を生む余地はない。
Gitの場合は内部も見せた上でドキュメントとして外面仕様も説明することになってて、
それが外面仕様なのか内部実装なのか、
またbranchのように外面仕様と内部実装が異なってて隠蔽しきれてない場合とか、(--no-ffの有無で観測可能)
それは正しく説明しなければならない。
密結合なら、上記の通り、「『線』として見せてますが実は『点』です！」と書くべきだ。
とはいえ全般的にドキュメントはしっかり書かれている。これ自体は素晴らしい。
ただ、そもそも仕様がグダグダ過ぎるし、
或いはユーザーにどこまで見せ、どこからは見せないのか、仕様を管理する感覚がまるでない。
おそらく上層部の連中に仕様管理の経験者がおらず、グダグダになってしまってる。
とはいえ、再度言うが、ドキュメントはよく書いてる方だよ。

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が素晴らしいのは、「伽藍とバザール」での
> 9. 賢いデータ構造と間抜けなコードのほうが、その逆よりずっとまし。
を体現してるからであって、つまり根っこがしっかりしてるから上部は雑草でも問題なかったんだが、
この点は根っこが駄目だから、上部(filter-branch)が機能しない。

ここら辺はちゃんと仕様の大切さを理解してる奴が仕切らないと駄目なのだが、
おそらくGitの連中も、仕様を捏ねてる連中は手を動かしてないと見なし、嫌ってるのだろう。
だから仕様を捏ねることすらしてない。
ただ、それは結局は遠回りでしかない。
今のGitだと、filter-branchも、filter-repoも、その次に出てくる何かも、まともに動作するはずがない。
駄目な仕様だと実装をいくら頑張ってもどうにもならない、と知ってる奴が、ちゃんと仕切らないといけないんだけどね。
ただこれは、それを知らない奴にとってはムカつく奴でしかなく、そいつらを排除した結果、Gitは暴走中、というわけだ。
Linusがcommit履歴も大切に考える奴だったら違ってたが、惜しいね。

947(1): (ﾜｯﾁｮｲ debb-qVfh) 2022/11/06(日)10:57 ID:FBkt/oHG0(1/8) AAS
長々と無駄な長文と大量投稿でスレを穢すんじゃねー。
単に既存のバージョン管理ツールと、git の考え方の違いが理解できてないだけじゃねーか。
・git はパッチ管理ツール、作業履歴管理ツールじゃない。
・ソフトウェアはパッチとパッチを当てる順番で構成されている。
1000回唱えろ。この思想が気に要らなければそもそも git 使うな。

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の使い方は後者だろ。

950(1): (ﾜｯﾁｮｲ 515f-pSqO) 2022/11/06(日)11:33 ID:sj15aRfA0(1/4) AAS
ということにしたいのですね。

951: (ﾜｯﾁｮｲ debb-qVfh) 2022/11/06(日)11:46 ID:FBkt/oHG0(2/8) AAS
>>949
お前の狭い世間なんて知るか
お前は話題の電動ドリル買ってきて釘打つのに不便ガンガンってやりながら文句言ってるのと同じレベル
そもそもマニュアルもちゃんと読めてないだろ。root と route を間違える英語レベル
背伸びして 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にこのサポートが無く、パッチを当てる人はいきなり完成したパッチを書け！勿論でバッグ済みだぞ！みたいな構造なのがおかしい。
すくなくとも、捨てbranch機能があって、そこで日々の作業を終わらせた結果、
mergeするときには本ブランチでその結果がいきなり生えたように見せる機能
(捨てbranchとmergeしても中身の結果だけもらって親にはしない）
みたいな機能が必要なんだよ。
ただまあ、これは今でも手動だと出来た気はするが。

だからまあ、確かにパッチ管理ツールであって、
ソフトウェア開発時のバージョン管理ツールではないんだろうさ。
だけど、今、全世界のGitで、mergeコミットと通常のcommit、どっちが多いか考えれば、自明だろ。
一つのパッチを作るまでにも何回もcommitが必要なのだから。

953(1): (ﾜｯﾁｮｲ debb-qVfh) 2022/11/06(日)12:07 ID:FBkt/oHG0(3/8) AAS
>>952
アホか。共同開発が全く理解できてねーじゃねーか。
お前の試行錯誤の記録を push しようとしてんじゃねーよ。
手元で試行錯誤して実装できたら、それを元に綺麗なパッチに書き直す作業するんだよ。
そして完成した綺麗なパッチ群のみを共有リポジトリに公開するんだよ。

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

955(1): (ﾜｯﾁｮｲ b114-pSqO) 2022/11/06(日)12:20 ID:JyiC8cnE0(1/6) AAS
試行錯誤はすべて記録に残すべき
→じゃあテキストエディタで保存するたびに記録するべきっていうのか？

こういう話なので無視すんなよ？ｗ

956: (ﾜｯﾁｮｲ b114-pSqO) 2022/11/06(日)12:21 ID:JyiC8cnE0(2/6) AAS
バージョン管理はソースコードの変更履歴を残すのであって
作業履歴を残すものじゃないっていうのが分かってなさすぎ

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
> こういう話なので無視すんなよ？ｗ
無視する/しない以前に、何が言いたいのか分からないから反応しようがないんだよ。

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 もある。
だからパッチの分割はすぐ出来るんだよ。

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

あと 35 ﾚｽあります
ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ

ぬこの手ぬこTOP 0.022s