Git 18
■ このスレッドは過去ログ倉庫に格納されています
ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。 Git - Fast Version Control System http://git-scm.com/ ◆関連サイト Pro Git - Table of Contents http://git-scm.com/book/ja Git入門 http://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 だからなんでgit使うだけで bash+たくさんコマンド入れなきゃならんのだよ >>797 必要なのはポインタであってブランチではないんだ。 というか、俺にとってはその時のスナップショットが復元出来れば何だっていいんだよ。 fast-forwardでは履歴が辿れないからrebaseで、みたいな話もあるからもうちょっと確認必要だが、 git flow は手動ではなくインストールして使え、そうすれば全部やってくれる、としてるところばかりで、 どうもmergeの時に色々判断して小細工してるようだが、何やってるのか書いてないから分からないんだ。 まあでも色々他の簡単なのもあるみたいだし、初心者だから出来るだけ単純なのにするよ。 >>799 逆に一体どんな環境でやってるのさ? 普通のunixコマンド一式すら入ってないのか? そもそもGitなんてPCかそれに近い環境で動けば良くて、それ以外は考慮する必要ない気がするが。 >>800 今話をしているのはお前が言ったこと > 逆に言えば、同時開発する気がなければ要らないわけだな。 if (同時に開発する気がある) { いる } else { いらない } 自分で同時に開発する気があればいるって言っただろ自分で >>802 ん?どこを誤解されてるのかは分からんが、 俺は複数バージョンを同時開発する気はない。 ただ、リリース後にバグが発覚するする事はあるので、hotfixはする。 >>801 普通にSourceTreeとかでコマンド一杯を前提としているとは思えないが。 >>788 少なくともCIで回すときは楽だろ。 Git初心者で視野狭すぎなのに、その視野の狭さを無視して「合理的に考えてこれが不要」ってのがあんたのスタイルのようだけど、 そうやってわざわざ視野の狭さから来る「不要」の主張をして反感を買ったレスで学びたいのか? 勉強したいなら、炎上スタイルは目障りなんでよしてほしいな。二言ぐらい余計なんだよ。 >>798 以下は簡単に調べただけで、時系列の検証もしてないので、何か間違いあるかもしれない macOSはbash,gcc,sambaをベースシステムにいれるのをやめた これらはGPLv2からGPLv3にライセンスが変更されて、GPLv3に追加されたバイナリの取り扱いに関する条項がmacOSのセキュリティポリシーに合わなくなったのがその理由 linusはこのGPLv3の条項に批判的で、gitはGPLv2のままでいく可能性が高い GPLv3のbashに依存するようgitを作り変えると、インストール方法をちょっと特殊にしないとgitもこのGPLv3の条項の制限をうけることになってしまうので、まあやらないだろうね 他のOSSに依存するとこういうのもあるから気を付けないといけない > Cコード上で何か小細工が必要なら、それは「互換性を上げる」名分でbashにcontributeすべきで、 Git側で吸収する案件ではない。 頭おかしい まあdevelopはいらないかな mainブランチで開発すりゃいいよ リリースブランチが必要なら別途releaseブランチを作ればよいのであって、デフォルトブランチは開発系の先端を指してる方が分かりやすい >>798 > Cコード上で何か小細工が必要なら、それは「互換性を上げる」名分でbashにcontributeすべきで、 gitの都合でbashに迷惑をかけるな お前のやりそうなことだな 自分の都合で関係ないやつに迷惑をかける >>808 初心者のお前の感想なんかどうでもいいよ GPLに賛同せずにGNU製品を使ってたってことだろね。 結局Linusもタダ乗り爺ってことでしょ。 ブランチの名前の付け方や使い方なんてほんとどうでも良い。チーム内で話し合え git のブランチは全部等価 デフォルトで main / master 作られるけど これも使いたくなけりゃ使わなくて良いし名前変えても良い >>805 そんなガキみたいなことはしないが、 どう取るのも自由だし、気に入らないのなら無視してくれて構わんよ。 ただgitがポンコツだと言ったとしても、それ本来お前ら関係ないよね? 自身の分身と思えるほどcontributeしまくってるのなら別だけどさ。 > 少なくともCIで回すときは楽だろ。 必要になったときに作ればいいだけなのと、 多分仕様か実装を間違えてて、今のGitの動作では技術的に実用性がない。 これは次の投稿で詳しく述べる。 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) そして、どうやら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で修正されるべき案件だろうね。 >>806 MacOSがFreeBSD系なのとLinusがGPLv3をボロクソ言ってたのは知ってたが、両方とも理由は知らなかった。 > GPLv3に追加されたバイナリの取り扱いに関する条項がmacOSのセキュリティポリシーに合わなくなった よく分からんが結局は両方ともここかな? > プロプライエタリなドライバソフトを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でも十分だろうしさ。 やっぱりかなり政治的だよ。勿論譲れないのだろうけどさ。 >>807 >>809 お前ら狭量すぎ。OSS全体で盛り上がるんだ!という考えが無さ過ぎ。 diffもそうだが、bashの互換性が本当に問題なら、bashを修正すれば全員助かるだろ。 Gitコマンドをシェルで実装すると、unixコマンドの中にgitコマンドが混ぜ込まれてる形になる。 そのgitコマンドをcpに差し替え、unixコマンドだけの状態で環境依存で使い物にならないのなら、 それは立派なバグだから、bashの連中に投げれば直してもらえるよ。 自分で抱え込みすぎ。それでは回らなくなる。(のが一般的だが、バザールだからなあ…) ただGNUとは根本的にウマが合わないだろうよ。 仕様はグダグダ、ソースコードはゴミ、でも回り続けてるのだから、GNU(伽藍)から見たら何じゃあこれは!!!ってなる。 Git側にはGNUの開発速度はどうにも認められないだろうしね。 > お前ら狭量すぎ。OSS全体で盛り上がるんだ!という考えが無さ過ぎ。 だからgitの話はgitの中で盛り上がればいいだろ 勝手に他人の家で盛り上がるな ば~か bashがなんでも修正を入れるわけがない それは俺の仕事じゃないと言って断られるが落ち bashをぶくぶく太らせるな 一つ事だけやらせろ >>816 GPLv3ではバイナリを配布する際にそのバイナリをユーザがソースからコンパイルしなおして入れ替え可能でなければいけないという条項になっているらしい MacOSやiOSのアプリやストアから配布するAndroidのアプリなんかの今どきのバイナリ配布は、署名済みバイナリしか実行できないから、ここにGPLv3の物を入れるとライセンス違反になる >>817 GNUは別に開発組織ではないから統一的な開発ポリシーなんてものはないが、 GPLv3に移行するようなFSF管理下のGNUプロダクトは、歴史も古いし、比較的少数のおっさん達が気ままに管理してることが多いので、OSSと呼ばれるようになる前からの伝統的なUNIXフリーソフトのべたなソースツリー構成なものばかり たとえばbashのソースコード構成なんてgitみたいにトップディレクトリ下に組み込みコマンドの実装コードがだらだら並んでてgitと変わらん どのOSでメインに作業してるのかわからん感じだな。 LinuxはCでモノリシックだとDISり、GNUコマンド群でないmacOSも当然DISり、 Windowsなんか論外って感じだろ。 3OSぐらい使ってたらとてもシェルなんか信用できないけどな。 >>822 いやそこまでは全然見てない。 今回の仕様とパッチの顛末見て、他もそうだと勝手に推定してる。 読む価値のないコードのはずだから。(物によって全然違うかもしれんが) ただこれで回ってるのは事実だからな~。ちょっと観戦モードだ。 まず既に言ってるが仕様がグダグダ。 仕様は追加は簡単だが、削除することは基本的に無理なので、厳選しないといけないのに、まるで出来てない。 つまりこの辺の常識的な長期保守戦略をまるで知らない奴がやってて、止める奴もいないということ。 そして今回のメモリリークだが、確保したらそこで寿命も確定する、実装が一番簡単なタイプで、 これをリークさせるようなら話にならない。 ただそれでもミスることはあるが、出てきたパッチがこれまたグダグダで、Cのメモリ管理の基本を完全に無視してる。 レビューがあったら見た瞬間落とされるソースだ。そりゃリークするよな、としか思わない。 (ただし第2弾、第3弾も出てきて、ましになりつつあるが、それでも方向性を根本的に間違ってる。 とはいえ、展開が異常に早いのも確か) だから、通常の開発をやっているであろうGNUでは、仕様のレビューでも、コードのレビューでも落とされる。 だけどGit側にその理由を理解出来る奴がいないからこうなわけで、当然ブチ切れる。 そして喧嘩別れ、だったら俺らで作るからいいよ、でforkして突っ走ってるだけのように見える。 若すぎる。 ただそれでも実装能力だけはあるので、diffはGNUより装飾周りが断然進歩してる。 これはやっぱりGNUdiffと一緒にやってた方がみんな幸せだったと思うよ。 上手く導ける奴がいれば、 というより普通に長期保守したことがある奴が上層部に一人でもいれば、この辺は簡単に修正出来ると思うのだけど、 それは伽藍タイプの話で、バザールだとどうにもならないのかもしれんし、 突っ走らせないとプロジェクト自体が死ぬのかもしれんし、(サメみたいにね) よく分からん。 >>823 自分が理解できないものは全部糞 理解力が致命的に弱い この2つが合わさると全方面Disることになる >>817 何で自分の関心の向かないOSSにわざわざ貢献しないといけないんですか? 金も貰えないのにそんなの苦行でしょう、アホらしい それとも君はLinusに向かってそれを要求できるほどGNUに対して貢献してるんですか? bashの方を直せって言うなら GNU bashのプロジェクトに殴り込みをかければいいじゃん お前が >>828 逆だよ。他人に投げられることは他人に投げろと言ってる。 bashのバグだってことになれば、勝手に直してもらえるだろ。 自分で対応するのは、直してもらえないのが確定してからでいい。 >>829 そもそも俺はbashの互換性で苦労した試しがない。 ただそもそもOS跨いでシェルスクリプトを持っていった試しも無いけどな。てかそんなこと普通せんし。 あーだから、最悪Linux/Windows/Mac用と3種類用意すればよかったんじゃね?C化よりは楽だろうよ。 > 逆だよ。他人に投げられることは他人に投げろと言ってる。 なんのために? > bashのバグだってことになれば、勝手に直してもらえるだろ。 だからお前がbashに通報しろって お前という他人に投げたぞw さっさとやれ >>830 え、Cでプログラム書いたことないの?OS間の違い、標準Cライブラリの方がよっぽど互換性に苦労することないよ… 考慮しなければならないのはファイルシステムと改行コードぐらいだろう。 まあおまえら落ち着け>>815 とか見る限りこいつはひとりではGitを理解できない 炎上させて答えを引き出そうとしてるから餌を与えちゃいかん ほっとけばすぐいなくなるよ >>834 ああ、@1か、これは失礼。 ただお世辞にも分かりやすいとは言えないねこれは。 まあでも、ならbranchを残す意味はあり、>>815 は取り下げだな。 >>814 については引き続き募集中。 >>836 @{1}に気が付くとはさすが軍師殿www HEAD~1 で一つ前のリリースとか言ってて爆笑 リリースごとに一回だけコミットするつもりなのか? 永久に git 理解できそうにないな ネットのクソ記事で独学するより、まともな本買って学習すればいいのにな つうかあれか、gitの仕様の粗探しがしたいから使い方とかどうでもいいのか そもそも一つ前wみたいな考え方するようなものじゃないよなw 自分が理解できないから、知ってるシェルスクリプトにすがってるだけだな POSIX原理主義者と一緒。POSIXの名前を勝手に使って シェルスクリプトしかできないのをごまかしてる gitを利用してシェルスクリプトしかできないのをごまかしてる >>717 ちなみに書く側のコマンドは hash-objectのようだ。 多分初期はPlumbing Commandsをシェルスクリプトでラップして各上位コマンドを提供してたのだろう。 そして俺にはこの程度のシェルスクリプトが環境依存するとはとても思えないんだけどさ。 >>821 って、ふと気づいたが、俺が使ってるのはGitBashだったわ。 現在の公式版にもGitBashバイナリは同梱されてるし、ライセンスがどうこうという問題は無いか、解決されてるよ。 Macは政治的だとして、Linusはその辺実務的に見えるから、 GPLv3をボロカス言って自分はGPLv3には参加しないが、(これは正当な権利で全く問題ない) GPLv3を殺す為にGPLv3のプロダクトの同梱すらしない、みたいなことはしないのだろうよ。 >>814 公式のcontribに置いてあるユーザー製作の勝手ツールにあるのは発見した。 つまり熟知してる公式からみても面倒な作業だと認めているわけだ。 解決というよりは諦めと納得だが、これも質問を閉じる。 > https://zenn.dev/yoichi/articles/git-restore-branch ちなみに、branchを『後から追加』は出来るか? いやそんな使い方はおかしい!禁止だ!かもしれんが、 やはり俺にはbranchはただの(DBにおける)INDEXで、 随時落としたり作ったり復活させられないと使いづらい。(のではないかと予想している) ただ、要はreflogを偽造すればいいだけのようだが、 再実装は時間の無駄でしかないので、既にあればそれを使いたい。 >>842 index-stageを理解してないおまえにはわからないかもしれないけど、 DBへ登録されるのはwork tree上のファイル丸ごとでない場合もあるし、 逆にDBからwork treeへ展開されるのもファイルの中の一部分の場合があるから、 そんな単純にはいかない >>842 Windowsはアプリを実行する上でコード署名が必須でないから問題にならないだけ >>843 gitのマージを全然理解できてないからブランチを復活させたいとか思ってしまうんだな 普段の運用でスクリプトを使ってブランチを復活させたいとか思う羽目になることはあまりない ブランチがDBにおけるindexみたいなものとか、後から追加できる?みたいな疑問が生じるあたり、ブランチが何なのか全然わかってない reflogの偽造が必要という発想もかなりズレてるし、>>814 をみるとコミットの履歴がどういうものなのか理解できていないのだろう >>844 さすがにその程度は知ってるぞ。 ただ、一般的には git add -A で問題ないディレクトリ構成で使う方が多いんじゃないか? まあそれはさておき、 要は、正しくソフトウェアが構成されてれば、cat-file/hash-object を組みで交換すれば、 末端のファイル形式は自由に選べるって事だよ。sshにすればネットワーク先にも余裕だ。 つってももうこの話は通じないのでいいが。 >>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の機能だけで書き直す方を選択するけどね。 >>847 実際仕事すればわかるが add -Aで綺麗なコミットを作れるように整備されてるリポジトリはあまり無い デバッグしながらコミットしていくときは add -p を使うことがとても多い git add -Aで十分とかさぁ、開発経験なさすぎだろ それはgitをバックアップとか途中セーブ機能とでも思ってんのか? 1 commit = 一機能の追加とか、一日の最後にやるものとか思ってるんだろ 通常なにかのバグの修正とか 複数の個別の問題の複合なのに それ全部まとめんな >>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の思想と合ってないだけだね。ならツール用意しとけと。 >>852 世の中に理解しないで使えるものなんてない 大体gitの使い方を理解したいと思ってるやつはアホ 理解するのはバージョン管理の仕方だ こうやってツールの使い方を学ぶことが理解だと思ってるから gitがなくなったらどうしよう また新しいことを学ばなきゃいけないってなるんやろ >>854 git そのものを理解すること諦めたか でもお前使い方の方も盛大に勘違いしてるよ >>851 > それはgitをバックアップとか途中セーブ機能とでも思ってんのか? > 1 commit = 一機能の追加とか、一日の最後にやるものとか思ってるんだろ そうだぞ。 ブッ込んでおけば後で何とでもなるただのバケツでしかない。 バケツの使い方を学べとか、知るかボケだ。 後でバケツから探し出すハメになった時、取り出し方をググって取り出せれば十分だ。 大方、プログラマの大半はこの程度の認識のはずだぞ。 そしてお前が望む、綺麗な管理記録は、これのサブセットでしかないんだよ。 だから例えば俺が780で言ったように、「コミットメッセージが空」を除外すれば簡単に得られる。 今のGitにこの機能がないだけ。(まあ近い機能はあるが) DBならWHEREに条件を付加すればいいだけの楽勝案件で、Web系ならみんな出来るよ。 sedのワンライナーで済むことすらCで実装するGit界隈だと誰も出来ないのだろうけどさ。 まあGitにSQLインタフェースを付け加えればWeb系の奴等は文句言わなくなるんじゃないかな? 連中にとっては直感的になるから。 > 大方、プログラマの大半はこの程度の認識のはずだぞ。 お前の周りの無能集団だけだろ 一体どこのプロジェクトに「2022年11月4日の仕事終了時のセーブ」なんてコミットがあるんですかねぇ データの取り出し方なんか知っていても 過去のコミットのミスを簡単に直せないなら バージョン管理は苦痛になるし やっぱりツールの使い方だけ知ってバージョン管理をしたことがないんだろうな バージョン管理が不便だからgitが作られたんだぞ >>859 俺はそれでいいと思うけど。 記録してない方が問題で、記録さえしてあれば、ゴミとマジを簡単に分離出来れば十分だ。 >>860 今のGitの修正は十分苦痛だよ。 修正させたくないから面倒にする、は間違いで、 簡単に修正出来るが、修正したことも履歴に残るようにする、が正しい。 × 俺はそれでいいと思うけど。 ○ 無能はそんなことをしている。 まずさぁ、gitというかバージョン管理の基本を理解してないんだからさ そこから勉強しなよ > 簡単に修正出来るが、修正したことも履歴に残るようにする、が正しい。 お前はテキストエディタで保存するたびに gitにセーブしろって言ってんのか?w >>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しても、俺は構わんと思うけど。 上記のように、それを1コマンドで除去出来れば、実務上何ら問題ない。 粒度が細かすぎてDBが膨れあがるなら、その部分を定期的にバックアップに切り出していけばいいだけ。 bitcoinはこの方式だ。 >>862 多分根本的に違うのは、 俺: 俺のワークフローに合うようにツールをカスタマイズする 863: Gitのワークフローに合わせてgitを使え、それ以外認めない! なんだよ。 Linusが個人的に開発したんだからGit自体はそれでいいんだが、 全世界でLinuxと同じワークフローが適切なわけではない。 >>864 アホなの?コミットメッセージは毎回入れるものだ >>864 > 全世界でLinuxと同じワークフローが適切なわけではない。 だからgitはいろんなワークフローに対応してるんだろうが お前のはバージョン管理のワークフローではない ただのバックアップのワークフローだ まあ1人プロジェクトみたいだし好き勝手やらせればいいさ コミットメッセージが空だったら~とかわけわからんなw 行単位で独立してるデータベースのデータじゃないんだからさぁ ソースコードは前後の歴史とつながってる DELETEなんちゃらみたいに一つだけ取り除くことが出来るのは稀 >>869 それは当然UIの話で、当たり前だが内部のリンクは接続し直すんだよ。 そしてそれをユーザーには見せない。 多分ここら辺の階層の話がGitには存在しないんだよ。 だからユーザーがviでリンク書き換えろとかの勢いだろ。 超密結合だし滅茶苦茶だよそれは。 >>870 都合が悪いからって無視するな 前後のソースコード関連してるから 途中のコミットを取り除くことはできないと言ってる つまり、両親がイブに中出ししてお前が生まれたという歴史において、 イブの中出しだけを無かったことにはできないと言うことだね その後の歴史でお前が存在するのはおかしいし >>871 何言ってんだ? 中身はただの単方向リンクリストだぞ。 リンク先が複数のこともあるが、それでも問題なく抜ける。 ただそれ以前に、俺は既に言ったとおり「記録されてないほうが問題」とするので、 CREATE INDEXを使うが。これなら理解出来るか? だったら、このINDEX対象をちょうど全部含むようにリンクリストを新しく作り直せばいいだけ。 それがDELETEしたものと同じ物になる。これで理解出来るか? >>873 じゃあ抜き取ってみ ・commit 1「aaa を追加」 aaa ・commit 2「bbb を追加」 aaa bbb ・commit 3「bbb を ccc に置き換えた」 aaa ccc ここからcommit2を抜き取ったときの commit3の修正内容をよく読んでみろ >>873 残念だけどそこから間違ってる Gitのコミットのリストは単方向リンクリストではない なのでリストの途中のコミットを削除したり途中に追加できない >>874 ああコミットメッセージについては考えてなかったが、 俺ならそのままぐちゃっと貼り付けるけど。 つまり、 ・commit 1「aaa を追加」 aaa ・commit 3「bbb を追加」「bbb を ccc に置き換えた」 aaa ccc になる。 >>875 親が複数あるだけの単方向リストだよ。 まあこれを単方向リストと呼ぶかは微妙だから、ツリーと言った方が通じたか? ツリーが複数重なり合った状態になってるだけだよ。 単線の A<-B<-C なら A<-C になる。これは自明だよな。 マージの場合、(BがADのマージ結果ね) A<-B<-C D<-| を A<-C D<-| にする。 >>876 ようやく理解したか。 だからお前がやってるのはただのバックアップを取ってるだけだっていってんだよ バージョン管理というのは何をどう変えたかという変化を記録するものだ スナップショットじゃねーんだよ、あーほ >>876 bbbの話がないのだから、 書き間違えなのか全く区別がつかない バグコミットメッセージだな >>873 > ただそれ以前に、俺は既に言ったとおり「記録されてないほうが問題」とするので、 だからお前のテキストエディタでの変更内容を全部記録するって言ってるんだろ? ファイルを保存するたびにコミットするんだろお前は? バージョン管理で記録するのはソースコードの修正履歴であって お前個人の作業履歴じゃねーんだよ 使い物にならないゴミコミットを作るな >>878 ああ履歴についての認識が違うんだな。了解した。 履歴は、 俺: スナップショット=「点」の並び 君: 変更した線の並びで、それはcommitメッセージに現れる。 それだと、commitメッセージが間違ってる場合はどうしようもなくなるだろ。 あくまでソースコードが重要で、どこをどう変えたかはdiff取れば済むだけの話、 commitメッセージなんて目安に過ぎないんだよ。 Gitもこちらの立場に近く、VCSとしては珍しく(と聞いているが俺はそこまで詳しくないが) 差分ではなく本体を記録するだろ。 >>881 > 履歴は、 > 俺: スナップショット=「点」の並び だから、それはバックアップで言うって最初から言ってるだろ お前が完全に間違ってるんだよ > それだと、commitメッセージが間違ってる場合はどうしようもなくなるだろ。 修正しろよ。それが出来るように作られているだろ > commitメッセージなんて目安に過ぎないんだよ。 はっw バージョン管理の素人が。 コミットメッセージの重要性を知らない時点で終わってるよ >>880 > ファイルを保存するたびにコミットするんだろお前は? そこまではしないが、1日10回とか平気ですることもあるし、それが問題だとも思わない。 この辺はポリシーだし、好きなようにすればいいと思うがね。 間違いなく言えるのは、俺は美しいソースコードを目指しているのであって、 美しいコミット履歴を目指しているわけではないんだよ。 そしてコミット履歴が過剰なら、落とせばいいだけだろ、という話。 無い履歴からは生成することは不可能なのだから、大きすぎる粒度より、小さすぎる粒度の方がいいに決まってる。 所詮commitメッセージなんて当てにならないし、diffが取れれば全く問題ない。 > Gitもこちらの立場に近く、VCSとしては珍しく(と聞いているが俺はそこまで詳しくないが) > 差分ではなく本体を記録するだろ。 だから最初からバージョン管理は差分を記録するものであり gitの優れた点が、発想の転換で 本体を記録することで差分を表現することにした点なんだろ 実装の話とごっちゃにするな そういうところが技術的に未熟なんだよ >>883 > そこまではしないが、1日10回とか平気ですることもあるし、それが問題だとも思わない。 そりゃお前が素人だから問題であることに気づいてないだけ 誰もやってないからね > この辺はポリシーだし、好きなようにすればいいと思うがね。 お前が未熟だから反論できずにポリシーってことにしようとしてる >>877 分散バージョン管理ではですね、リポジトリのコピーがばらばらに複数存在することが前提なので、 あるひとつのリポジトリのコミット履歴が A<-B<-C で、他のリポジトリではこれが A<-C になっているという状況は不味いんですよ なのでGitではそれができないようにデータ構造が設計されています > 間違いなく言えるのは、俺は美しいソースコードを目指しているのであって、 > 美しいコミット履歴を目指しているわけではないんだよ。 コミット履歴は「使うもの」だって分かってないようだな 一部のコミットだけ抜き取って 他のブランチに組み込む 使うものだ お前はただ見れればいいと思ってる バージョン管理を理解してない >>883 > 所詮commitメッセージなんて当てにならないし、diffが取れれば全く問題ない。 お前が作るコミットがクソだから、使いものにならなくなっているだけだなw >>882 まあ君と仕事することは無さそうだから別に問題ないけど、 > 修正しろよ。それが出来るように作られているだろ コミットメッセージをいくら修正したところでそもそも意味無いんだよ。 管理してるのはメッセージじゃなくてソースコードなんだから。 それで、重要なコメントはソースコード上に書いてるから、diff取れれば十分なんだよ。 コミットメッセージは、あくまでGit上から探し出すラベルでしかなくて、何をやったかはdiffで見るし、それ以外にないよ。 > はっw バージョン管理の素人が。 > コミットメッセージの重要性を知らない時点で終わってるよ まあ俺はGitの達人になりたいわけでもないんで、これで問題ないよ。 > コミットメッセージをいくら修正したところでそもそも意味無いんだよ。 それはお前だけの感想ですねw > まあ俺はGitの達人になりたいわけでもないんで、これで問題ないよ。 バージョン管理の素人だって言ってる お前、他の人と一緒に仕事ができないよw > コミットメッセージは、あくまでGit上から探し出すラベルでしかなくて、何をやったかはdiffで見るし、それ以外にないよ。 途中を抜いといて、何をやったかなんてわかるわけ無いだろwww >>889 こうやってコミット履歴をちゃんと見れて なんの変更をしたのかわかるようになるまで頑張れよ https://github.com/freebsd/freebsd-src/commits お前のコミットは汚すぎて 使い物にならんのだわ >>884 > gitの優れた点が、発想の転換で > 本体を記録することで差分を表現することにした点なんだろ これは違う。 というかね、どっちを記録したところで、正常に動いていればどのみち任意の履歴を取り出せるから関係ないんだ。 ただ、ファイルシステム等がぶっ壊れて、断片的にしか取り出せなくなったときに、Gitみたいに本体を記録してる方が断然強い。 だから基本は「一番大事なもの」で記録するようにしなければいけない、という観点だったのだけど、 まあこれはフォールトトレラントにしろという話で、ちょっと蛇足ではあったね。 あまり関係ないからこの話は終わりで。 > これは違う。 だーかーら、素人のお前の意見なんか聞いてない https://www.techpit.jp/courses/33/curriculums/34/sections/286/parts/965 なぜスナップショットとして記録するのか スナップショットとして記録することで、複数人で開発する時のスピードを上げることができます。 詳しくは後ほど解説しますが、複数人での開発の際、並行して開発できるよう、 Gitではブランチというものを切って、バージョンを枝分かれさせて開発していきます。 このブランチでバージョンを枝分かれさせる際や、ブランチを統合(マージ)する際にスナップショットだと非常に作業が速くできます。 Gitがデータを差分というかたちで持っていると、ブランチを切ってマージする時に差分をいちいち計算しなければなりません。 しかしスナップショットで保存しておけば、差分の計算をしなくて済む分、とても速くブランチを切ったりマージできるようになります。 ちなみに、Git以前のバージョン管理ツールの多くは差分としてデータを保存していて、ブランチを切るのに大変時間がかかっていました。 大規模なプロジェクトになると数十秒かかったりすることもありました。 Gitだとこの作業が一瞬でできます。こういった事情があって、Linuxの作者のリーナス・トーバルズは 当時、大規模開発であったLinuxカーネル開発のバージョン管理システムを自作しました。これがGitのスタートです。 >>886 ああなるほど、ブロックチェーンよろしく親のhashデータも自分のhashに入ってるのか。 しかしそれは、改竄がばれるだけで、リンクを繋ぎ直すことが出来ないわけではないね。 というかね、それは本体ツリーの話で、 余分なcommitはrepoから消せ!とする君らにとっては問題だが、 俺みたいに、スカスカのINDEXでbranchを再構成するのはその場合にも全く問題ないはず。 ところで、 実は今もbranchの実体がどこにあるのか見えてない。 見る限り .git/logs/refs/heads/各branchにしかなさそうなのだけど、ここかね? これだと毎回reflogを動的に解釈することになるが。 実装としておかしくはないが、普通はこうはしないので、ちょっと不可解だ。 なおオブジェクトツリーにはbranchのデータは無く、branchは各オブジェクトへのリンクの入った配列だと見てる。 だからシャローコピーでしかなく、後からでもいくらでも作れるだろ、という話。 > 後からでもいくらでも作れるだろ、という話。 だから速度重視だって言ってる ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.4 2024/05/19 Walang Kapalit ★ | Donguri System Team 5ちゃんねる