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
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 してみろ

[ 続きを読む ] / [ 携帯版 ]

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