Git 18

[表示 : 全て最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2ch.scのread.cgiへ]
Update time : 08/13 17:55 / Filesize : 365 KB / Number-of Response : 1056
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

Git 18

1 名前：デフォルトの名無しさん [2022/04/23(土) 03:25:45.27 ID:HOOXt/T30.net]: ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。

Git - Fast Version Control System
git-scm.com/

◆関連サイト
Pro Git - Table of Contents
git-scm.com/book/ja
Git入門
www8.atwiki.jp/git_jp/

◆前スレ
Git 16©2ch.net
https://mevius.5ch.net/test/read.cgi/tech/1502726047/
Git 17
https://mevius.5ch.net/test/read.cgi/tech/1599016710/
VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured
778 名前：デフォルトの名無しさん mailto:sage [2022/11/01(火) 12:34:56.06 ID:lDKItQe4r.net]: Git初心者に語らせると頓珍漢な文章が生まれるという好例
779 名前：デフォルトの名無しさん mailto:sage [2022/11/01(火) 12:39:40.93 ID:QdibabTL0.net]: >>745
お前日本語読めなさそうだな
ましてやリンク先にある英語とかかけらも理解できてないだろ
混在とかじゃないぞ。二つを同時につけて「安全」に相互変換するということだぞ
安全にすることが目的でSHA-256を使えば解決みたいな話じゃない
�
780 名前：ｨ前みたいなのが目的と手段を取り違えるタイプの典型 OOPとかアホなプログラマでも理解できる単純なことなわけないだろ そんなんで済むならとっくに終わってる まずは常識で考えろ できないなら黙って勉強しろ []: [ここ壊れてます]
781 名前：デフォルトの名無しさん mailto:sage [2022/11/01(火) 18:29:25.93 ID:/+vO/8+o0.net]: 長文すげー
782 名前：デフォルトの名無しさん mailto:sage [2022/11/02(水) 05:40:42.57 ID:n+gr/3CY0.net]: >>749
どうであれ同じだよ。

複数付けようが、何をどう組み合わせようが、
抽象化の向こうの実体については知らないし、取り扱うコードも存在してないから、
同じバイナリで動作するんだよ。それが抽象化と隠蔽で、これはOOPの基本中の基本。
783 名前：デフォルトの名無しさん mailto:sage [2022/11/02(水) 05:41:43.29 ID:n+gr/3CY0.net]: んー、お前ら完全に化石だわ。若い奴からは確実に馬鹿にされてるよ。
というか、現在において有名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が悪いわけではないし、ストールマンも別になんとも思ってないようだけど。
784 名前：デフォルトの名無しさん mailto:sage [2022/11/02(水) 06:01:09.34 ID:z+vraLDY0.net]: > これは特殊ケースではなく、こうなるように設計するんだよ。
> これに対してGitはマニュアル見てもそういう思想が全く見あたらず、「頑張ればいいよね」で終わってる。

それあなたの感想ですよね？
gitはソースコード1行程度で変更終わりですよ
785 名前：デフォルトの名無しさん mailto:sage [2022/11/02(水) 06:03:01.35 ID:z+vraLDY0.net]: > 実装で一番簡単な方法は、Gitをバックエンドに使ってシェルスクリプトでラップすることだよ。これらは既に言ったが。

シェルスクリプトは移植性低いって分かってる？
シェルスクリプトでラップしようものなら
Linuxでは動くがFreeBSDでは動かないってことが
しょっちゅう発生する

シェルスクリプトで頑張るものじゃない
786 名前：デフォルトの名無しさん mailto:sage [2022/11/02(水) 07:01:05.57 ID:S2ENS6Jw0.net]: git の一部機能は git コマンドを使ったスクリプトで実装されていたんだけど、多くのユーザーの要望に応える形でそれらのC言語化進めてる
787 名前：デフォルトの名無しさん mailto:sage [2022/11/02(水) 09:34:00.28 ID:33j+wJW8H.net]: シェルでラップw
USPから悪い影響でも受けたか？
788 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 8bbb-VzUj) mailto:sage [2022/11/02(水) 10:35:32.50 ID:sFE/M4aa0.net]: OOPなんて初心者プログラマ訓練ギブスってことを理解できなくてアホ理論展開しているやつがいてｗ
789 名前：デフォルトの名無しさん mailto:sage [2022/11/02(水) 14:42:23.54 ID:LlnSL/r70.net]: OOPなんか、そん辺のサンデープログラマでもかなり深い所までメリットデメリット含め浸透してるがな。
関数指向やクロージャがある言語も同様で
もはや当たり前のようにハイブリッドになってて一部の原理主義者以外いい塩梅で使ってるから話題にはならん。
790 名前：デフォルトの名無しさん mailto:sage [2022/11/02(水) 15:33:51.58 ID:4T0OIw/dr.net]: OOPそれほど語るなら、お前の大好きなシェルスクリプトはみんなOOP意識して作られてるのかって感じだな
791 名前：デフォルトの名無しさん mailto:sage [2022/11/02(水) 18:08:31.10 ID:mw55lzgRM.net]: リーナスを中心としたOSSコミュニティの起源にタネンバウムとのモノリシックカーネル・マイクロカーネル論争があることを知らないのかな？
結果として無駄な抽象階層を積み重ねることの無意味さをLinuxカーネルの成功が証明してしまった
もちろんLinuxカーネルもファイルシステムとか必要なとこは抽象化されてるけどね
792 名前：デフォルトの名無しさん [2022/11/02(水) 18:41:51.51 ID:1AIcQZnX6.net]: 今どきの若い奴(というか最新の風潮)ってなんでもかんでもオブジェクト指向を徹底するって感じじゃないと思うけどなあ
それこそオブジェクト指向主義みたいなのが滅茶苦茶強かったのって20年前ぐらいじゃない？
WindowsもNTでマイクロカーネルにしたけどオーバーヘッドデカすぎて一部はカーネル空間に戻したりしたでしょ。
SIerの階層が深い開発なんかだとオブジェクト指向を徹底しないと事故が起こりそうだけど、そういうとこしか知らない人間なのか？
793 名前：デフォルトの名無しさん mailto:sage [2022/11/02(水) 22:26:03.48 ID:KtYxSAYnr.net]: 何でもかんでもシェルでやろうとするやつは病気
名前を呼んではいけないあの開発手法とか推してそう
794 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 05:47:24.09 ID:AHw2USmo0.net]: >>755
それはどのプラットフォームで問題になったの？
賢い選択とは思えないけどね。
具体的なデメリットは既に666で挙げたとおり。

俺はシェルの互換性問題なんて有ったとは思えないけど、
(昔からsh《bsh》は互換性は高かったし、今はその後継のbashで統一されてる。
ああ確かにcsh/tcsh/ksh/zshはゴミだったし死滅したよ)
それが問題なら、GitのC化ではなく、直接シェルの互換性を上げるのが常策だよ。
互換性がC化で達成出来るのなら、
既にあるbash(多分C)ソースをコンパイルしただけのものを同梱し、
gsh(=gitsh)だ！これを使え！と強弁すれば済んだろ。

なんかやっぱり無能の働き者を地で行ってる気はする。
仕事を減らす努力をしてないよね。
795 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 05:49:10.00 ID:AHw2USmo0.net]: >>758
その通りだ。だからアマチュアの樋口Pも正しく対応出来てた。
だからこそ、このスレのこれまでのやりとりに驚いている。
今時初心者でも、他言語スレでもあり得ない流れだ。

で、パッチ出てきたけど、あれでは駄目だね。
彼等はC流のメモリ管理の方法を知らず、Gitは完全に糞コードで出来てる。
あれでは他にもメモリリークだらけだよ。
(ただこれも想定内っぽいし、
リークしたところでアプリとしては大した問題でもないのも事実だが)

彼等は、バグを直す努力はしているが、
バグが出にくいコードにする努力は全くしてない。
OOPもやりすぎると問題だが、何故彼等はそうするのかを学んで、
美味しいところだけ貰えばいい�
796 名前：ﾌにとは思うよ。 OOP原理主義者も、Gitプロジェクトやこのスレ民みたいなOOP排除原理主義者も、同様に問題だよ。 []: [ここ壊れてます]
797 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 06:07:03.27 ID:AHw2USmo0.net]: ただ見る限りGit界隈は密結合主義のようだ。
つまり、Gitと知識的に密結合した、Gitに詳しい奴だけがGitを使うべきであり、
tutorial1が基本コマンドなら普通はtutorial2は応用コマンドのところ、
なんと内部データ構造の紹介になってるし、
(ただこれは俺には極めて有効に作用したが、普通はブーイングの嵐だろう)
798 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 06:07:22.90 ID:AHw2USmo0.net]: ソースコードも密結合、これは馬鹿除けだ！と言い放つ。
糞コードでもパッチの手数で勝負だ！カリスマLinusならモグラ叩き志願者は無限に募れる！
とまあ、他の誰も出来ないアプローチだね。
ただまあ、ソースコードを清潔に保つ目的は長期的メンテの為であり、
それは実際出来てるしいいだろ、と言われれば、はーそうですねー(棒)だが。
799 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 06:07:59.96 ID:AHw2USmo0.net]: これ見てたら、buggyな糞コードでもとりあえず動けば受け入れてどんどん改訂し、バグもパッチの手数で勝負するのと、
普通のプロジェクトがやってる、レビューして駄目なコードは最初からrejectするのと、
(つまり手間をかけてもrejectされる可能性があるからコードを投げるのを躊躇される)
どっちが良いのだろう？とは考えさせられるよ。
リソースが無限にあるOSSでは、前者の方がいいのだろうか？
LinusはBillJoyに対して「オープンソースを理解してない」と思ったらしいが、こういう事なのだろうか？
(この発言はLinus著作本にあるらしいが、俺は読めてない)

しかしこのアプローチでは、絶対に浄化はしない。
自分の糞を片づけるのは仕方ないとして、
他人の糞を片づけたがる奴はいないし、そもそもその界隈が掃除に価値を置いてない。
しかし糞コードならどんどん投げてもらえるし、それらを受け入れる限り、進化が止まることもない。
はーなんだかねー。なるほど研究者と色々衝突するのも分かる気はする。
そういや大昔「伽藍とバザール」読んだなーと思って今読み返してみたが、これがバザールなのか？

（NGにかかったので分割した）
800 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 10:41:57.59 ID:NhDXzDSd0.net]: それだけ文句あるなら本家MLで言うか自分で作り直してみろよ軍師様
これだけ大口叩いておいて英語のMLでコミュニケーションとれないとかだったら笑うが
Git は世界中のプログラマが使ってる最重要プロジェクトで、これが改良されるとなれば世界中から絶賛される
801 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 10:46:51.87 ID:odT0DHDr0.net]: まだやってのか
暇そうだな
802 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 13:22:38.17 ID:AHw2USmo0.net]: >>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%A
803 名前：0%E3%81%A3%E3%81%9F%E3%82%82%E3%81%AE もあり、顧客自身が実装してるんだから、そりゃ商用VCSでは絶望的に仕様的に太刀打ち出来ない。 そしてソースコード戦略も違う。Gitはコードレビューとか無い世界なんじゃないかな？ それで回るってのがスゲエが、多分これは「伽藍とバザール」の衝撃を追体験しただけなのだろう。 ソースコードを綺麗にしたら、新機能の追加が断然早くはなるけど、それは同じ人数での話で、 ここも手数で勝負だ！と来られたら、為す術もない。 ソースコードなんて糞でいいんだ、人数さえ有れば！では、研究者とは対立するよ。 なるほどエンジニアリングの天才だというのも納得ではある。 だからまあ、Gitを根本的に覆すにはGitよりも良い仕様が必要で、これは本当に難しいんだろうさ。 ところで、やはり俺のワークフローではIndexが邪魔なので削除しようと思うんだけど、 そもそもあれはどう使う為に設計されたものなのだ？ 多分Indexの存在が一番直感的でなく、『説明されてないと』間違える所だと思うんだが。 今のところadd直後にcommitしてて、邪魔でしかない状態で使ってる。 []: [ここ壊れてます]
804 名前：デフォルトの名無しさん [2022/11/03(木) 13:30:44.47 ID:9oLRzF140.net]: index stageなかったら複数ファイルの変更を一度にcommitできないじゃん。コミット粒度の問題から、全部の変更をcommitしたいわけでもないし。
どのcommitを取ってきてもちゃんと動く状態にするのが普通だからどう考えてもいるでしょ。
805 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 13:52:50.16 ID:/4IN/B1bM.net]: indexの意味がわかってない馬鹿が全然関係無いファイルをコミットしてリポジトリをブチ壊す
806 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 14:35:27.11 ID:AHw2USmo0.net]: >>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 を真似して上記のようにするつもりだが、何かまずいかな？
807 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 14:40:47.35 ID:5PP47Osh0.net]: git分からない思想も理解できないならSVN使えば？
808 名前：デフォルトの名無しさん [2022/11/03(木) 14:46:46.91 ID:9oLRzF140.net]: >>773
そりゃgitの設計思想で想定されたコミットの仕方をしていないからindex stageがいらないと感じるだけでしょ。
大多数は設計思想通りに使っているので、index stageが必要だと理解していると思うよ。
だから、「どう使うために設計された」かと聞かれれば、gitの思想通りにコミット粒度を適度に保つためだとしか言いようがない。
「俺は違うから俺はいらない」はそれはそうだろうが、だから何？って話になる。
809 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 15:04:33.12 ID:jVDh6EB5M.net]: 適当なタイミングで時系列に修正を記録していくものだと思ってる阿保には理解できないVCS
810 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 15:05:56.85 ID:AHw2USmo0.net]: >>775
git add -u を複数回して粒度を上げて動くものだけcommitしてもいいのだけど、
俺の場合は10回に1回程度は2-3回前の変更とdiff取った方が見やすいことがあって、
その場合にhash控えておくのが面倒だし、gcされてたらさらに面倒だし、gc切るのもまた邪道だろうしで、
動かないのもcommitしてfeatureの途中は動きませんと割り切るのが一番ましかと思ってる。

まあでもありがとう。
粒度調整の為ならこちらの予想の範囲内ではあった。
811 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 15:26:33.67 ID:O+O1uzzM0.net]: >>777
> その場合にhash控えておくのが面倒だし、gcされてたらさらに面倒だし、gc切るのもまた邪道だろうしで、
N個前との diff は git diff HEAD~N でハッシュを控える必要もないし gc のくだりは何のこと言ってるのかわからない。

> 動かないのもcommitしてfeatureの途中は動きませんと割り切るのが一番ましかと思ってる。
ローカルブランチなら別に構わないけど、そのノリで作られたブランチをそのままレビューするのは効率悪い。
なのでマージ前のブランチをレビュー対象とする開発では push の際に整理することになるから、
都度整理の際にインデックスはとても有用。
他にも、作業中に全然関係ない typo 直したりするのにも使える。
812 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 15:53:58.77 ID:HnXRQ5rf0.net]: index の重要性が分からないやつが git 語ってて草。
素人向けに説明すると git の役目は他人に読んでもらうやすい分かり易いパッチを仕上げること。
個人で作る分にはそれほど関係ないが共同作業するには他人への分かり易さ、見た目は最重要といっていい。
料理に例えるならフライパンやまな板のまま出すんじゃなくて、皿に盛って食べ易くしてから出すのが基本。
ワークツリーがフライパンで、インデックスが皿。フライパンからでも直接食えるけど、綺麗に皿に盛って、そこで丁寧にチェックしてから提供すれば他人の作業効率が上がる。
813 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 16:18:44.28 ID:AHw2USmo0.net]: >>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コマンドはスルーだからな)
814 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 16:20:05.12 ID:AHw2USmo0.net]: >>779
いやレビュー対象はcommit済みで、index上ではないだろ。
815 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 16:22:38.83 ID:5PP47Osh0.net]: うんうんわかった
大人しくSVN使え
その方が君には向いている
816 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 17:18:17.27 ID:NhDXzDSd0.net]: >>781
779はindex上でレビューするんじゃなくて、indexにいれた状態にしてからdiff --cachedでcommit前の確認をするってことじゃない？自分もそれやるよ
817 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 17:50:52.37 ID:e1pojM/n0.net]: >>763
> (昔からsh《bsh》は互換性は高かったし、今はその後継のbashで統一されてる。
> ああ確かにcsh/tcsh/ksh/zshはゴミだったし死滅したよ)

FreeBSDにはbash入っとらんぞ
818 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 17:52:28.68 ID:e1pojM/n0.net]: >>763
> 既にあるbash(多分C)ソースをコンパイルしただけのものを同梱し、
> gsh(=gitsh)だ！これを使え！と強弁すれば済んだろ。
bashだけじゃ足らんだろ
GNUコマンドも全部入れなきゃな！
819 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 17:53:10.48 ID:e1pojM/n0.net]: >>770
> 仮に時間が十分にあったとしても、俺が改善出来るのはソースコードであって、アプリではない。
だからソースコードを改善しろってｗ
820 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 18:10:35.38 ID:3fLLADP3M.net]: >>784
macもbsahやめたんだよね
GPLから逃げるために
821 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 19:01:05.13 ID:AHw2USmo0.net]: あと実は、masterの意義も分からないのだが。俺の場合は、

master: 今現在Web上で公開しているもの
develop: 今現在ローカル上でテストしているもの
feature: 今現在変更中のソースコード

と3つポインタが必要なのは分かる。
しかし、masterは常にdevelopとfast-forwardマージするなら、developにタグ打てば済む。
途中からのbranchも可能だし、hotfixするにしても問題ない。
branchケチる意味もないのも分かるが、それにしても無駄に多い気もする。

と思ってたら、俺にはサル先生方式位が適切な気がしてきた。
> ここでは統合ブランチとトピックブランチという二種類のブランチを使った運用方法について紹介します。
> https://backlog.com/ja/git-tutorial/stepup/02/

サル先生方式の統合ブランチにタグ打つだけと比べて、
masterとdevelopとして別に持っておいたら何が嬉しいの？
822 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 19:03:24.24 ID:AHw2USmo0.net]: >>784
>>787
政治的案件をOSS側がフォローする必要ないと思うが…
823 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 20:29:42.55 ID:e1pojM/n0.net]: >>789
なに政治的案件の話にすり替えようとしてるんだよ
gitは環境依存が激しいシェルスクリプトに依存しないように
C言語で書いてるって話をしていただろ
824 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 20:33:17.75 ID:e1pojM/n0.net]: >>788
1系、2系の同時開発とかあるやろ
825 名前：デフォルトの名無しさん [2022/11/03(木) 20:41:00.73 ID:vXMSDhes0.net]: .gitignoreの書き方で質問
app.log, app.log.1, app.log.2みたいな感じで増えていくログファイルを無視したいのですがどう書けばいいですか？
826 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 20:41:54.93 ID:5PP47Osh0.net]: >>788
なんだやっぱりブランチのことすら分かってなかったのか
827 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 20:48:29.66 ID:5fumPTTR6.net]: >>792
*.log* でなにか被ったりする？
828 名前：792 [2022/11/03(木) 20:58:19.76 ID:vXMSDhes0.net]: logフォルダ作ってそれを無視することにしました

>>794
ごめんなさい！
829 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 21:00:04.22 ID:AHw2USmo0.net]: >>791
あ、なるほど了解。
逆に言えば、同時開発する気がなければ要らないわけだな。
830 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 21:04:46.26 ID:e1pojM/n0.net]: >>796
今自分で「必要だ」って言ったってこと理解してるかい？
831 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 21:15:11.85 ID:AHw2USmo0.net]: >>790
C化しただけで環境依存が無くなるのなら、既にC化されてるbashでいいだろ。
Cコード上で何か小細工が必要なら、それは「互換性を上げる」名分でbashにcontributeすべきで、
Git側で吸収する案件ではない。

GPLから逃れたいってのも意味が分からん。
bashのコードを改変して新機能追加してmac_bachにしたら、そのコードを公開しないといけないが、
普通にbashを使って作業するだけなら関係ないから使えばいいだけ。
何か思惑有るんだろうけど、Gitがソースを汚してまでフォローする案件じゃないだろ。

> また、これ以外にも zsh や bash などのシェルが FreeBSD Ports Collection から利用可能です。
> https://
832 名前：docs.freebsd.org/ja/books/handbook/basics/ 自分でインストールしろよ。 []: [ここ壊れてます]
833 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 21:16:20.05 ID:e1pojM/n0.net]: だからなんでgit使うだけで
bash＋たくさんコマンド入れなきゃならんのだよ
834 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 21:22:26.35 ID:AHw2USmo0.net]: >>797
必要なのはポインタであってブランチではないんだ。
というか、俺にとってはその時のスナップショットが復元出来れば何だっていいんだよ。

fast-forwardでは履歴が辿れないからrebaseで、みたいな話もあるからもうちょっと確認必要だが、
git flow は手動ではなくインストールして使え、そうすれば全部やってくれる、としてるところばかりで、
どうもmergeの時に色々判断して小細工してるようだが、何やってるのか書いてないから分からないんだ。

まあでも色々他の簡単なのもあるみたいだし、初心者だから出来るだけ単純なのにするよ。
835 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 21:25:51.42 ID:AHw2USmo0.net]: >>799
逆に一体どんな環境でやってるのさ？
普通のunixコマンド一式すら入ってないのか？

そもそもGitなんてPCかそれに近い環境で動けば良くて、それ以外は考慮する必要ない気がするが。
836 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 21:29:12.32 ID:e1pojM/n0.net]: >>800
今話をしているのはお前が言ったこと

> 逆に言えば、同時開発する気がなければ要らないわけだな。

if (同時に開発する気がある) {
　　いる
} else {
　　いらない
}

自分で同時に開発する気があればいるって言っただろ自分で
837 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 21:39:01.44 ID:AHw2USmo0.net]: >>802
ん？どこを誤解されてるのかは分からんが、
俺は複数バージョンを同時開発する気はない。
ただ、リリース後にバグが発覚するする事はあるので、hotfixはする。
838 名前：デフォルトの名無しさん [2022/11/03(木) 23:10:44.38 ID:9oLRzF140.net]: >>801
普通にSourceTreeとかでコマンド一杯を前提としているとは思えないが。
839 名前：デフォルトの名無しさん [2022/11/03(木) 23:14:43.83 ID:9oLRzF140.net]: >>788
少なくともCIで回すときは楽だろ。
Git初心者で視野狭すぎなのに、その視野の狭さを無視して「合理的に考えてこれが不要」ってのがあんたのスタイルのようだけど、
そうやってわざわざ視野の狭さから来る「不要」の主張をして反感を買ったレスで学びたいのか？
勉強したいなら、炎上スタイルは目障りなんでよしてほしいな。二言ぐらい余計なんだよ。
840 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 23:20:07.30 ID:NhDXzDSd0.net]: >>798
以下は簡単に調べただけで、時系列の検証もしてないので、何か間違いあるかもしれない

macOSはbash,gcc,sambaをベースシステムにいれるのをやめた
これらはGPLv2からGPLv3にライセンスが変更されて、GPLv3に追加されたバイナリの取り扱いに関する条項がmacOSのセキュリティポリシーに合わなくなったのがその理由

linusはこのGPLv3の条項に批判的で、gitはGPLv2のままでいく可能性が高い
GPLv3のbashに依存するようgitを作り変えると、インストール方法をちょっと特殊にしないとgitもこのGPLv3の条項の制限をうけることになってしまうので、まあやらないだろうね

他のOSSに依存するとこういうのもあるから気を付けないといけない
841 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 00:15:00.44 ID:SQ9pznPg0.net]: > Cコード上で何か小細工が必要なら、それは「互換性を上げる」名分でbashにcontributeすべきで、
Git側で吸収する案件ではない。
頭おかしい
842 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 00:54:15.51 ID:NvjwOVKTd.net]: まあdevelopはいらないかな
mainブランチで開発すりゃいいよ
リリースブランチが必要なら別途releaseブランチを作ればよいのであって、デフォルトブランチは開発系の先端を指してる方が分かりやすい
843 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 01:05:42.22 ID:EF7BixRC0.net]: >>798
> Cコード上で何か小細工が必要なら、それは「互換性を上げる」名分でbashにcontributeすべきで、
gitの都合でbashに迷惑をかけるな
お前のやりそうなことだな
自分の都合で関係ないやつに迷惑をかける
844 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 01:06:39.03 ID:EF7BixRC0.net]: >>808
初心者のお前の感想なんかどうでもいいよ
845 名前：デフォルトの名無しさん [2022/11/04(金) 02:09:07.55 ID:v1xRwBrw0.net]: GPLに賛同せずにGNU製
846 名前：品を使ってたってことだろね。 結局Linusもタダ乗り爺ってことでしょ。 []: [ここ壊れてます]
847 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 02:50:33.29 ID:BbpXyzD40.net]: ブランチの名前の付け方や使い方なんてほんとどうでも良い。チーム内で話し合え
git のブランチは全部等価
デフォルトで main / master 作られるけど
これも使いたくなけりゃ使わなくて良いし名前変えても良い
848 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 18:16:16.05 ID:XH5wI1Z90.net]: >>805
そんなガキみたいなことはしないが、
どう取るのも自由だし、気に入らないのなら無視してくれて構わんよ。

ただgitがポンコツだと言ったとしても、それ本来お前ら関係ないよね？
自身の分身と思えるほどcontributeしまくってるのなら別だけどさ。

> 少なくともCIで回すときは楽だろ。
必要になったときに作ればいいだけなのと、
多分仕様か実装を間違えてて、今のGitの動作では技術的に実用性がない。
これは次の投稿で詳しく述べる。
849 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 18:17:59.81 ID:XH5wI1Z90.net]: A. 消したbranchの情報が確認出来るのって、reflogsだけ？
B. あと、branchは線だ！ってマニュアルは言ってるけど、点だよなこれ？
（ドキュメントか実装のどちらかが間違ってると思うが)

以下git-flowを真似てるとして、gitkと同様に下から上にcommitして、

impl5@feature5, merged to develop and master, add tag of "Version1".
impl4@feathre4
impl3@feature3
impl2@feature2, merged to develop, add tag of "Version0".
impl1@feathre1
impl0@feature0
initial@master, develop

としたとする。
このとき、featureXを一々作っては消させてるのだから、
何か簡単に一覧に出来るコマンドがあるべきだが、無さそう。(git log --walk-reflogsで探すことは出来るが)
正直あとから参照することはほぼ無いが、何かあってもいいと思うが？---(A)
850 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 18:19:31.52 ID:XH5wI1Z90.net]: そして、どうやら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で修正されるべき案件だろうね。
851 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 18:20:37.25 ID:XH5wI1Z90.net]: >>806
MacOSがFreeBSD系なのとLinusがGPLv3をボロクソ言ってたのは知ってたが、両方とも理由は知らなかった。

> GPLv3に追加されたバイナリの取り扱いに関する条項がmacOSのセキュリティポリシーに合わなくなった
よく分からんが
852 名前：結局は両方ともここかな？ > プロプライエタリなドライバソフトをLinuxカーネルに読み込む際にDRMの技術を応用している件についてだと思います。 > http://japan.cnet.com/news/ent/story/0,2000047623,20095317,00.htm > GPLv3ではDRMを実装する場合はそのDRMのアルゴリズムに加えて秘密鍵も公開することを義務付けているので、 > そのようなことをしたらプロプライエタリなドライバを提供してもらえなくなるため、賛成はできない、と。 > https://srad.jp/story/06/01/29/1119224/ ただこれって、 GPLv3のコードを使ったバイナリを配布する際、そのバイナリと同じ物を作れるソースコードも配布しろ、だから、 GPLv3のBashをGit配布zipに同梱してもBashのバイナリだから何ら問題ないはずなんだけどね。 GPLv3だからだめだ、ならGPLv2(～2007)のBashでも十分だろうしさ。 やっぱりかなり政治的だよ。勿論譲れないのだろうけどさ。 []: [ここ壊れてます]
853 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 18:22:05.12 ID:XH5wI1Z90.net]: >>807
>>809
お前ら狭量すぎ。OSS全体で盛り上がるんだ！という考えが無さ過ぎ。
diffもそうだが、bashの互換性が本当に問題なら、bashを修正すれば全員助かるだろ。
Gitコマンドをシェルで実装すると、unixコマンドの中にgitコマンドが混ぜ込まれてる形になる。
そのgitコマンドをcpに差し替え、unixコマンドだけの状態で環境依存で使い物にならないのなら、
それは立派なバグだから、bashの連中に投げれば直してもらえるよ。
自分で抱え込みすぎ。それでは回らなくなる。(のが一般的だが、バザールだからなあ…)

ただGNUとは根本的にウマが合わないだろうよ。
仕様はグダグダ、ソースコードはゴミ、でも回り続けてるのだから、GNU(伽藍)から見たら何じゃあこれは！！！ってなる。
Git側にはGNUの開発速度はどうにも認められないだろうしね。
854 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 8b14-Tk+f) mailto:sage [2022/11/04(金) 19:16:09.99 ID:EF7BixRC0.net]: > お前ら狭量すぎ。OSS全体で盛り上がるんだ！という考えが無さ過ぎ。
だからgitの話はgitの中で盛り上がればいいだろ
勝手に他人の家で盛り上がるな
ば～か
855 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 8b14-Tk+f) mailto:sage [2022/11/04(金) 19:18:48.53 ID:EF7BixRC0.net]: >>817
あとgitをbashに依存させるな
856 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 8b14-Tk+f) mailto:sage [2022/11/04(金) 19:19:54.54 ID:EF7BixRC0.net]: bashがなんでも修正を入れるわけがない
それは俺の仕事じゃないと言って断られるが落ち
bashをぶくぶく太らせるな
一つ事だけやらせろ
857 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 19:54:32.33 ID:fRhzbJ/d0.net]: >>816
GPLv3ではバイナリを配布する際にそのバイナリをユーザがソースからコンパイルしなおして入れ替え可能でなければいけないという条項になっているらしい
MacOSやiOSのアプリやストアから配布するAndroidのアプリなんかの今どきのバイナリ配布は、署名済みバイナリしか実行できないから、ここにGPLv3の物を入れるとライセンス違反になる
858 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 19:57:10.42 ID:fRhzbJ/d0.net]: >>817
GNUは別に開発組織ではないから統一的な開発ポリシーなんてものはないが、
GPLv3に移行するようなFSF管理下のGNUプロダクトは、歴史も古いし、比較的少数のおっさん達が気ままに管理してることが多いので、OSSと呼ばれるようになる前からの伝統的なUNIXフリーソフトのべたなソースツリー構成なものばかり
たとえばbashのソースコード構成なんてgitみたいにトップディレクトリ下に組み込みコマンドの実装コードがだらだら並んでてgitと変わらん
859 名前：デフォルトの名無しさん [2022/11/04(金) 20:10:08.60 ID:jUM5cpqM0.net]: どのOSでメインに作業してるのかわからん感じだな。
LinuxはCでモノリシックだとDISり、GNUコマンド群でないmacOSも�
860 名前：桝RDISり、 Windowsなんか論外って感じだろ。 3OSぐらい使ってたらとてもシェルなんか信用できないけどな。 []: [ここ壊れてます]
861 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 21:06:47.76 ID:XH5wI1Z90.net]: >>822
いやそこまでは全然見てない。
今回の仕様とパッチの顛末見て、他もそうだと勝手に推定してる。
読む価値のないコードのはずだから。(物によって全然違うかもしれんが)
ただこれで回ってるのは事実だからな～。ちょっと観戦モードだ。

まず既に言ってるが仕様がグダグダ。
仕様は追加は簡単だが、削除することは基本的に無理なので、厳選しないといけないのに、まるで出来てない。
つまりこの辺の常識的な長期保守戦略をまるで知らない奴がやってて、止める奴もいないということ。
そして今回のメモリリークだが、確保したらそこで寿命も確定する、実装が一番簡単なタイプで、
これをリークさせるようなら話にならない。
ただそれでもミスることはあるが、出てきたパッチがこれまたグダグダで、Cのメモリ管理の基本を完全に無視してる。
レビューがあったら見た瞬間落とされるソースだ。そりゃリークするよな、としか思わない。
(ただし第２弾、第３弾も出てきて、ましになりつつあるが、それでも方向性を根本的に間違ってる。
とはいえ、展開が異常に早いのも確か)

だから、通常の開発をやっているであろうGNUでは、仕様のレビューでも、コードのレビューでも落とされる。
だけどGit側にその理由を理解出来る奴がいないからこうなわけで、当然ブチ切れる。
そして喧嘩別れ、だったら俺らで作るからいいよ、でforkして突っ走ってるだけのように見える。
若すぎる。
ただそれでも実装能力だけはあるので、diffはGNUより装飾周りが断然進歩してる。
これはやっぱりGNUdiffと一緒にやってた方がみんな幸せだったと思うよ。
上手く導ける奴がいれば、
というより普通に長期保守したことがある奴が上層部に一人でもいれば、この辺は簡単に修正出来ると思うのだけど、
それは伽藍タイプの話で、バザールだとどうにもならないのかもしれんし、
突っ走らせないとプロジェクト自体が死ぬのかもしれんし、(サメみたいにね)
よく分からん。
862 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 21:10:52.33 ID:EF7BixRC0.net]: 口だけ達者で何もできない無能
863 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 21:14:59.38 ID:PwG12fTHM.net]: >>824
GNUが何なのか全く理解できていない
864 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 21:27:19.25 ID:PwG12fTHM.net]: >>823
自分が理解できないものは全部糞
理解力が致命的に弱い
この2つが合わさると全方面Disることになる
865 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 21:35:53.62 ID:SQ9pznPg0.net]: >>817
何で自分の関心の向かないOSSにわざわざ貢献しないといけないんですか？
金も貰えないのにそんなの苦行でしょう、アホらしい

それとも君はLinusに向かってそれを要求できるほどGNUに対して貢献してるんですか？
866 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 21:39:58.51 ID:EF7BixRC0.net]: bashの方を直せって言うなら
GNU bashのプロジェクトに殴り込みをかければいいじゃん
お前が
867 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 21:54:21.97 ID:XH5wI1Z90.net]: >>828
逆だよ。他人に投げられることは他人に投げろと言ってる。
bashのバグだってことになれば、勝手に直してもらえるだろ。
自分で対応するのは、直してもらえないのが確定してからでいい。

>>829
そもそも俺はbashの互換性で苦労した試しがない。
ただそもそもOS跨いでシェルスクリプトを持っていった試しも無いけどな。てかそんなこと普通せんし。
あーだから、最悪Linux/Windows/Mac用と3種類用意すればよかったんじゃね？C化よりは楽だろうよ。
868 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 21:55:50.76 ID:EF7BixRC0.net]: > 逆だよ。他人に投げられることは他人に投げろと言ってる。
なんのために？
869 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 21:56:20.74 ID:EF7BixRC0.net]: > bashのバグだってことになれば、勝手に直してもらえるだろ。
だからお前がbashに通報しろって

お前という他人に投げたぞｗ
さっさとやれ
870 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 7997-uk66) [2022/11/04(金) 22:08:26.91 ID:jUM5cpqM0.net]: >>8
871 名前：30 え、Cでプログラム書いたことないの？OS間の違い、標準Cライブラリの方がよっぽど互換性に苦労することないよ… 考慮しなければならないのはファイルシステムと改行コードぐらいだろう。 []: [ここ壊れてます]
872 名前：デフォルトの名無しさん (ﾌﾞｰｲﾓ MM33-ntN1) mailto:sage [2022/11/04(金) 22:17:50.42 ID:qsZ+zSWqM.net]: まあおまえら落ち着け>>815とか見る限りこいつはひとりではGitを理解できない
炎上させて答えを引き出そうとしてるから餌を与えちゃいかん
ほっとけばすぐいなくなるよ
873 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 22:48:48.23 ID:XH5wI1Z90.net]: >>834
ああ、@1か、これは失礼。
ただお世辞にも分かりやすいとは言えないねこれは。
まあでも、ならbranchを残す意味はあり、>>815は取り下げだな。
>>814については引き続き募集中。
874 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 22:50:35.62 ID:XH5wI1Z90.net]: @{1}ね、まあ分かると思うけど
875 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 23:04:09.79 ID:7RpVnNq7M.net]: >>836
@{1}に気が付くとはさすが軍師殿ｗｗｗ
876 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 00:48:19.73 ID:yugci9j10.net]: HEAD~1 で一つ前のリリースとか言ってて爆笑
リリースごとに一回だけコミットするつもりなのか？
永久に git 理解できそうにないな
877 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 01:35:03.83 ID:CLSrxuim0.net]: ネットのクソ記事で独学するより、まともな本買って学習すればいいのにな
つうかあれか、gitの仕様の粗探しがしたいから使い方とかどうでもいいのか
878 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 01:42:19.97 ID:zPyCNtrD0.net]: そもそも一つ前ｗみたいな考え方するようなものじゃないよなｗ
879 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 03:02:36.62 ID:0q4aURph0.net]: 自分が理解できないから、知ってるシェルスクリプトにすがってるだけだな
POSIX原理主義者と一緒。POSIXの名前を勝手に使って
シェルスクリプトしかできないのをごまかしてる
gitを利用してシェルスクリプトしかできないのをごまかしてる
880 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) mailto:sage [2022/11/05(土) 09:15:20.90 ID:646uiMLL0.net]: >>717
ちなみに書く側のコマンドは hash-objectのようだ。
多分初期はPlumbing Commandsをシェルスクリプトでラップして各上位コマンドを提供してたのだろう。
そして俺にはこの程度のシェルスクリプトが環境依存するとはとても思えないんだけどさ。

>>821
って、ふと気づいたが、俺が使ってるのはGitBashだったわ。
現在の公式版にもGitBashバイナリは同梱されてるし、ライセンスがどうこうという問題は無いか、解決されてるよ。
Macは政治的だとして、Linusはその辺実務的に見えるから、
GPLv3をボロカス言って自分はGPLv3には参加しないが、(これは正当な権利で全く問題ない)
GPLv3を殺す為にGPLv3のプロダクトの同梱すらしない、みたいなことはしないのだろうよ。
881 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) mailto:sage [2022/11/05(土) 10:38:45.29 ID:646uiMLL0.net]: >>814
公式のcontribに置いてあるユーザー製作の勝手ツールにあるのは発見した。
つまり熟知してる公式からみても面倒な作業だと認めているわけだ。
解決というよりは諦めと納得だが、これも質問を閉じる。
> https://zenn.dev/yoichi/articles/git-restore-branch

ちなみに、branchを『後から追加』は出来るか？
いやそんな使い方はおかしい！禁止だ！かもしれんが、
やはり俺にはbranchはただの(DBにおける)INDEXで、
随時落としたり作ったり復活させられないと使いづらい。(のではないかと予想している)
ただ、要はreflogを偽造すればいいだけのようだが、
再実装は時間の無駄で
882 名前：しかないので、既にあればそれを使いたい。 []: [ここ壊れてます]
883 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 11:40:31.33 ID:zDjINlW+0.net]: >>842
index-stageを理解してないおまえにはわからないかもしれないけど、
DBへ登録されるのはwork tree上のファイル丸ごとでない場合もあるし、
逆にDBからwork treeへ展開されるのもファイルの中の一部分の場合があるから、
そんな単純にはいかない
884 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 11:40:56.02 ID:zDjINlW+0.net]: >>842
Windowsはアプリを実行する上でコード署名が必須でないから問題にならないだけ
885 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 11:41:36.89 ID:zDjINlW+0.net]: >>843
gitのマージを全然理解できてないからブランチを復活させたいとか思ってしまうんだな
普段の運用でスクリプトを使ってブランチを復活させたいとか思う羽目になることはあまりない

ブランチがDBにおけるindexみたいなものとか、後から追加できる？みたいな疑問が生じるあたり、ブランチが何なのか全然わかってない
reflogの偽造が必要という発想もかなりズレてるし、>>814 をみるとコミットの履歴がどういうものなのか理解できていないのだろう
886 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 12:57:19.46 ID:646uiMLL0.net]: >>844
さすがにその程度は知ってるぞ。
ただ、一般的には git add -A で問題ないディレクトリ構成で使う方が多いんじゃないか？

まあそれはさておき、
要は、正しくソフトウェアが構成されてれば、cat-file/hash-object を組みで交換すれば、
末端のファイル形式は自由に選べるって事だよ。sshにすればネットワーク先にも余裕だ。
つってももうこの話は通じないのでいいが。
887 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 13:13:08.87 ID:646uiMLL0.net]: >>845
つまり現行2.38.1のMac版にはBashバイナリが入ってないのか？
それでMacに元々入っているbash以外のshを使ってれば、そりゃ問題は発生するだろうさ。
> https://qiita.com/ko1nksm/items/59c2e8a7afa969af8212#:~:text=Mac%20%E3%81%AE%E3%82%B7%E3%82%A7%E3%83%AB%E3%81%AF%20macOS%2010.15%20Catalina%20%E3%81%A7%20bash%20%E3%81%8B%E3%82%89,%E3%81%AB%E5%A4%89%E3%82%8F%E3%81%A3%E3%81%9F%E3%81%A8%E4%B8%80%E8%88%AC%E3%81%AB%E8%A8%80%E3%82%8F%E3%82%8C%E3%81%A6%E3%81%84%E3%81%BE%E3%81%99%E3%81%8C%E3%80%81%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB%E3%81%95%E3%82%8C%E3%81%A6%E3%81%84%E3%82%8B%E3%82%B7%E3%82%A7%E3%83%AB%E3%81%AF%E3%83%90%E3%83%BC%E3%82%B8%E3%83%A7%E3%83%B3%E7%95%AA%E5%8F%B7%E3%81%AE%E9%81%95%E3%81%84%E3%82%92%E9%99%A4%E3%81%84%E3%81%A6%E4%BB%A5%E5%89%8D%E3%81%A8%E3%81%BB%E3%81%A8%E3%82%93%E3%81%A9%E5%A4%89%E3%82%8F%E3%81%A3%E3%81%A6%E3%81%84%E3%81%BE%E3%81%9B%E3%82%93%E3%80%82%20%2Fbin%2Fsh%20%E3%81%AF%20POSIX%20%E3%83%A2%E3%83%BC%E3%83%89%E3%81%A7%20bash%20%28%2Fbin%2Fbash%29%20%E3%82%92%E8%B5%B7%E5%8B%95%E3%81%97%E3%81%BE%E3%81%99

Macとしては署名済みじゃないとウイルスかもしれないので認められず、
GPLとしては署名付けるならその署名を作るソースも公開しろと言ってるわけ？
どっちも拗らせすぎだが、
一般論としては、Mac側に「開発者オプション」で「署名がないバイナリの動作を許可する」があれば済む話では？
実際自分でコンパイルしたバイナリを動かせないと困るし。
ただ、Macってスマホと同一化したからこれって脱獄になるんだっけ？
ならまあ、Gitの為に脱獄はないし、こじれるのは分かるが。

まあ、正直つき合いきれないが、俺なら、C化ではなく、
bashの機能を諦めてshの機能だけで書き直す方を選択するけどね。
888 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 13:19:32.87 ID:zDjINlW+0.net]: >>847
実際仕事すればわかるが add -Aで綺麗なコミットを作れるように整備されてるリポジトリはあまり無い
デバッグしながらコミットしていくときは add -p を使うことがとても多い
889 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 13:20:48.95 ID:zDjINlW+0.net]: >>848
https://www.infoq.com/jp/news/
890 名前：2019/07/macos-ditches-bash-for-zsh/ []: [ここ壊れてます]
891 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 13:57:20.56 ID:0q4aURph0.net]: git add -Aで十分とかさぁ、開発経験なさすぎだろ
それはgitをバックアップとか途中セーブ機能とでも思ってんのか？
1 commit = 一機能の追加とか、一日の最後にやるものとか思ってるんだろ

通常なにかのバグの修正とか
複数の個別の問題の複合なのに
それ全部まとめんな
892 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 13:58:29.56 ID:646uiMLL0.net]: >>846
そもそも俺含めて大半のプログラマはGitを理解したいとは思ってなくて、
単に便利だから使ってるだけだと思うがな。
理解せずに使えるのならそれに越したことはない。
(この価値観が相容れないのは理解したからもういいが）

君はGitを履歴追跡ツールとしてしか見てないようだが、
俺はもっと一般的に、Git形式のDBとして見てる。(INSERT履歴が保持されるDB)
そして、俺は>>808と同意見で、
開発が今現在行われていないブランチは閉じられてた方が見やすいと思ってる。
常時存在するのはgit-flowでいうdevelopだけで、masterやreleaseはタグでよく、
hotfixを作るならまずmasterブランチを復活させ、そこからhotfixを発生させたほうがいい。
(なおreleaseブランチは最後にバージョンを打つ奴にはいいが、
俺は先にバージョンを打ってから更新部分を実装するので、俺のワークフローには合わない）

それ以外にも、featureX付加時の変更漏れ/不適切な変更によるバグ挿入が後で発覚することはあるから、
git-flow的にfeatureを作っては消しで行くなら、ブランチの復活はプログラマには疑問のないことだ。
featureX_patch0と新たな変更扱いしてもgitオブジェクトツリー自体は同じだが、
名前が似てるだけの別物扱いになるので、
featureXの開発『線』をメンテナンスする気なら、branchの復活が必要になる。

実は、とりあえず同じ名前で作り直せば自動的にくっつく馬鹿向け仕様か？と試してみたが、
まあGitの文化でこれはなかった。
が、まあ、俺的にはこれであって欲しかったね。
「同じ名前が昔ありましたが、そこにくっつけますか？(Y/N)」「Y」
「いい加減にしてくださいよ、何回目ですか？」「うるせーよ」みたいな。

ただこれ、branch側は --list オプションで表示を簡単に絞れるから、
Gitの思想としてはbranchは「消さずに全部残しておけ」で、
git-flowがGitの思想と合ってないだけだね。ならツール用意しとけと。
893 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 14:02:51.18 ID:0q4aURph0.net]: >>852
世の中に理解しないで使えるものなんてない
894 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 14:04:13.47 ID:0q4aURph0.net]: 大体gitの使い方を理解したいと思ってるやつはアホ
理解するのはバージョン管理の仕方だ

こうやってツールの使い方を学ぶことが理解だと思ってるから
gitがなくなったらどうしよう
また新しいことを学ばなきゃいけないってなるんやろ
895 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 14:19:41.99 ID:W/77BOuWM.net]: >>854
git そのものを理解すること諦めたか
でもお前使い方の方も盛大に勘違いしてるよ
896 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 14:24:19.56 ID:646uiMLL0.net]: >>851
> それはgitをバックアップとか途中セーブ機能とでも思ってんのか？
> 1 commit = 一機能の追加とか、一日の最後にやるものとか思ってるんだろ
そうだぞ。
ブッ込んでおけば後で何とでもなるただのバケツでしかない。
バケツの使い方を学べとか、知るかボケだ。
後でバケツから探し出すハメになった時、取り出し方をググって取り出せれば十分だ。
大方、プログラマの大半はこの程度の認識のはずだぞ。

そしてお前が望む、綺麗な管理記録は、これのサブセットでしかないんだよ。
だから例えば俺が780で言ったように、「コミットメッセージが空」を除外すれば簡単に得られる。
今のGitにこの機能がないだけ。（まあ近い機能はあるが）
DBならWHEREに条件を付加すればいいだけの楽勝案件で、Web系ならみんな出来るよ。
sedのワンライナーで済むことすらCで実装するGit界隈だと誰も出来ないのだろうけどさ。

まあGitにSQLインタフェースを付け加えればWeb系の奴等は文句言わなくなるんじゃないかな？
連中にとっては直感的になるから。
897 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 14:34:25.48 ID:0q4aURph0.net]: > 大方、プログラマの大半はこの程度の認識のはずだぞ。

お前の周りの無能集団だけだろ
898 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 14:35:58.29 ID:0q4aURph0.net]: 一体どこのプロジェクトに「2022年11月4日の仕事終了時のセーブ」なんてコミットがあるんですかねぇ
899 名前：デフォルトの名無しさん mailto:age [2022/11/05(土) 14:42:21.04 ID:oTMzuhJSa.net]: >>858
それなんて、俺の前の職場
900 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 14:46:20.49 ID:0q4aURph0.net]: データの取り出し方なんか知っていても
過去のコミットのミスを簡単に直せないなら
バージョン管理は苦痛になるし
やっぱりツールの使い方だけ知ってバージョン管理をしたことがないんだろうな
バージョン管理が不便だからgitが作られたんだぞ
901 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 14:58:06.66 ID:646uiMLL0.net]: >>859
俺はそれでいいと思うけど。
記録してない方が問題で、記録さえしてあれば、ゴミとマジを簡単に分離出来れば十分だ。

>>860
今のGitの修正は十分苦痛だよ。
修正させたくないから面倒にする、は間違いで、
簡単に修正出来るが、修正したことも履歴に残るようにする、が正しい。
902 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 15:03:35.62 ID:0q4aURph0.net]: × 俺はそれでいいと思うけど。
○ 無能はそんなことをしている。

まずさぁ、gitというかバージョン管理の基本を理解してないんだからさ
そこから勉強しなよ
903 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 15:04:40.67 ID:0q4aURph0.net]: > 簡単に修正出来るが、修正したことも履歴に残るようにする、が正しい。

お前はテキストエディタで保存するたびに
gitにセーブしろって言ってんのか？ｗ
904 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 16:06:55.57 ID:646uiMLL0.net]: >>863
俺が言ってる「修正」は、Git自体の修正で、
> なのでマージ前のブランチをレビュー対象とする開発では push の際に整理することになる (778)
の場合に、SQL的に、
DELETE FROM my_repo WHERE branch='featureX' AND commit_message='';
あるいは、
CREATE INDEX beautiful_featureX ON my_repo WHERE branch='featureX' AND commit_message='';
で済むのに、何故Gitにつき合ってグダグダやらねばならんのだ？ということ。

それとは別に、ちょこまかcommitしても、俺は構わんと思うけど。
上記のように、それを１コマンドで除去出来れば、実務上何ら問題ない。
粒度が細かすぎてDBが膨れあがるなら、その部分を定期的にバックアップに切り出していけばいいだけ。
bitcoinはこの方式だ。

>>862
多分根本的に違うのは、

俺：俺のワークフローに合うようにツールをカスタマイズする
863： Gitのワークフローに合わせてgitを使え、それ以外認めない！

なんだよ。
Linusが個人的に開発したんだからGit自体はそれでいいんだが、
全世界でLinuxと同じワークフローが適切なわけではない。
905 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 16:10:37.55 ID:5Oe/8sYX0.net]: >>864
アホなの？コミットメッセージは毎回入れるものだ
906 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 16:11:36.07 ID:5Oe/8sYX0.net]: >>864
> 全世界でLinuxと同じワークフローが適切なわけではない。
だからgitはいろんなワークフローに対応してるんだろうが

お前のはバージョン管理のワークフローではない
ただのバックアップのワークフローだ
907 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 16:45:19.71 ID:CLSrxuim0.net]: まあ1人プロジェクトみたいだし好き勝手やらせればいいさ
908 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 16:54:40.83 ID:5Oe/8sYX0.net]: コミットメッセージが空だったら～とかわけわからんなｗ
909 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 16:56:10.72 ID:5Oe/8sYX0.net]: 行単位で独立してるデータベースのデータじゃないんだからさぁ
ソースコードは前後の歴史とつながってる
DELETEなんちゃらみたいに一つだけ取り除くことが出来るのは稀
910 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 17:21:12.99 ID:646uiMLL0.net]: >>869
それは当然UIの話で、当たり前だが�
911 名前：熾狽ﾌリンクは接続し直すんだよ。 そしてそれをユーザーには見せない。 多分ここら辺の階層の話がGitには存在しないんだよ。 だからユーザーがviでリンク書き換えろとかの勢いだろ。 超密結合だし滅茶苦茶だよそれは。 []: [ここ壊れてます]
912 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 17:22:28.46 ID:5Oe/8sYX0.net]: >>870
都合が悪いからって無視するな
前後のソースコード関連してるから
途中のコミットを取り除くことはできないと言ってる
913 名前：デフォルトの名無しさん [2022/11/05(土) 17:28:35.59 ID:B2i8Nuif0.net]: つまり、両親がイブに中出ししてお前が生まれたという歴史において、
イブの中出しだけを無かったことにはできないと言うことだね
その後の歴史でお前が存在するのはおかしいし
914 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 17:30:55.67 ID:646uiMLL0.net]: >>871
何言ってんだ？
中身はただの単方向リンクリストだぞ。
リンク先が複数のこともあるが、それでも問題なく抜ける。

ただそれ以前に、俺は既に言ったとおり「記録されてないほうが問題」とするので、
CREATE INDEXを使うが。これなら理解出来るか？
だったら、このINDEX対象をちょうど全部含むようにリンクリストを新しく作り直せばいいだけ。
それがDELETEしたものと同じ物になる。これで理解出来るか？
915 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 17:40:00.52 ID:5Oe/8sYX0.net]: >>873
じゃあ抜き取ってみ

・commit 1「aaa を追加」
aaa

・commit 2「bbb を追加」
aaa
bbb

・commit 3「bbb を ccc に置き換えた」
aaa
ccc

ここからcommit2を抜き取ったときの
commit3の修正内容をよく読んでみろ
916 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 17:44:37.25 ID:W/77BOuWM.net]: >>873
残念だけどそこから間違ってる
Gitのコミットのリストは単方向リンクリストではない
なのでリストの途中のコミットを削除したり途中に追加できない
917 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 17:58:44.17 ID:646uiMLL0.net]: >>874
ああコミットメッセージについては考えてなかったが、
俺ならそのままぐちゃっと貼り付けるけど。
つまり、

・commit 1「aaa を追加」
aaa

・commit 3「bbb を追加」「bbb を ccc に置き換えた」
aaa
ccc

になる。
918 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:03:19.55 ID:646uiMLL0.net]: >>875
親が複数あるだけの単方向リストだよ。
まあこれを単方向リストと呼ぶかは微妙だから、ツリーと言った方が通じたか？
ツリーが複数重なり合った状態になってるだけだよ。

単線の A<-B<-C なら A<-C になる。これは自明だよな。
マージの場合、(BがADのマージ結果ね）

A<-B<-C
D<-|

を

A<-C
D<-|

にする。
919 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:18:30.70 ID:5Oe/8sYX0.net]: >>876
ようやく理解したか。
だからお前がやってるのはただのバックアップを取ってるだけだっていってんだよ
バージョン管理というのは何をどう変えたかという変化を記録するものだ
スナップショットじゃねーんだよ、あーほ
920 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:19:21.47 ID:5Oe/8sYX0.net]: >>876
bbbの話がないのだから、
書き間違えなのか全く区別がつかない
バグコミットメッセージだな
921 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:21:44.83 ID:5Oe/8sYX0.net]: >>873
> ただそれ以前に、俺は既に言ったとおり「記録されてないほうが問題」とするので、

だからお前のテキストエディタでの変更内容を全部記録するって言ってるんだろ？
ファイルを保存するたびにコミットするんだろお前は？

バージョン管理で記録するのはソースコードの修正履歴であって
お前個人の作業履歴じゃねーんだよ
使い物にならないゴミコミットを作るな
922 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:26:48.37 ID:646uiMLL0.net]: >>878
ああ履歴についての認識が違うんだな。了解した。

履歴は、
俺：スナップショット＝「点」の並び
君：変更した線の並びで、それはcommitメッセージに現れる。

それだと、commitメッセージが間違ってる場合はどうしようもなくなるだろ。
あくまでソースコードが重要で、どこをどう変えたかはdiff取れば済むだけの話、
commitメッセージなんて目安に過ぎないんだよ。

Gitもこちらの立場に近く、VCSとしては珍しく(と聞いているが俺はそこまで詳しくないが）
差分ではなく本体を記録するだろ。
923 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:31:31.07 ID:5Oe/8sYX0.net]: >>881
> 履歴は、
> 俺：スナップショット＝「点」の並び

だから、それはバックアップで言うって最初から言ってるだろ
お前が完全に間違ってるんだよ

> それだと、commitメッセージが間違ってる場合はどうしようもなくなるだろ。
修正しろよ。それが出来るように作られているだろ

> commitメッセージなんて目安に過ぎないんだよ。
はっｗ　バージョン管理の素人が。
コミットメッセージの重要性を知らない時点で終わってるよ
924 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:32:44.57 ID:646uiMLL0.net]: >>880
> ファイルを保存するたびにコミットするんだろお前は？
そこまではしないが、1日10回とか平気ですることもあるし、それが問題だとも思わない。
この辺はポリシーだし、好きなようにすればいいと思うがね。

間違いなく言えるのは、俺は美しいソースコードを目指しているのであって、
美しいコミット履歴を目指しているわけではないんだよ。
そしてコミット履歴が過剰なら、落とせばいいだけだろ、という話。
無い履歴からは生成することは不可能なのだから、大きすぎる粒度より、小さすぎる粒度の方がいいに決まってる。
所詮commitメッセージなんて当てにならないし、diffが取れれば全く問題ない。
925 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:32:45.04 ID:5Oe/8sYX0.net]: > Gitもこちらの立場に近く、VCSとしては珍しく(と聞いているが俺はそこまで詳しくないが）
> 差分ではなく本体を記録するだろ。

だから最初からバージョン管理は差分を記録するものであり
gitの優れた点が、発想の転換で
本体を記録することで差分を表現することにした点なんだろ

実装の話とごっちゃにするな
そういうところが技術的に未熟なんだよ
926 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:33:34.01 ID:5Oe/8sYX0.net]: >>883
> そこまではしないが、1日10回とか平気ですることもあるし、それが問題だとも思わない。
そりゃお前が素人だから問題であることに気づいてないだけ
誰もやってないからね

> この辺はポリシーだし、好きなようにすればいいと思うがね。
お前が未熟だから反論できずにポリシーってことにしようとしてる
927 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:33:50.55 ID:zDjINlW+0.net]: >>877
分散バージョン管理ではですね、リポジトリのコピーがばらばらに複数存在することが前提なので、
あるひとつのリポジトリのコミット履歴が A<-B<-C で、他のリポジトリではこれが A<-C になっているという状況は不味いんですよ
なのでGitではそれができないようにデータ構造が設計されています
928 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:34:49.14 ID:5Oe/8sYX0.net]: > 間違いなく言えるのは、俺は美しいソースコードを目指しているのであって、
> 美しいコミット履歴を目指しているわけではないんだよ。

コミット履歴は「使うもの」だって分かってないようだな
一部のコミットだけ抜き取って
他のブランチに組み込む
使うものだ

お前はただ見れればいいと思ってる
バージョン管理を理解してない
929 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:35:50.16 ID:5Oe/8sYX0.net]: >>883
> 所詮commitメッセージなんて当てにならないし、diffが取れれば全く問題ない。

お前が作るコミットがクソだから、使いものにならなくなっているだけだなｗ
930 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:39:58.47 ID:646uiMLL0.net]: >>882
まあ君と仕事することは無さそうだから別に問題ないけど、

> 修正しろよ。それが出来るように作られているだろ
コミットメッセージをいくら修正したところでそもそも意味無いんだよ。
管理してるのはメッセージじゃなくてソースコードなんだから。
それで、重要なコメントはソースコード上に書いてるから、diff取れれば十分なんだよ。
コミットメッセージは、あくまでGit上から探し出すラベルでしかなくて、何をやったかはdiffで見るし、それ以外にないよ。

> はっｗ　バージョン管理の素人が。
> コミットメッセージの重要性を知らない時点で終わってるよ
まあ俺はGitの達人になりたいわけでもないんで、これで問題ないよ。
931 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:40:40.33 ID:5Oe/8sYX0.net]: > コミットメッセージをいくら修正したところでそもそも意味無いんだよ。
それはお前だけの感想ですねｗ
932 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:41:08.69 ID:5Oe/8sYX0.net]: > まあ俺はGitの達人になりたいわけでもないんで、これで問題ないよ。
バージョン管理の素人だって言ってる
お前、他の人と一緒に仕事ができないよｗ
933 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:41:43.46 ID:5Oe/8sYX0.net]: > コミットメッセージは、あくまでGit上から探し出すラベルでしかなくて、何をやったかはdiffで見るし、それ以外にないよ。

途中を抜いといて、何をやったかなんてわかるわけ無いだろｗｗｗ
934 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:43:50.28 ID:5Oe/8sYX0.net]: >>889
こうやってコミット履歴をちゃんと見れて
なんの変更をしたのかわかるようになるまで頑張れよ
https://github.com/freebsd/freebsd-src/commits

お前のコミットは汚すぎて
使い物にならんのだわ
935 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:44:39.97 ID:646uiMLL0.net]: >>884
> gitの優れた点が、発想の転換で
> 本体を記録することで差分を表現することにした点なんだろ
これは違う。
というかね、どっちを記録したところで、正常に動いていればどのみち任意の履歴を取り出せるから関係ないんだ。
ただ、ファイルシステム等がぶっ壊れて、断片的にしか取り出せなくなったときに、Gitみたいに本体を記録してる方が断然強い。

だから基本は「一番大事なもの」で記録するようにしなければいけない、という観点だったのだけど、
まあこれはフォールトトレラントにしろという話で、ちょっと蛇足ではあったね。
あまり関係ないからこの話は終わりで。
936 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:45:34.09 ID:5Oe/8sYX0.net]: > これは違う。
だーかーら、素人のお前の意見なんか聞いてない
937 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:50:58.69 ID:5Oe/8sYX0.net]: > ただ、ファイルシステム等がぶっ壊れて、断片的にしか取り出せなくなったときに、

gitは速度のためにスナップショットにしてると書いています
https://git-scm.com/book/ja/v2/%E4%BD%BF%E3%81%84%E5%A7%8B%E3%82%81%E3%82%8B-Git%E3%81%AE%E5%9F%BA%E6%9C%AC
938 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:53:08.44 ID:5Oe/8sYX0.net]: https://www.techpit.jp/courses/33/curriculums/34/sections/286/parts/965

なぜスナップショットとして記録するのか
スナップショットとして記録することで、複数人で開発する時のスピードを上げることができます。
詳しくは後ほど解説しますが、複数人での開発の際、並行して開発できるよう、
Gitではブランチというものを切って、バージョンを枝分かれさせて開発していきます。
このブランチでバージョンを枝分かれさせる際や、ブランチを統合(マージ)する際にスナップショットだと非常に作業が速くできます。

Gitがデータを差分というかたちで持っていると、ブランチを切ってマージする時に差分をいちいち計算しなければなりません。
しかしスナップショットで保存しておけば、差分の計算をしなくて済む分、とても速くブランチを切ったりマージできるようになります。

ちなみに、Git以前のバージョン管理ツールの多くは差分としてデータを保存していて、ブランチを切るのに大変時間がかかっていました。
大規模なプロジェクトになると数十秒かかったりすることもありました。
Gitだとこの作業が一瞬でできます。こういった事情があって、Linuxの作者のリーナス・トーバルズは
当時、大規模開発であったLinuxカーネル開発のバージョン管理システムを自作しました。これがGitのスタートです。
939 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:56:37.48 ID:646uiMLL0.net]: >>886
ああなるほど、ブロックチェーンよろしく親のhashデータも自分のhashに入ってるのか。
しかしそれは、改竄がばれるだけで、リンクを繋ぎ直すことが出来ないわけではないね。

というかね、それは本体ツリーの話で、
余分なcommitはrepoから消せ！とする君らにとっては問題だが、
俺みたいに、スカスカのINDEXでbranchを再構成するのはその場合にも全く問題ないはず。

ところで、
実は今もbranchの実体がどこにあるのか見えてない。
見る限り .git/logs/refs/heads/各branchにしかなさそうなのだけど、ここかね？
これだと毎回reflogを動的に解釈することになるが。
実装としておかしくはないが、普通はこうはしないので、ちょっと不可解だ。
なおオブジェクトツリーにはbranchのデータは無く、branchは各オブジェクトへのリンクの入った配列だと見てる。
だからシャローコピーでしかなく、後からでもいくらでも作れるだろ、という話。
940 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 19:03:07.94 ID:5Oe/8sYX0.net]: > 後からでもいくらでも作れるだろ、という話。
だから速度重視だって言ってる
941 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 19:03:54.30 ID:5Oe/8sYX0.net]: >>898
君、ほんと知らないなら黙ってたほうがいいよ
恥ずかしいだけだから
942 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 19:05:11.02 ID:5Oe/8sYX0.net]: >>898
> 余分なcommitはrepoから消せ！とする君らにとっては問題だが、
余分なコミットじゃなくて、
コミットとして使えないものにする
バグコミットを消せと言ってるだけ
943 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 19:21:59.71 ID:zDjINlW+0.net]: >>898
まあもう面倒臭くなってきたので全部説明しちゃうが
結果的に親のhashが自分のhashに含まれることになるのだけど、実際には親のhashは自分のコミットオブジェクトに含まれている
その自分のコミットオブジェクトから計算して求めるのが自分のhash
親の祖先に変更があれば自分のコミットオブジェクトの作り直しになってhashも計算し直すことになりそれはもう自分ではない

ブランチの実体はコミットオブジェクトのハッシュひとつだけ
それで事足りる
ず～～～と思っているんだがどう考えてもお前のブランチへの理解はオカシイ
内部的な構造の話ではなくてユーザとして使う上でも問題があるような酷い理解に見える
だから >>815 みたいな謎発言がでてくる
DBのINDEXみたいなもの？とかの謎解釈で突き進まれてもついていけない
944 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 20:06: ]: [ここ壊れてます]
945 名前：13.91 ID:646uiMLL0.net mailto: >>902
前半の内容は知ってるし、そのつもりで898を書いてる。
それはtutorial2に書いてあったから。
そこのhash値も混ぜてるかどうかは関知してなかっただけ。

ちなみにtutorlal2には「ここのhash値とは違うから、各自のhash値をコピペしてね」
と書いてあるが、実際は同じhash値が生成される。
だからどこまで混ぜ込んでるのかよくわからなった。
名前と時間も混ぜ込んでるぜ！と書いてあるが、どう見てもそうじゃない。
ただまあ、親ハッシュは混ぜ込んでるのは理解した。

> ブランチの実体はコミットオブジェクトのハッシュひとつだけ
それは俺の最初の理解、「点」なんだよ。815の通り。エントリポイントだけ、というわけだろ。
ただそれだと、オブジェクトツリーは辿れるが、
master @{1}で「master branch上の」一つ前、という経路情報に変換することが出来ない。
つまり、HEAD~! != @{1} とするには、何らかの情報が何処かに必要なんだよ。
そして今のところ、reflogしかないので、そこを動的に辿ってるのか？みたいなことになってる。
だから「reflogを偽造」(843)なんて話になる。

言い換えると、エントリポイントからだと、親は辿れるが、
親が複数現れたとき(マージ）に、どちらから来たのか分からないのと、
fast-forwardマージでオブジェクトは一本道でもbranch上では飛ばしている場合に、その情報がないんだよ。
これはどこに格納されてるんだ？ []: [ここ壊れてます]
946 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 20:19:07.74 ID:646uiMLL0.net]: すまん、分かると思うが、 HEAD~1 != @{1}
947 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 20:45:45.41 ID:zDjINlW+0.net]: >>903
reflogのhashは、HEADが変わるような操作をしたときに、その操作の結果のHEADのhashを追記していくだけのログだよ
このログがその後のgitの動作に影響を与えることはない
HEAD@{0}が常に最新の操作に対応したhashに更新される
だからたとえばmasterとfirstという二つのブランチを交互にcheckoutすればこんな感じになる

$ git reflog
0956cde (HEAD -> first) HEAD@{0}: checkout: moving from master to first
be7e7d7 (master) HEAD@{1}: checkout: moving from first to master
0956cde (HEAD -> first) HEAD@{2}: checkout: moving from master to first
be7e7d7 (master) HEAD@{3}: checkout: moving from first to master
0956cde (HEAD -> first) HEAD@{4}: checkout: moving from master to first
be7e7d7 (master) HEAD@{5}: checkout: moving from first to master

最後にcheckout firstしたので HEAD -> first になってる
948 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 20:59:53.75 ID:646uiMLL0.net]: >>905
reflogがその形式なのは知ってる。

ただ、頭のポイントだけだと、903で言ったとおり、経路情報にならないだろ。
例えば、815の場合、再記するが、

impl5@feature5, merged to develop and master, add tag of "Version1".
impl4@feathre4
impl3@feature3
impl2@feature2, merged to develop, add tag of "Version0".
impl1@feathre1
impl0@feature0
initial@master, develop

これで、master上で
git diff @{1}　では、initial commit との差分
git diff HEAD~1　では、　impl4との差分が出るんだよ。
これが、master->impl5のエントリポイント情報だけだと出来ないから、
maseterはinitial->impl5に移動しましたよ、という経路情報が何処かに必要なんだ。
それで、git reflog では、
どこにswitchして、commit して、mergeした、という履歴が全部出るから、
（多分だが各HEADのreflogを全てcatして時系列にソートしてる）
解釈すれば可能ではあるけど、そんな面倒なことするか？普通はstaticにシャローコピーだろ、というのと、
reflog は gc されるので、reflogを頼りにする実装は不適切だし、
俺的にbranchを消したり復活させたりする使い方はヤバそうなんだよ。
だからその辺を確認してる。
それで、後で任意のオブジェクト群でbranchを作れるのなら、この辺心配ないのだけど、そうではなさそうだし。
949 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 21:04:51.93 ID:646uiMLL0.net]: ちなみに、843の記事では、Git内のcontrib内のスクリプトが、
branchをreflogを参考に復活させるらしいので、reflog内の情報で足りてはいるらしい
950 名前：。 確かに目で見た限りそうだが、 でもそれだとreflogをgcするのは割と狂気の沙汰だから、おかしいよなーと思ってて。 []: [ここ壊れてます]
951 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 21:06:47.08 ID:646uiMLL0.net]: ごめん、書き方が悪かった。

907は、gc対象となるreflogを本番情報として持つのは狂気の沙汰だなーということ。
復活させるときにそこにしか手がかりがないのは仕方ないとして、
生きてるbranchは普通はツリー情報をstaticに持ってるはずだが、見あたらないんだよ。
952 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 21:15:14.62 ID:zDjINlW+0.net]: >>906
そのリポジトリがどういう構造になっているかわけわからん
git show-branch してみろ
953 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 21:26:43.61 ID:646uiMLL0.net]: >>909
すまぬ、確かに今見てればちょっとおかしい。
もう一度作るから30分ほどお待ちを。
954 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 21:51:56.84 ID:646uiMLL0.net]: >>909
結果
$ git show-branch
! [develop] impl5
* [master] impl5
--
+* [develop] impl5

$ git branch
develop
* master
955 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 21:52:24.93 ID:646uiMLL0.net]: >>909

$ git diff HEAD~1
diff --git a/test.txt b/test.txt
index 3585d98..bbddc42 100644
--- a/test.txt
+++ b/test.txt
@@ -4,3 +4,4 @@ impl1
impl2
impl3
impl4
+impl5

$ git diff @{1}
diff --git a/test.txt b/test.txt
index e79c5e8..bbddc42 100644
--- a/test.txt
+++ b/test.txt
@@ -1 +1,7 @@
initial
+impl0
+impl1
+impl2
+impl3
+impl4
+impl5
956 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 21:53:21.88 ID:646uiMLL0.net]: >>909
再現コード

#!/bin/bash -x
#

git init
echo 'initial' > test.txt
git add test.txt
git commit -m 'initial'
git branch develop

for (( i=0 ; i<6 ; i++ ));
do
git branch feature$i
git switch feature$i
echo "impl"$i >> test.txt
git add test.txt
git commit -m "impl"$i
git switch develop
git merge feature$i
git branch -d feature$i
done

git switch master
git merge develop
957 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 22:01:15.70 ID:646uiMLL0.net]: >>909
ちなreflog

$ git reflog
1a804d9 (HEAD -> master, develop) HEAD@{0}: merge develop: Fast-forward
b0325fc HEAD@{1}: checkout: moving from develop to master
1a804d9 (HEAD -> master, develop) HEAD@{2}: merge feature5: Fast-forward
ba4e962 HEAD@{3}: checkout: moving from feature5 to develop
1a804d9 (HEAD -> master, develop) HEAD@{4}: commit: impl5
ba4e962 HEAD@{5}: checkout: moving from develop to feature5
ba4e962 HEAD@{6}: merge feature4: Fast-forward
a32e11d HEAD@{7}: checkout: moving from feature4 to develop
ba4e962 HEAD@{8}: commit: impl4
a32e11d HEAD@{9}: checkout: moving from develop to feature4
a32e11d HEAD@{10}: merge feature3: Fast-forward
8d9924f HEAD@{11}: checkout: moving from feature3 to develop
a32e11d HEAD@{12}: commit: impl3
8d9924f HEAD@{13}: checkout: moving from develop to feature3
8d9924f HEAD@{14}: merge feature2: Fast-forward
0f78740 HEAD@{15}: checkout: moving from feature2 to develop
8d9924f HEAD@{16}: commit: impl2
0f78740 HEAD@{17}: checkout: moving from develop to feature2
0f78740 HEAD@{18}: merge feature1: Fast-forward
47792a3 HEAD@{19}: checkout: moving from feature1 to develop
0f78740 HEAD@{20}: commit: impl1
47792a3 HEAD@{21}: checkout: moving from develop to feature1
47792a3 HEAD@{22}: merge feature0: Fast-forward
b0325fc HEAD@{23}: checkout: moving from feature0 to develop
47792a3 HEAD@{24}: commit: impl0
b0325fc HEAD@{25}: checkout: moving from master to feature0
b0325fc HEAD@{26}: commit (initial): initial
958 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 22:02:09.13 ID:646uiMLL0.net]: >>909
ついでに一応、終了時のtest.txt

$ cat test.txt
initial
impl0
impl1
impl2
impl3
impl4
impl5
959 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 22:05:21.84 ID:zDjINlW+0.net]: >>911-915
これ全部FFマージやってるから結果的にdevelopブランチとmasterブランチが同じものになるぞ
960 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 22:09:56.21 ID:zDjINlW+0.net]: mergeを全部merge --no-ffにするとマージした構造がわかるようになるし、最後にdevelopとmasterが別のものになる
どっちのマージにするかは現場の運用しだい
961 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 22:10:47.10 ID:zDjINlW+0.net]: git log --graph --branches --oneline とかするとわかりやすい
962 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 22:11:46.51 ID:646uiMLL0.net]: >>916
ああ、それがrebaseしないと履歴が無くなるとかいう話か？
実はそれはまだ確認中だが、とりあえず本件についてはこれでいいし、
俺的には多分こうなる。(基本的にmasterはdevelopの後を追うだけ)
けしか�
963 名前：轤ｩ？ それはさておき、本件、HEAD~1 と @{1} が違うものだという経路情報は、 どこにあるのか分かれば教えてくれ。 []: [ここ壊れてます]
964 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 22:22:33.37 ID:zDjINlW+0.net]: HEAD~1と@{1}は全然関係無いよ？
HEAD~1は今のHEADの一番目の親のhash
親が複数いるときにはHEAD^1とかHEAD^2とかで指定する
@{1}はひとつ前の操作によってHEADになったhashだから、どういう操作したかで変わり、リポジトリの構造とは関係無い
965 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 22:30:34.81 ID:zDjINlW+0.net]: >>914 で説明すると、
@{0}は最後のコミットで、FFマージした結果masterとdevelopがこのhash=1a804d9になった
@{1}はgit commit -m 'initial'の結果できた最初のコミット(最後のマージ操作の前のmaster)で、最後にこれにdevelopをマージするためcheckoutしたらこれになってる
966 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 22:35:17.82 ID:646uiMLL0.net]: >>920
> @{1}はひとつ前の操作によってHEADになったhashだから、どういう操作したかで変わり、リポジトリの構造とは関係無い
だから、それは「そのbranchの」一つ前の操作なんだよ。
結果、diffは、masterブランチでは>>912で、HEAD~1 != @{1} だが、
developブランチでは、以下になって、 HEAD~1 == @{1}　なんだよ。

$ git diff HEAD~1
diff --git a/test.txt b/test.txt
index 3585d98..bbddc42 100644
--- a/test.txt
+++ b/test.txt
@@ -4,3 +4,4 @@ impl1
impl2
impl3
impl4
+impl5

$ git diff @{1}
diff --git a/test.txt b/test.txt
index 3585d98..bbddc42 100644
--- a/test.txt
+++ b/test.txt
@@ -4,3 +4,4 @@ impl1
impl2
impl3
impl4
+impl5

だからmasterブランチをdevelopにmergeしかしない運用をした場合、
masterブランチは @{n} でn回前のリリースが検索出来、存在価値が出てくる、という見立てだが、間違ってるか？
(@はcommit履歴だと思ってるが、まさか操作履歴か？なら確かに意味無いし、先頭情報しか要らないし、reflogしかなくても納得だが)
967 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 22:40:04.85 ID:zDjINlW+0.net]: 最終的にお前のリポジトリは git merge develop でこうなっているはずだ

$ git log --graph --branches --oneline
* 1a804d9 impl5 (HEAD -> master, develop)
* xxxxxxx impl4
* xxxxxxx impl3
* xxxxxxx impl2
* xxxxxxx impl1
* xxxxxxx impl0
* b0325fc initial

最後のひとつ前の git switch master をやったときにはこうなっていたはず
* 1a804d9 impl5 (develop)
* xxxxxxx impl4
* xxxxxxx impl3
* xxxxxxx impl2
* xxxxxxx impl1
* xxxxxxx impl0
* b0325fc initial (HEAD -> master)

だから HEAD@{0} = 1a804d9 で、HEAD@{1} = b0325fc
968 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 22:46:20.49 ID:646uiMLL0.net]: >>921
@はやっぱcommit履歴だよな？

エントリポインタだけだと、commit履歴に出来ないんだよ。
今回はfast-forwardマージしてるから、

init<-0<-1<-2<-3<-4<-5 = master, develop

で、単にエントリポイントだけなら master も develop も同じ 5 で区別がない。
当たり前だが両方とも HEAD~1 は4を指してる。
ただ、@{1}は、commit履歴だから、masterでは init を指し、developでは4を指す。
この、commit履歴情報はどこに記録されてるの？というのが俺の質問。

>>923
そこは理解出来てるはず。上記の通り。
問題はcommit履歴がどこにあるか。
969 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 22:50:12.27 ID:zDjINlW+0.net]: >>922
masterブランチをdevelopブランチにマージする方法が
git switch masterとgit merge developの連続実行だけではないし、
HEAD@{n}は適当なタイミングでGCされるから、
HEAD@{n}をそんな用途に使う奴はいない
970 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 22:52:10.49 ID:zDjINlW+0.net]: >>924
commit履歴がどこにあるか説明するのに使いたいから、git log --graph --branches --oneline してくれ
971 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 22:54:11.54 ID:zDjINlW+0.net]: @はcommit履歴じゃなくて、reflogの履歴
972 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 22:57:39.34 ID:646uiMLL0.net]: >>926
$ git log --graph --branches --oneline
* 1a804d9 (HEAD -> master, develop) impl5
* ba4e962 impl4
* a32e11d impl3
* 8d9924f impl2
* 0f78740 impl1
* 47792a3 impl0
* b0325fc initial
973 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 23:01:41.48 ID:zDjINlW+0.net]: @{n}はカレントブランチのreflog履歴になるはず
reflog履歴はブランチ毎に存在するので
master@{n}とdevelop@{n}は違うハッシュになってるはず
git reflog masterとgit reflog developで比べてみればわかる
974 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 23:04:26.02 ID:646uiMLL0.net]: >>917,926
ちな --no-ff 版、
今出すと余計に混乱するかもだが。

$ git log --graph --branches --oneline
* a5aaf72 (HEAD -> master, develop) Merge branch 'feature5' into develop
|\
| * e03bcd0 impl5
|/
* 324df68 Merge branch 'feature4' into develop
|\
| * c2634c4 impl4
|/
* 68ed20a Merge branch 'feature3' into develop
|\
| * 5e12b99 impl3
|/
* 608e5d7 Merge branch 'feature2' into develop
|\
| * 4660e46 impl2
|/
* 3924eae Merge branch 'feature1' into develop
|\
| * 138d83f impl1
|/
* 7db4424 Merge branch 'feature0' into develop
|\
| * 8877414 impl0
|/
* ec041f9 initial
975 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 23:08:22.79 ID:646uiMLL0.net]: >>929
$ git reflog master
1a804d9 (HEAD -> master, develop) master@{0}: merge develop: Fast-forward
b0325fc master@{1
976 名前：}: commit (initial): initial $ git reflog develop 1a804d9 (HEAD -> master, develop) develop@{0}: merge feature5: Fast-forward ba4e962 develop@{1}: merge feature4: Fast-forward a32e11d develop@{2}: merge feature3: Fast-forward 8d9924f develop@{3}: merge feature2: Fast-forward 0f78740 develop@{4}: merge feature1: Fast-forward 47792a3 develop@{5}: merge feature0: Fast-forward b0325fc develop@{6}: branch: Created from master ってことは、commit履歴はreflogにしか無いって事か？ ならbrahchを消すとreflogも消されてcommit履歴が消えるが、マジ？ これだとbranchの復活は本質的に無理なことになってしまう。 (他branchに断片的には残ってるんだけどさ） []: [ここ壊れてます]
977 名前：デフォルトの名無しさん [2022/11/05(土) 23:09:25.37 ID:zDjINlW+0.net]: >>928
impl5のコミットオブジェクトの hash = 1a804d9
impl5のコミットオブジェクトの中には親のコミットオブジェクトimpl4の hash = ba4e962 が格納されている
impl4のコミットオブジェクトの hash = ba4e962
impl4のコミットオブジェクトの中には親のコミットオブジェクトimpl3の hash = a32e11d が格納されている
impl3のコミットオブジェクトの hash = a32e11d
impl3のコミットオブジェクトの中には親のコミットオブジェクトimpl2の hash = 8d9924f が格納されている
impl2のコミットオブジェクトの hash = 8d9924f
impl2のコミットオブジェクトの中には親のコミットオブジェクトimpl1の hash = 0f78740 が格納されている
impl1のコミットオブジェクトの hash = 0f78740
impl1のコミットオブジェクトの中には親のコミットオブジェクトimpl0の hash = 47792a3 が格納されている
impl0のコミットオブジェクトの hash = 47792a3
impl0のコミットオブジェクトの中には親のコミットオブジェクトinitialの hash = b0325fc が格納されている
initialのコミットオブジェクトの hash = b0325fc
initialのコミットオブジェクトはルートなので親のコミットオブジェクトが存在しない

つまり impl5のコミットオブジェクトの hash = 1a804d9 からたどっていけば、コミット履歴が全部わかる
親が複数存在する場合には複数の親のhashを格納する
978 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 23:11:25.45 ID:zDjINlW+0.net]: >>930
￥で表示されるとちょっと見にくいが、慣れれば見やすい
979 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 23:14:09.84 ID:zDjINlW+0.net]: >>931
逆だ。コミットのつながりはコミットオブジェクトの中にしかない >>932 みたいにね
それを説明してるのが >>902
980 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 23:16:52.31 ID:zDjINlW+0.net]: >>930は最後のdevelopのマージが --no-ff になってないな
最後のも --no-ff にするともっと面白いぞ
981 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 23:18:09.46 ID:646uiMLL0.net]: >>932
ごめん、それは分かってる。
それはグローバル履歴＝gitオブジェクトを辿った履歴、だろ。

問題は、masterのcommitには b0325fc と 1a804d9 しかない、という情報が、
今のところ master の reflogにしか見あたらないんだよ。
だから、各branchを消したら、それ以前の gitオブジェクトは全部辿れるが、commit履歴は消失してしまう。
今のmasterみたいに、fast-forwardマージで中間をすっ飛ばしてきた、
という情報が無くなってしまうんだよ。
だから、branchを消す前の状態に完全には戻せない、という話。

だから、常識的に考えればもうちょっとましな何処かに保持してるはずなんだけど、無いんだ。
982 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 23:21:56.96 ID:646uiMLL0.net]: >>935
ほい
$ git log --graph --branches --oneline
* 2fb59f1 (HEAD -> master) Merge branch 'develop'
|\
| * 25e1b95 (develop) Merge branch 'feature5' into develop
| |\
| | * 4b27393 impl5
| |/
| * 9bfb8cc Merge branch 'feature4' into develop
| |\
| | * c2a5b7d impl4
| |/
| * 02d2308 Merge branch 'feature3' into develop
| |\
| | * f6d1cf7 impl3
| |/
| * 81e18bb Merge branch 'feature2' into develop
| |\
| | * 01c3871 impl2
| |/
| * 5b57f48 Merge branch 'feature1' into develop
| |\
| | * 0fe34d2 impl1
| |/
| * 6272da6 Merge branch 'feature0' into develop
| |\
|/ /
| * fe1b132 impl0
|/
* 832f464 initial
983 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 23:23:27.84 ID:zDjINlW+0.net]: >>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
984 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 23:26:10.78 ID:zDjINlW+0.net]: >>937 だとこう表示されるはず
$ git log --graph --branches --oneline --オプション忘れた探せ
* 2fb59f1 (HEAD -> master) Merge branch 'develop'
* 832f464 initial
985 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 23:35:28.93 ID:646uiMLL0.net]: >>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
986 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 23:41:19.40 ID:zDjINlW+0.net]: >>939がそう表示されるのは、--no-ff マージの手順が何か普通とちがうからかもしれん
>>939みたいに表示させるマージの手順もあるはずだから工夫してみるんだな
987 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 23:41:56.11 ID:646uiMLL0.net]: >>938
なるほど了解した。
データ側に混ぜ込んでて、保持したければ --no-ff で使えってことか。

そもそも同じハッシュなら同じgitオブジェクトにリンクするようになってるのだし、
(つまり見た目が膨らんでるだけで実際の容量は
988 名前：大して食わない） --no-ff がデフォのほうがよかった気がするが。 まあとにかく了解した。長々とありがとう。 []: [ここ壊れてます]
989 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 00:38:34.83 ID:UPUgwCSv0.net]: FFがデフォじゃなと使いにくい気がするのだがｗ
990 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) mailto:sage [2022/11/06(日) 09:32:37.27 ID:OfQ8ymDc0.net]: >>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はソースコード向けにしか出来てない、ということは認識しておくべきだろう。
991 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) mailto:sage [2022/11/06(日) 09:32:57.06 ID:OfQ8ymDc0.net]: あと、Gitのドキュメントは全般的によく出来ているが、branchは「線だ！」と言ってるのは不適切だ。
Gitのドキュメントは密結合状態、つまりGitをよく知ってる人向けに書かれているので、
同様に内部実装を見せる形で書くのが正しく、
つまり、「branchは『線』のように見せてますが、実は『点』です！」と言わないと誤解される。俺がそうだが。
これは解像度が統一されてないから起こった問題だ。
一般のマニュアルは疎結合状態、
つまりそのツールについて内部実装なんて全く知らないし知る由もない人向けに書かれるから、
『見た目』線であれば「線」とずっと言い張り、内部実装を曝露してはいけない。
この場合、あくまでユーザーから見たら常に「線」であり、内部がどうであれ「線」としてしか見えないから誤解を生む余地はない。
Gitの場合は内部も見せた上でドキュメントとして外面仕様も説明することになってて、
それが外面仕様なのか内部実装なのか、
またbranchのように外面仕様と内部実装が�
992 名前：ﾙなってて隠蔽しきれてない場合とか、(--no-ffの有無で観測可能) それは正しく説明しなければならない。 密結合なら、上記の通り、「『線』として見せてますが実は『点』です！」と書くべきだ。 とはいえ全般的にドキュメントはしっかり書かれている。これ自体は素晴らしい。 ただ、そもそも仕様がグダグダ過ぎるし、 或いはユーザーにどこまで見せ、どこからは見せないのか、仕様を管理する感覚がまるでない。 おそらく上層部の連中に仕様管理の経験者がおらず、グダグダになってしまってる。 とはいえ、再度言うが、ドキュメントはよく書いてる方だよ。 []: [ここ壊れてます]
993 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) mailto:sage [2022/11/06(日) 09:33:22.07 ID:OfQ8ymDc0.net]: ただこれだと、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履歴も大切に考える奴だったら違ってたが、惜しいね。
994 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 10:57:26.83 ID:FBkt/oHG0.net]: 長々と無駄な長文と大量投稿でスレを穢すんじゃねー。
単に既存のバージョン管理ツールと、git の考え方の違いが理解できてないだけじゃねーか。
・git はパッチ管理ツール、作業履歴管理ツールじゃない。
・ソフトウェアはパッチとパッチを当てる順番で構成されている。
1000回唱えろ。この思想が気に要らなければそもそも git 使うな。
995 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 10:59:15.02 ID:OfQ8ymDc0.net]: >>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).
996 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 1 ]: [ここ壊れてます]
997 名前：1:04:28.51 ID:OfQ8ymDc0.net mailto: >>947
> ・git はパッチ管理ツール、作業履歴管理ツールじゃない。
ああ非常に納得出来る。Gitはmerge特化型だ。
確かにそれを日々の業務(非merge)に使おう、というのがフィットしないんだろうよ。

しかし世の中の一般人のGitの使い方は後者だろ。 []: [ここ壊れてます]
998 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 11:33:11.11 ID:sj15aRfA0.net]: ということにしたいのですね。
999 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 11:46:16.67 ID:FBkt/oHG0.net]: >>949
お前の狭い世間なんて知るか
お前は話題の電動ドリル買ってきて釘打つのに不便ガンガンってやりながら文句言ってるのと同じレベル
そもそもマニュアルもちゃんと読めてないだろ。root と route を間違える英語レベル
背伸びして git 学ぶ前に高校に進学して英語学んだ方が近道だぞ
1000 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 11:51:22.62 ID:OfQ8ymDc0.net]: >>950
いや事実だよ。
Linusは確かにmergeしかしないんだろうけど。

だけどその、mergeするパッチを書く奴は、それを一発で書けたわけがないんだ。
何日もかけて、何回も直して、そこに到達してる。
この過程のサポートがGitにはない。
別branchで作業してもmerge時にhash値が組み込まれるから、
確かに俺がやろうとしてる「日々の進捗」をcommitされると除去出来ずウザイんだろうさ。
しかしパッチのコードは必ずGit-repoをクローンしてから出発するのだから、
Gitにこのサポートが無く、パッチを当てる人はいきなり完成したパッチを書け！勿論でバッグ済みだぞ！みたいな構造なのがおかしい。
すくなくとも、捨てbranch機能があって、そこで日々の作業を終わらせた結果、
mergeするときには本ブランチでその結果がいきなり生えたように見せる機能
(捨てbranchとmergeしても中身の結果だけもらって親にはしない）
みたいな機能が必要なんだよ。
ただまあ、これは今でも手動だと出来た気はするが。

だからまあ、確かにパッチ管理ツールであって、
ソフトウェア開発時のバージョン管理ツールではないんだろうさ。
だけど、今、全世界のGitで、mergeコミットと通常のcommit、どっちが多いか考えれば、自明だろ。
一つのパッチを作るまでにも何回もcommitが必要なのだから。
1001 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 12:07:06.70 ID:FBkt/oHG0.net]: >>952
アホか。共同開発が全く理解できてねーじゃねーか。
お前の試行錯誤の記録を push しようとしてんじゃねーよ。
手元で試行錯誤して実装できたら、それを元に綺麗なパッチに書き直す作業するんだよ。
そして完成した綺麗なパッチ群のみを共有リポジトリに公開するんだよ。
1002 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 12:19:51.48 ID:OfQ8ymDc0.net]: >>948
一応見つけた。 git worktree らしい。
複数のbranchを同時に開く機能で、DBで言うATTACHっぽい。
1003 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 12:20:57.36 ID:JyiC8cnE0.net]: 試行錯誤はすべて記録に残すべき
→じゃあテキストエディタで保存するたびに記録するべきっていうのか？

こういう話なので無視すんなよ？ｗ
1004 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 12:21:44.03 ID:JyiC8cnE0.net]: バージョン管理はソースコードの変更履歴を残すのであって
作業履歴を残すものじゃないっていうのが分かってなさすぎ
1005 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 12:30:26.14 ID:OfQ8ymDc0.net]: >>953
それはいいんだけどさ、その肝心のパッチを書く人へのサポートがまるでないだろ。
出発点がgit clone で、その上で作業して、終われば pull request する前提なのにさ。

そしてOSSではなく一般企業等で使ってる奴は、
当たり前だが日々の作業のバックアップや巻き戻し出来るシステムが必要で、そう使ってる。
だから、Gitが難しすぎるというのは、目的外使用だから意味が分かりにくい、というのはあるね。
Indexもマージの時には�
1006 名前：�った方が便利なんだろうしさ。(ただのcommitには邪魔でしかない） しかし確かに、Linusに言わせれば、全く問題ないんだろうさ。彼はmergeしかしないしね。 そして他のVCSよりまし、という理由でGitを使う奴は、混乱するんだろうさ。VCSと聞いてきたのだからね。 確かにパッチ管理システムだよGitは。ソースコード生成時のサポートシステムではない。 []: [ここ壊れてます]
1007 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 12:32:16.81 ID:OfQ8ymDc0.net]: >>955
> こういう話なので無視すんなよ？ｗ
無視する/しない以前に、何が言いたいのか分からないから反応しようがないんだよ。
1008 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 12:42:58.45 ID:sj15aRfA0.net]: >>957
> それはいいんだけどさ、その肝心のパッチを書く人へのサポートがまるでないだろ。
rebase あるよ。
元のローカルブランチを消さないでおけば記録もぜんぶ残るし。よかったね。
1009 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 12:43:13.14 ID:FBkt/oHG0.net]: >>957
git ほどパッチを書くのに向いてるツールは他にないぞ。
index 無しでどうやってパッチの分割とかするんだよ？
1010 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 12:53:16.71 ID:OfQ8ymDc0.net]: >>960
最初から一つずつ書けば分割の必要ないし、
Index無くてもdiffの出力を絞ってpatchに食わせれば普通に分割出来るだろ。
1011 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 13:02:38.08 ID:JyiC8cnE0.net]: >>958
書いてあるとおりじゃん。
試行錯誤の履歴を全部取れというなら、テキストエディタで保存するごとに
gitでコミットしなければならないはずだ
お前の主張はそういうことなんだから、それをちゃんとやれってこと
1012 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 13:04:02.78 ID:JyiC8cnE0.net]: >>961
コミットがメチャクチャなのに、どうやってdiffとってパッチできると思ってるの？
そのdiffには関係がない修正が大量に入ってるだろ
1013 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 13:37:22.28 ID:FBkt/oHG0.net]: >>961
なんも分かってないことを露呈しているな。
A,B,C,D,Eとコミットした後に Cはc1,c2,c3に分割すべきで、BとEは一つにすべきで、Aは不要だったと気づいたらどうすんの？
こういうのがお手軽にできて綺麗なパッチ群に整理できるのがパッチ管理ツールである git の利点なんだ。
そういうのやったことないだろ？
1014 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 13:39:49.06 ID:az1H5JFk0.net]: >>954
脊髄反射で理解したつもりになって書いてるだろ正解率が著しく低い

git worktreeは一つのリポジトリに追加のワークツリーを用意して、異なるブランチをそれぞれ別のワークツリーにcheckoutできるようにする機能
DBのATTACHとは全然違う

マルチルートは普通に作ったリポジトリをfetchやpushで合成してmerge --allow-unrelated-historiesすればできる
でもこれはかなり特殊な用途に使うもので普段使いするようなものではない
1015 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) mailto:sage [2022/11/06(日) 13:46:46.96 ID:OfQ8ymDc0.net]: >>965
実は今し方ドキュメント読んで、これは違うと書こうとしたところだった。
wor,ktreeはstashの代わりで、同時作業用ではないね。

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

まあ、もう地味に.git/.xxx/に転がそうと思案中。
1016 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 13:57:15.91 ID:OfQ8ymDc0.net]: >>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 もある。
だからパッチの分割はすぐ出来るんだよ。
1017 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 14:05:27.55 ID:az1H5JFk0.net]: >>967
そういう作業を必要で
1018 名前：無くすためにgitが生まれた patchの提出をgitの分散リポジトリ上で可能とするためにね 963とか964が行ってるpatchというのは、いわゆるpatchファイルのことではなく、ブランチ上に存在する差分の事 そのpatchを整理するのに index や rebase がある []: [ここ壊れてます]
1019 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 14:19:49.14 ID:FBkt/oHG0.net]: もしかして、もしかすると、git では「パッチ＝コミット」っていうことすら理解できてないのだろうか。
まさかそんな人はいないよね。単に言動が変な人なだけだよね。
1020 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 14:25:32.34 ID:OfQ8ymDc0.net]: >>968
知ってるよ。

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

なお俺は
> ブランチ上に存在する差分の事
も所詮はdiffだ、という立場だよ。だから元のunixコマンドで何とでもなるし、
それをシェルスクリプトで集大成したのが初期Gitだろ。
1021 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 14:31:58.60 ID:FBkt/oHG0.net]: >>970
ちがうぞ。最初からパッチ管理ツールとして設計されるぞ。
そしてパッチ管理ツールなんだから、パッチの出力機能さえあれば良いんだぞ。
それ以外の差分が欲しかったら別の外部ツール使えば良いんだぞ。それこそ基本だろ
1022 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 14:33:28.64 ID:OfQ8ymDc0.net]: >>969
各commmit「点」でdiff取ったときに落ちる情報って何？
ああcommitメッセージか？そんなのは知らんし要らんよ、って立場。

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

ソースコード読める奴ならこんな言い訳効かないんだよ、何でお前が上にいるんだ！監督する為だろ！になる。
さすがに素通しはヤバい。
そしてどう見てもヤバいパッチを素通ししてるから、なんじゃあこりゃあ？ってなってる。
1023 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 14:36:33.55 ID:OfQ8ymDc0.net]: >>971
ああそれが diff のデフォルト出力をさせない理由だな。
651から一周回ったが、なるほど色々状況は理解出来たよ。賛同はしないが。
1024 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 14:45:12.77 ID:FBkt/oHG0.net]: >>972
だからお前の考えてるような作業履歴管理ツールじゃないんだから、あきらめて他所へ行け。
gitはパッチ管理ツール。そしてパッチは何時、誰が、何のために作成したかが重要情報なんだよ。それを管理してるんだよ。
ソースコードの保管するツールじゃねーぞ。
1025 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 14:49:22.34 ID:OfQ8ymDc0.net]: >>974
そこは違うんだな。
みんな結局自分でやるのも作るのも面倒だから、既に動いてるツールを使ってるだけだよ。
Gitの機能のサブセットで十分にカバー出来るのなら、Git使えばいいだけ。
1026 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 14:56:19.71 ID:OfQ8ymDc0.net]: >>974
だからな、前言ったように、ブッ込んでおけば後で取り出せるバケツでしかないんだよ。
そのバケツにゴテゴテ付いてるから難しそうだが、要らない機能は使わなければいいだけ。
ただ、履歴保持の範囲を知らずに使って、実は記録されていませんでは困るから、使う前に調べてる。
1027 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 15:45:34.08 ID:o7v4FvnP0.net]: https://www.praha-inc.com/lab/posts/commit-message

そもそもコミットメッセージは何のためにあるのでしょうか？

コミットログのうちコードの変更履歴には「コードをどのように変更したか」という情報が含まれていますが、「コードを何故変更したのか」という情報はコミットメッセージを読まないと分かりません。機能追加、バグ修正、パフォーマンスのためなど、変更した理由は様々なものが考えられます。

もちろんコードを変更した本人に聞けば変更した意図はわかると思いますが、変更した本人にいつ�
1028 名前：ﾅも聞ける状況であるとは限りません。 「何故コードを変更したのか」という情報が欲しい時のためにコミットメッセージが存在します。 加えて、コミットメッセージは基本的に他人が読むものです。 他人というと同僚やコントリビューターなどが挙げられると思いますが、この「他人」には未来の自分も含んでいます。自分が書いたコミットメッセージを数ヶ月先の自分が読む場合、過去の自分のコミットメッセージを未来の自分が読むことになります。 つまり、コミットメッセージは自分以外の人のために存在するのです。 []: [ここ壊れてます]
1029 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 15:52:02.65 ID:az1H5JFk0.net]: まあこいつは分散バージョン管理の難しさを理解できていない
一人でしかプログラム組んだことがないのだろう
gitのややこしいと感じる仕様のほとんどは分散リポジトリ管理に起因していて、分散リポジトリ管理の問題をできるだけ明示的にシンプルに解決しようという意図で設計されている
1030 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 15:55:03.47 ID:JyiC8cnE0.net]: ほんとなぁ、POSIX原理主義だからユニケージだかUSP研究所だかしらんが
例のあいつも、バージョン管理のツールを、バックアップツールとしてしか考えてねぇ
だからとりあえずファイルを入れておけば差分はdiffで見れるだろとか
訳のわからんことを言い出す

ある時点とある時点の差を見たいんじゃねーんだよ
ある修正にどのような差分があるかを記録＝コミットしたいわけで
その記録なしに差分だけみれても役に立たないっつーの
そこが根本的に違うというか、バージョン管理の役目がわかってない
1031 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 16:10:07.15 ID:az1H5JFk0.net]: 「ブッ込んでおけば後で取り出せるバケツ」など言っているが、
必要とされていたのは内容を同期できる複数のバケツで、
なおかつバケツ同士が常にオンラインで通信しているわけではない
そういう問題に取り組んだ結果だ
1032 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 16:12:28.94 ID:az1H5JFk0.net]: そういう魔法のバケツを生み出すために、ただのバケツならできることがgitでは制限されていたりもする
ユーザから見て不自由のない完全な魔法のバケツを生み出そうとしたプロジェクトは複雑すぎてことごとく失敗してきた
1033 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 16:14:37.71 ID:JyiC8cnE0.net]: バケツの中に入っている袋詰めの塩や砂糖を、一つづつ取り出したいのであって

バケツの中に全部入ってるから、遠心分離機でも使って
取り出せばいいだろうじゃないんだよなｗ
1034 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 16:36:01.68 ID:az1H5JFk0.net]: 前スレは消費に1年半かかってるのに、このスレは半年ぐらいで終わりだな
次スレ立ててみるけど失敗したらゴメン
1035 名前：デフォルトの名無しさん [2022/11/06(日) 16:41:37.94 ID:az1H5JFk0.net]: 次スレ
Git 19
mevius.5ch.net/test/read.cgi/tech/1667720427/
1036 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 19:18:45.16 ID:OfQ8ymDc0.net]: 相変わらずお前ら盛大に勘違いしてるが、とりあえず、

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

としよう。管理は出来てない。何を管理すべきか分かってないから。
commitメッセージなんてただのラベルに過ぎない。
1037 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 19:19:20.86 ID:OfQ8ymDc0.net]: 例えば今回俺が送った再現コード、あれはどこに配置されるのだ？
>>977の通り、「何故この変更を行ったのか」の完全情報がそこにある。
まさか捨てたりしないよな？

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

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

だ。どんなに丁寧にcommitメッセージを書いたところで、「それ、あなたの感想ですよね？」でしかない。
肝心なところを書き間違ってるかもしれないし、信用も出来ない。
この点、再現コードは情報が完全で、全ての情報を過不足無く含んでいて、曖昧さもない。
だからcommitメッセージの情報価値なんて再現コードと比べたらゴミ以下で、
再現コードに対してのリンクで十分なんだよ。つまり、

○年○月○日に○○から送られてきた○○のバグ(メモリリーク
1038 名前：)を修正する。 詳細はXXXX で、XXXXのところ、Git流ならSHA1ハッシュで、 その中に再現コードと詳細、今回なら全員のメールの全文を入れておくのがバグ管理だよ。 これで、「何故この変更を行ったのか」の完全情報が保たれる。 そして、再現コードは今後ずっとregressionテストに使う資産にする。 そうすれば、少なくとも過去と同じバグはリリース前に見つかる。 []: [ここ壊れてます]
1039 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 19:20:02.27 ID:OfQ8ymDc0.net]: こうなってないだろ。一回パッチ当てて動きました！満足です！じゃないんだよ。
繰り返すが、commitメッセジーをいくら丁寧に書いても意味無い。
再現コードに比べたら本当にゴミ以下。
逆に、再現コードに辿り着けるのなら、後はラベルが正しく付いてれば十分なんだ。
それ以上の情報は、commitメッセージのテキストではなく、
再現コードとバグ報告＝完全情報を見た方がいいから。

で、GitHubはまあこれに近いよ。
そもそもバグ報告自体Webだし、少なくともIssueからバグの完全情報に当たれる。
Gitはどうなの？
今回の俺と同様の、過去のバグ報告の再現コードを生かせてるのか？
ならそういうディレクトリがあって、
bug_patches/XXXXXなハッシュが名前になってるディレクトリに再現コードその他がブチ込まれてて、
出荷前(というのもおかしいが)には全部一通り通せ、となってるはずだけど、
どう見てもそうなってないでしょ。
パッチ当てたから満足です、で終わってる。

こんなのでバグが収束するはずがない。
同じ連中が書いてるのだから、放置したら同レベルのバグを繰り返す。
だから本来は何故こんなバグが発生したのか？からコード構造を見直して、
そもそもそうならないようにするのだけど、そういう学びもないし、(だから基本すら出来てない)
regressionテストのネタにもしないのだから、今後ともバグだらけだよ。
ああ、Gitの達人揃いだから、「記録」は出来てるのだろうよ。だけどそれは「管理」ではない。

ただ、これがバザール流だ！と来るなら、はーそうですかー(棒)だよ。
目も手も数が違うし、俺には何が最適か分からんし。
1040 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 19:20:37.38 ID:OfQ8ymDc0.net]: ちなみにchromeの連中は気持ち悪いほどregressionテストしてるぞ。
本来は、ああするべきなんだろうよ。
regressionテスト自体はタダ(スクリプトで自動実行)だからね。

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

分かりやすく言うとな、「体調管理」と言われれば、少なくとも同じ原因で風邪を引かないようにするだろ。
なら、「バグ管理」なら、最低限レビューしてregressionテストしないと駄目だよ。
それはcommitメッセージ云々では出来ない。だからパッチ「適用」「記録」ツール。
1041 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 19:24:47.08 ID:VM2X6i580.net]: >>985
> commitメッセージなんてただのラベルに過ぎない。

その言葉からお前がわかってないのが明らかなんだけど？
1042 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 19:26:23.98 ID:VM2X6i580.net]: >>988
うん。だからそのchromeはここまで徹底してコミットを管理してる
それを見習え
https://github.com/chromium/chromium/commits/main
1043 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 19:27:42.33 ID:VM2X6i580.net]: regressionする際にもコミットを管理するのは重要で
コミット単位で戻してテストする
動かないコードをコミットすることはない
お前みたいにテキストエディタで修正するたびにコミットとかしない
1044 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 19:28:57.43 ID:VM2X6i580.net]: なんでchromeのコミットメッセージが
こんなに詳しく書かれているのか、その理由を考えたら？
1045 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 19:32:31.47 ID:VM2X6i580.net]: バージョン管理はソースコードの変更履歴を管理するものなので
そこにバグ管理という別の概念を持ち出すのも頭悪い
バグ管理は別のツールでやれ
1046 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 19:55:47.23 ID:sj15aRfA0.net]: >>986
> 例えば今回俺が送った再現コード、あれはどこに配置されるのだ？
修正コミットのログから URL で辿れるようになるかな。
https://public-inbox.org/git/20221102220142.574890-2-szeder.dev@gmail.com/
1047 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 20:08:52.18 ID:OfQ8ymDc0.net]: >>994
それは鯖に置いてるだけだろ。まあそれはそれで十分で、（この意味では最初のMLでも十分)
問題は、

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

だよ。
レイヤーの考え方がない奴等ばかりなので通じないかもしれないが、
gitは適用/記録という下層レイヤーであって、バグ/パッチ「管理」は上位レイヤーの戦略だから、
gitで「管理」出来ると思ってるのが間違いなんだよ。記録は出来るが、管理は出来ない。
gitで出来るのは上の1だけだね。
だからcommitメッセージは勿論丁寧に書くべきなんだけど、丁寧に書けばいいわけでもないんだ。
それでバグやパッチが減るわけでもないから。
目的と手段の混同はどの界隈でもあるけど、ここの連中も大概だよ。 []; [ここ壊れてます]
1049 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 20:11:50.13 ID:OfQ8ymDc0.net]: >>994
と思ったがすまん、見落とした。

> 修正コミットのログ

つまりこれ、コミットメッセージそのものなのか？
ちょっと確認したいんだが、どこ見ればいいんだ？GitのGitHubから？
1050 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 20:22:10.42 ID:sj15aRfA0.net]: >>996
そう。コミットメッセージを含めてML上でレビュー中。まだ本体リポジトリには入ってない。
挙がってるレビューコメントを受けてそのうち第２弾が投稿されて取り込まれるんじゃないかな。
君もソースコードの質が気になるなら修正を送ってくれていいんだよ。さぁさぁ。
1051 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 20:38:50.28 ID:OfQ8ymDc0.net]: >>997
つまりあれがそのままに近い状態で入るのか？
まあそれは見守るとして、本来はちゃんとラベルを付け替えないとまずい。

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

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

> 君もソースコードの質が気になるなら修正を送ってくれていいんだよ。さぁさぁ。
これは本質的に無理だ。多分俺、というか、いわゆるCコードを拒絶すると思うよ。
間違いなく、連中は自己の能力に自信持ってて、傲慢で、言うこと聞かない連中だ。
世の中のCコードなんて、基本通りやってる物でほぼ全部だから、見たこと無いわけが無い。
それが何故そうなってるか理解出来ない、
つまり、王道を王道と理解出来ない奴等だからデタラメやってるわけで、
言うこと聞く連中ならそうはならない。

通常だと、やらせるだけやらせて、でもどうにももうダメポなときに、
そもそもお前のコードがおかしい、ここをこう直せ、なら簡単にメモリリークは抑えられる、とすると効くのだろうけど、
問題はバザールで、無限にモグラ叩き出来てしまって、実際にそれでやろうとしてることだよ。
マジかー、って、ちょっと驚きだが、まあ観戦だ。
ああちなみに、俺以外の誰でも、まともなC書ける奴なら、ちょっと引くコードだよ。
だからそこら辺の奴等に書かせても、もっとましなコードになるよ。そして俺もその程度だし。
というか単発のコードでそんなに技量の差なんて出ないし。
1052 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 20:40:54.42 ID:VM2X6i580.net]: >>998
お前がちゃんとやれって言われるだけだよ
お前雑なんだよ。無能なのに張り切るな。空回りしてるぞｗ
1053 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 20:46:49.73 ID:wlljBD17M.net]: 質問いいすか？
1054 名前：1001 [Over 1000 Thread.net]: このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 197日 17時間 21分 4秒
1055 名前：過去ログ ★ [[過去ログ]]: ■ このスレッドは過去ログ倉庫に格納されています

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef