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
596 名前:デフォルトの名無しさん mailto:sage [2022/10/06(木) 22:38:26.50 ID:PvD2K1c/r.net] 間抜けなPOSIX原理主義者がまた論破されて敗走したのか
597 名前:デフォルトの名無しさん mailto:sage [2022/10/06(木) 23:17:53.55 ID:jAkUbGv20.net] >>563 俺もその本読んだけど、何となくGitの存在意義分かったよ 例えば会議の備忘録がこんな感じで複数あるとしたら? ・備忘録_1.txt ・備忘録_2.txt ・備忘録_1改.txt ・備忘録_最新.txt ・備忘録_3.txt どれが最も新しいかピンとこない、どの順に更新されたのかピンとこない、 誰がどのファイルにどんな更新を加えたの分からない そんな問題を解決してくれるのがGitのようなバージョン管理ツール(って書いてある)
598 名前:デフォルトの名無しさん mailto:sage [2022/10/06(木) 23:50:19.63 ID:orz8mNRt0.net] Gitむずかしいな みんなよく使えるな
599 名前:デフォルトの名無しさん mailto:sage [2022/10/07(金) 04:44:37.69 ID:TBR3DhbF0.net] >>563 YouTube で「git 使い方」「git 入門 」などで検索! 山浦清透・せお丸・くろかわこうへい・しまぶーなど、色々ある
600 名前:デフォルトの名無しさん mailto:sage [2022/10/07(金) 09:55:21.21 ID:E++rKArz0.net] >>577 UNIX哲学ではバイナリ形式は禁止されている 愚か者め
601 名前:デフォルトの名無しさん mailto:sage [2022/10/07(金) 10:07:54.49 ID:GHAO4XK10.net] >>582 だから、そのバイナリーって何よ?
602 名前:デフォルトの名無しさん mailto:sage [2022/10/07(金) 10:12:43.41 ID:E++rKArz0.net] >>583 話のわからんやつだな。この本を買え。全部書いとるわ。 https://techbookfest.org/product/5743917710442496 我らが一番問題だと思っているのは、リポジトリーの中身の多くが訳のわからぬバイナリーデータになって いることだ。そのバージョン管理ソフトウェアが滅んだら復元は絶望的だ。テキストデータ形式ならば眺めれ ば方策も見えてくるのでまだ何とかなりそうな気がするというのに。「データはテキスト形式で保存せよ」とは UNIX 哲学でも言われてきたことだ。一体何を考えているのか。
603 名前:デフォルトの名無しさん [2022/10/07(金) 10:13:25.77 ID:E++rKArz0.net] 移り行くトレンド 古参のプログラマーなら、これまでどんなバージョン管理ソフトウェアが台頭してきたか振り返ってみよ。す ぐ思いつくものだけでも、RCS、CVS、SVN、そしてGit。これらは同時期に存在して覇権を争っていたのでは ない。それぞれが時代を担ってきたといっても過言ではない。時代によって使うものが替わり、新しいバージョ ン管理ソフトウェアが
604 名前:流行り出せば、その使い方を覚え直し、時にはリポジトリーの移行を強いられてきたこと だろう。よくまぁ、懲りもせずにといったところだが、我らはもうたくさんだ。もしかすると、諸君は「Git を 覚えれば安泰だ」などと思っているかも知れんが、あと数年、遅くとも5 年も経てばきっと次のバージョン管理 ソフトウェアが登場し、覚え直しとリポジトリーの移行を余儀なくされることだろう。 [] [ここ壊れてます]
605 名前:デフォルトの名無しさん [2022/10/07(金) 10:13:49.81 ID:E++rKArz0.net] 目的を見失っったバージョン管理ソフト バージョン管理ソフトウェアのそもそもの目的は何だったのか。開発を続け、バージョンアップしていくソフ トウェアの維持管理に要するコストの抑制であったはずだ。これは、POSIX 原理主義を崇拝する我らがソフト ウェアを5 年、10 年と生き長らえさせようとする、その根底に流れる目的そのものである。 ソフトウェアはバージョンアップする。新しいコードを加え、古いコードは切り捨て、時には依存するライブ ラリーを付け替えもする。その変わる様をすべて見届けることがバージョン管理ソフトウェアの役割であり、そ れができて初めてまともに維持管理コストの抑制が実現する。ゆえに、 バージョン管理ソフトウェアは、ライブラリーの類よりも遥かに長く生き長らえなければ意味がない。 ところが実際はそうなっていない。「バージョン管理ソフトウェアの維持管理」を強いられる。本末転倒もい いところ。お前は何を言っているんだ。
606 名前:デフォルトの名無しさん mailto:sage [2022/10/07(金) 10:26:43.54 ID:8xhEA9gJ0.net] 覚え直しと移行すりゃいいじゃん その時期がくれば便利な移行ツール(git svnコマンドのような)が出回るし、簡単なことだよ そんなちっぽけなことを恐れて、完全無欠の理想通りじゃないからと今のベターな現実解を忌避するのはあれだ こだわりが強すぎて社会生活に支障が出るタイプの典型的症例
607 名前:デフォルトの名無しさん [2022/10/07(金) 10:31:38.34 ID:E++rKArz0.net] >>587 何度も何度も覚え直しでお前は成長してると言えるのか シェルスクリプトだけでなんでもできる
608 名前:デフォルトの名無しさん [2022/10/07(金) 10:33:30.22 ID:E++rKArz0.net] >>587 中身がわけのわからんバイナリデータなのだから壊滅的だ データは取り出せなくなり移行なんかできん バージョン管理ソフトウェアが滅んだら復元は絶望的だ
609 名前:デフォルトの名無しさん mailto:sage [2022/10/07(金) 11:43:19.78 ID:GHAO4XK10.net] 中身がわからんのはお前が無能だからだろ。ソースも公開されてるし、中身の形式も公開されてるので読んどけ。プロプラな機密ソフトの基準で語ってんじゃねーよ。 中身が完全にわかっているという意味ではテキストと同等かフォーマットが決まってる分それ以上に効率が良い。
610 名前:デフォルトの名無しさん mailto:sage [2022/10/07(金) 12:18:40.03 ID:6in1nvJWM.net] >>582 UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている
611 名前:デフォルトの名無しさん [2022/10/07(金) 12:20:40.01 ID:d4ub3t4La.net] テキストで保存した結果 e38397 e383ad e382b0 e383a9 e3839f e383b3 e382b0 e381a3 e381a6 e4bd95 efbc9f ↓ e383 97e3 83ad e382 b0 e383 a9 e383 9fe3 83b3 e382 b0 e381 a3 e381 a6 e4bd 95ef bc ↓ 繝励Ο繧ー繝ウ繝溘Φ繧ー縺」縺ヲ菴包シ
612 名前:デフォルトの名無しさん mailto:sage [2022/10/07(金) 13:30:31.61 ID:8xhEA9gJ0.net] >>588 成長? 最適なツールを選ぶときに成長とか関係ある? 淡々と使うだけだろ 何度も何度もっていったい何百年生きるつもりなんだ
613 名前:デフォルトの名無しさん mailto:sage [2022/10/07(金) 13:58:18.44 ID:+OS+xNc10.net] USP研究所のシェルスクリプトマガジンを購読しているけど、 こんな人がライターなのか? いささかガッカリした。
614 名前:デフォルトの名無しさん mailto:sage [2022/10/07(金) 14:06:48.59 ID:h1ATf2/y0.net] バイナリに見えるのはgzip圧縮されてるだけでgitconfigに compression=
615 名前:0 loosecompression=0 を書いておくと無圧縮のテキストになったような [] [ここ壊れてます]
616 名前:デフォルトの名無しさん mailto:sage [2022/10/07(金) 14:37:14.17 ID:E++rKArz0.net] >>593 せっかく覚えたのにバージョン管理ツールが変わって知識が役に立たなくなると言っておるのだ シェルスクリプトなら20年後も今の知識が通用する https://www.slideshare.net/ShellShoccarJpn/posix-59780910
617 名前:デフォルトの名無しさん mailto:sage [2022/10/07(金) 14:39:12.40 ID:q9dWCqSf0.net] 頭おかしい奴が沸いているw
618 名前:デフォルトの名無しさん mailto:sage [2022/10/07(金) 15:14:19.27 ID:h1ATf2/y0.net] ちなみにgitのリポジトリは、ブランチ、コミット履歴、データ(ファイル)の3種類を それぞれsha1ハッシュで繋いでいるだけのシンプルな構造 リポジトリをバラしてファイルを取り出すだけのプログラムなら大体の人は1日もあれば作れるよ
619 名前:デフォルトの名無しさん mailto:sage [2022/10/07(金) 15:32:28.30 ID:GHAO4XK10.net] >>598 さすがに1日もかからんやろ。スクリプト言語使って15分とかそんな感じでは。
620 名前:デフォルトの名無しさん mailto:sage [2022/10/07(金) 16:01:35.71 ID:IRNCV7aTr.net] >>596 そんなに苦痛なんだ。 大変だね。
621 名前:デフォルトの名無しさん mailto:sage [2022/10/07(金) 16:13:03.09 ID:h1ATf2/y0.net] む 〇zlib圧縮 ×gzip圧縮
622 名前:デフォルトの名無しさん [2022/10/07(金) 17:08:55.91 ID:E++rKArz0.net] >>598 ならばそのsha1ハッシュをPOSIXの範囲で作ってみよ POSIX準拠で仕様が許されてるハッシュ化コマンドはcksumのみだ 我らはbase64コマンドをawkで作ってみせた
623 名前:デフォルトの名無しさん [2022/10/07(金) 17:09:18.38 ID:E++rKArz0.net] POSIX準拠で使用が許されてる
624 名前:デフォルトの名無しさん mailto:sage [2022/10/07(金) 17:35:13.58 ID:GHAO4XK10.net] >>602 アホはスクリプト言語で書いた。 普通の人は速度出したいのでそういう用途にはCコンパイラ使う。POSIXにC言語の規定がないとでも思ってるんだろうな。
625 名前:デフォルトの名無しさん mailto:sage [2022/10/07(金) 18:19:16.51 ID:E++rKArz0.net] >>604 アホはお前だ。POSIXにC言語の規定があることぐらい知っておるわ。 C言語はハードウェア依存する。そのような効率よりも移植性のほうが重要だ。 https://www.ipsj.or.jp/dp/contents/publication/32/S0804-R1601.html POSIXに準拠したプログラムを作成することにすると,開発言語はシェルスクリプト またはC言語(C99)に限定される.その理由は,POSIXで用意されている プログラミング言語としてのコマンド(以下,POSIXコマンドと記す)に PerlやRuby,Javaといった現在よく利用される高級言語は存在せず, 存在するものはBourneシェル(sh コマンド)とCコンパイラ(c99コマンド)だけだからである. どちらを選択してもPOSIXに準拠したプログラミングができることにはなるが, 基本的にはシェルスクリプトを利用する.C言語はバイトオーダ等のハードウェア構造を 意識しなければならない.一方,シェルスクリプトであれば,そのようなハードウェア依存は POSIXコマンドが吸収しているため,意識せずにプログラミングできることが理由である. したがって,POSIX中心主義では,POSIXの仕様に準拠したシェルスクリプトを 中心としたプログラミングをする.シェルスクリプトを選択することには,以下に述べる3つの利点がある.
626 名前:デフォルトの名無しさん mailto:sage [2022/10/07(金) 18:20:33.07 ID:E++rKArz0.net] >>604 シェルスクリプトが遅いなどというのも間違いだ。 それはストリーミング型の書き方を知らない愚か者の戯言だ 3.1.1 開発効率と処理効率の両立 シェルスクリプトはC言語と比べて処理の遅さを指摘されるが,それは必ずしも正しい認識ではない. シェルスクリプトはインタプリタ型言語であるため,ステップ数が多いほど処理効率は悪化する. また各ステップに外部コマンドを起動する記述があればそれも大きな処理効率悪化につながる. しかし,手続き型の書き方からストリーミング型の書き方に改めるように工夫すれば, ステップ数の増加を抑えられ,処理効率は大きく改善する.
627 名前:デフォルトの名無しさん mailto:sage [2022/10/07(金) 18:27:03.31 ID:GHAO4XK10.net] >>606
628 名前:カゃあ、お前がシェルスクリプトで git 書けばいいんじゃね? 俺はバイトオーダーに依存しないCプログラムの書き方知ってるのでそっち使うけど。 [] [ここ壊れてます]
629 名前:デフォルトの名無しさん mailto:sage [2022/10/07(金) 18:36:41.70 ID:E++rKArz0.net] >>607 我らはすでにシェルスクリプトでバージョン管理を行うすべを持っておる gitを書く必要などない 知りたくばこれを買ってPOSIX主義的バージョン管理概論を読め https://richlab.org/coterie/lpf.html
630 名前:デフォルトの名無しさん (ワッチョイ cfbb-fxWw) mailto:sage [[ここ壊れてます] .net] >>608 ゴミを勧めんな。オライリーに訴えられてろ。
631 名前:デフォルトの名無しさん mailto:sage [2022/10/07(金) 20:35:52.31 ID:E++rKArz0.net] >>609 ゴミならば大学の教科書になっておらぬわ
632 名前:デフォルトの名無しさん mailto:sage [2022/10/07(金) 23:21:13.94 ID:YKezo8WP0.net] forkで2つのコミットの差分どうやって見るの? 履歴から2つ選択しても出ない。コンテキストメニューも。未実装?
633 名前:デフォルトの名無しさん mailto:sage [2022/10/08(土) 00:36:23.18 ID:5sXOif570.net] 以前作ったリポジトリのmasterブランチの名前をmainに変えようとしてます 以下の手順であってますか? リモートリポジトリは自分がSSHでログイン出来るノードにあってベアリポジトリにも入れる状態です 1. (ローカルで) git clone <リモートリポジトリ> <ローカルリポジトリ> # リポジトリを取得 2. (ローカルリポジトリで) git branch --move master main && git push origin main # ローカルでmasterをmainにリネームしてプッシュ 3. (リモートのベアリポジトリで) git symbolic-ref HEAD refs/heads/main # HEADをmainに設定 4. (ローカルリポジトリで) git push origin :master # リモートリポジトリのmasterを削除 おかしいようであれば、新しいリポジトリを作って2.でそっちにpushして古いリポジトリは退避、以後は新しいのを使うことも考えてますがどうでしょうか
634 名前:デフォルトの名無しさん mailto:sage [2022/10/08(土) 05:07:17.54 ID:qNYwj5bN0.net] >>610 大学には頭おかしいのがおらんとでも? 大学全体の何割が使ってるか言ってみ。
635 名前:デフォルトの名無しさん mailto:sage [2022/10/08(土) 07:49:17.82 ID:fwLI4Y/XM.net] どうせ安全じゃないだろw >fatal: detected dubious ownership in repository at こんなものつけるなよカス
636 名前:デフォルトの名無しさん mailto:sage [2022/10/08(土) 09:15:42.49 ID:vxPAcYo70.net] >>613 大学だけじゃないぞ プログラマならシェルスクリプトマガジンぐらい知っておろう そこに長期連載されているほど、普及しておる 頭がおかしいなら、こんなに長く連載されるはずがないな
637 名前:デフォルトの名無しさん mailto:sage [2022/10/08(土) 13:26:00.09 ID:HbWzH6SVM.net] >>615 シェルスクリプトなぁ……簡単な作業の自動化用途だな。 なんでgitスレでこんな話題が? NG指定したほうがいい?
638 名前:デフォルトの名無しさん mailto:sage [2022/10/08(土) 14:00:29.88 ID:x9F/jCO70.net] >>612 set-headサブコマンドが使えるみたい
639 名前:デフォルトの名無しさん mailto:sage [2022/10/08(土) 14:11:03.99 ID:vxPAcYo70.net] >>616 愚か者め。シェルスクリプトは何でも出来る。CGIも作れた。 この間はUNIX哲学に基づいてリアルタイムカーネルなしに シェルスクリプトだけでリアルタイム処理を実現してみせたわ https://www.sea.jp/ss2021/download/11-SS2021.pdf
640 名前:デフォルトの名無しさん mailto:sage [2022/10/08(土) 14:23:26.42 ID:vxPAcYo70.net] >>616 gitのような目的を見失ったバージョン管理ソフトを使っているからだ バージョン管理ソフトはライブラリよりも長く行き続けなければならんものだが リポジトリでわけのわからんバイナリ形式を使っておるから バージョン管理ソフトが滅んだら復元は不可能になる。一体何を考えておるのか。 「データはテキスト形式で保存しろ」とはUNIX哲学でも言われている。
641 名前:デフォルトの名無しさん mailto:sage [2022/10/08(土) 14:47:58.03 ID:TKlSmRLn0.net] 容れ物が古くなったら新しい容れ物に中身を移すだけ。
642 名前:デフォルトの名無しさん mailto:sage [2022/10/08(土) 14:51:46.02 ID:vxPAcYo70.net] >>620 よくもまあ懲りもせずにといったところだな そうやって古くなったソフトを捨て新しいものに入れ替え せっかく覚えた知識は無駄になり移行作業で苦しむ POSIX原理主義なら一度覚えた知識は一生使うことが出来る 新しいことを覚える必要はない
643 名前:デフォルトの名無しさん (ワッチョイ deb0-zauZ) mailto:sage [[ここ壊れてます] .net] 啓蒙したいんだろうけど >新しいことを覚える必要はない これ読んで「そんなメリットがあるなら俺もPOSIX原理主義に入信しよう」と考えるエンジニアがいるもんかね。
644 名前:デフォルトの名無しさん mailto:sage [2022/10/08(土) 15:30:37.98 ID:5sXOif570.net] >>617 git remote set-headだとリモートトラッキングブランチのHEADが変わっただけでベアリポジトリ側のHEADは変わらず、 HEADが指してるブランチ(master)も削除操作が利かないままだったんですが、もうちょっと教えてもらえませんか
645 名前:デフォルトの名無しさん mailto:sage [2022/10/08(土) 17:26:15.60 ID:qNYwj5bN0.net] >>621 いいから、お前は黙ってシェルスクリプトでOSカーネルでも書いとけ。完成するまで戻って来るな。
646 名前:デフォルトの名無しさん mailto:sage [2022/10/08(土) 17:39:03.44 ID:88/OpuEG0.net] 啓蒙したいんじゃなくて単に荒らしたいだけだから だいたいオープンソースなのにソフトウェアが滅ぶとか意味がわからん
647 名前:デフォルトの名無しさん mailto:sage [2022/10/10(月) 11:28:58.21 ID:JuIf0a+H0.net] シェルスクリプトのヤツは釣りだろ? マジでいってんだったら頭おかしいだろw (基地外を釣るエサ投下)
648 名前:デフォルトの名無しさん mailto:sage [2022/10/10(月) 17:13:47.79 ID:+gDGPUis0.net] https://megalodon.jp/2017-0110-1117-05/qiita.com/richmikan@github/items/7c2f844169db9a83c5ae 私の場合は「POSIX原理主義者」という名の人格者として名を知られるようになってきたが、「原理主義」を名乗るだけあって、
649 名前:デフォルトの名無しさん mailto:sage [2022/10/10(月) 17:25:23.67 ID:PTVZRYxu0.net] >>627 いいからお前はシェルスクリプトでカーネル書く作業に戻れ。シェルスクリプトがあれば何でもできるんだろ。
650 名前:デフォルトの名無しさん mailto:sage [2022/10/10(月) 17:30:56.62 ID:+gDGPUis0.net] >>628 勘違いしてるぞ。俺は人格者(笑)って書き込んだだけだぞ
651 名前:デフォルトの名無しさん mailto:sage [2022/10/16(日) 04:54:37.57 ID:kNlIrq3k0.net] Shelling at Russian power plant leaves Belgorod without electricity https://www.youtube.com/watch?v=n32nblVVz1g
652 名前:デフォルトの名無しさん mailto:sage [2022/10/16(日) 04:55:55.59 ID:kNlIrq3k0.net] 間違えた、すまん
653 名前:デフォルトの名無しさん mailto:age [2022/10/19(水) 13:19:13.07 ID:1sfAoeRGa.net] Git v2.38.1
654 名前:デフォルトの名無しさん mailto:sage [2022/10/27(木) 07:22:57.17 ID:TnOoNEjS0.net] Git初心者でGit練習中の者だが、質問いい? 関数の履歴を見るコマンド Git log -L '/function myfunction/',/},/:myFile があり得ないほどメモリを食うのだが、これって今のところ仕様? それとも俺の使い方がまずい? 2MB程度のファイルを2800回程度コミットしたリポジトリがあって、git gc して12MBになってる。 これに対して上記コマンドが9.4GBメモリを食う。 おかげでMINGW32bit環境では全然駄目で、MINGW64bit環境だと上記の通り。 Linux64bit環境でもスワップを増やさないとコケたので4GB以上は食ってるはず。 (windowsでの結果をふまえ、スワップを9GBに増やした環境では動作した) Gitのバージョンは、Windowsは最新(2.38.1)で、Unixは2.20.1。 なお出力された内容には不満はない。 ただ、10-20行程度の関数が15個履歴として表示されるだけで、このメモリはあり得ない。 シェルスクリプトでも同じ物は得られるが、1GBすら行かないはず。 最初から最後までfreeしないでやってるとしか思えないが、何かそうなる理由ある? あと、オプション等で回避する方法があれば教えて。
655 名前:デフォルトの名無しさん mailto:sage [2022/10/28(金) 00:23:09.45 ID:yz6FOYrM0.net] LooseCompressionの全展開用の領域 2MB*2800=5.6GB git logは内部でlessにパイプでデータを渡してるから パイプバッファも含めて約2倍だろうか Packしなけりゃ少しはマシかもしれない(未確認)
656 名前:デフォルトの名無しさん mailto:sage [2022/10/28(金) 07:15:31.79 ID:HlXde3ci0.net] >Pack git gcのことか? なら実は当初はしてなくて1.2GBあったが、その時からコケてた。少なくとも2GBは食ってる。 その後gc出来ると知り、やってみたが、実際は自動で何回かやってるようだし、多分大勢は変わりない。 (実は全部新たにコミットし直すのも試してる) なお愚直にgit show -> 切り出し -> diff を繰り返すだけのスクリプトを作って試してみた。 メモリは普段の使用と変わりなかった。 ただ問題は時間で、12分程度かかる。これでは気軽には使えない。 MINGW64だと2分程度で済む。 時間がかかるのは一々ファイルにしてるから?だから、 /dev/fd/3等で全部でパイプに出来れば短縮出来るかも?、というところ。 (システムキャッシュに完全に載るサイズだから関係ないかも?だし、 そもそも2回ずつ使うのでパイプにフィットしないが) ただ現在でも初期画面は数分で出るし、出なければ大昔のコミットなのでどうせ問題なく、 実際の運用としては及第点ではある。でも速ければ速いに越した事はない。 Gitはおそらく速度重視なのだろう。 自動増加スワップのMINGW64環境なら現実的には大した問題にはならない。 ただ、全部メモリ上に展開する意味もメリットもないはずなので、 途中で一回もfreeしてないであろうこのコードは、コードとしては大問題だとは思うよ。 (ジョークで言われてる、Javaしか知らない奴が書いた、freeが一つもないコード、になってる)
657 名前:デフォルトの名無しさん mailto:sage [2022/10/28(金) 07:18:13.37 ID:RikIMzkC0.net] 報告してあげるといい事案だと感じる
658 名前:デフォルトの名無しさん mailto:sage [2022/10/29(土) 06:39:27.49 ID:J4pkDf7Q0.net] パイプへの変更は厳しいので、一時ファイルをRAMDISK上に配置してみたが所要時間は変化無し。 よってシステムキャッシュは効いてて、パイプにしても高速化予算はほぼ無いと分かった。 diffを切ったら8分、さらに切り出しを切っても8分(変化無し)、git showをgit --version に変更したら2分で終了した。 よって時間予算は gitプロセス起動が1/6(2分)、git show が1/2(6分)、切り出しはほぼ0、diffが1/3(4分)と判明。 git showを高速化する為には出来るだけ纏めて取り出すのがよく、 メモリ無限大なら全展開が一番速いのも事実だが、せめてコア数程度にして欲しい。 見てる限り特に先頭も末尾も異常に速くはならない為、 動画と同様に途中にスナップショットを適度に挟んでいるように見え、なら、全展開する必然性/妥当性はない。 (やってもそんなに速くはならないのにメモリを異常に消費する=スワップする分余計に遅くなる) >>636 これは開発者マシンなら最低でもRAM16GBでSSDだよね!というノリなら方針は間違ってない。 ただ、-n 100 とかで直近100コミットに絞れればいいだけなのだが、これが出来ないのが問題。 どうやってもいきなり9GB超掴みに行くのは使用勝手が悪い。そもそも最初の方の履歴なんてほぼ要らんし。
659 名前:デフォルトの名無しさん mailto:sage [2022/10/29(土) 08:37:46.51 ID:e5vmfD+T0.net] >>637 HEAD~100 とかじゃ駄目なの?
660 名前:デフォルトの名無しさん mailto:sage [2022/10/29(土) 08:44:53.54 ID:+5EirK6r0.net] いやバグレポートすればいいと思う
661 名前:デフォルトの名無しさん mailto:sage [2022/10/29(土) 09:15:13.77 ID:J4pkDf7Q0.net] >>638 実はそこは初心者過ぎてよく知らないんだわ。 git log HEAD~100 では制限出来なかったけど、どう書くべきなの? とりあえず公式マニュアルでは -n が最初に載ってるので、-n が一番お手軽なのだと思う。 これが効かないのは、多分実装忘れじゃないかと。 > https://www.git-scm.com/docs/git-log >>639 多分、メモリ大量使用は仕様で、-n が効かないのはバグだね。
662 名前:デフォルトの名無しさん mailto:sage [2022/10/29(土) 09:25:26.30 ID:+5EirK6r0.net] 合理性のないメモリ使用があるなら実害があるユーザーが改善のリクエストをバグレポートで出せばいい そういうもん レアケース扱いされることもあれば皆が困ってるようなら優先的にチューニングされる 仕様なのでは!?と空気読んで黙ってるのは奥ゆかしいニンジャ精神
663 名前:デフォルトの名無しさん mailto:sage [2022/10/29(土) 09:38:02.85 ID:J4pkDf7Q0.net] >>641 なるほどその通りだ。 ガイドラインが糞長げえ…orz が、数日のうちにレポートする方向でやります。 > https://www.chiark.greenend.org.uk/~sgtatham/bugs.html > https://www.git-scm.com/community 内の this guide が上記
664 名前:デフォルトの名無しさん [2022/10/29(土) 11:09:21.06 ID:+W9Ulup+0.net] >>640 手練れのエンジニアとお見受けするが、どのジャンルで仕事されているので?
665 名前:デフォルトの名無しさん mailto:sage [2022/10/29(土) 15:16:52.52 ID:e5vmfD+T0.net] >>640 HEAD~100..HEAD みたいなのを最後につけてレンジを制限する話だけど効かない?
666 名前:デフォルトの名無しさん [2022/10/29(土) 21:10:22.54 ID:YQqcaKMe0.net] git log -100 じゃなくて?
667 名前:デフォルトの名無しさん mailto:sage [2022/10/29(土) 23:05:25.26 ID:e5vmfD+T0.net] >>645 -100 と -n 100 と --max-count=100 は同じ意味で表示するログの数を制限する A..B はログを検索する対象を制限する。(Bには存在するけどAには存在しないコミットという意味になる)
668 名前:デフォルトの名無しさん mailto:sage [2022/10/30(日) 02:06:46.88 ID:IOU525bY0.net] >>644 効いた!ありがとう。 何ぞそれ?と思いきや git log のdocumentの頭に書いてあるのな。 > https://www.git-scm.com/docs/git-log gitは機能が多すぎてドキュメントがやたら長いので端折っていたのが敗因だ。 やはり最初は一通り読まないと駄目だな。 これなら回せばいいので、組んでみたら32bit環境で43秒で終了した。 これだと高速化チューニングではなく単にfree忘れっぽいのでレポートしておいた。 再現用のスクリプトも同梱してるから気になる人はどうぞ。 https://lore.kernel.org/git/CAFOPqVXz2XwzX8vGU7wLuqb2ZuwTuOFAzBLRM_QPk+NJa=eC-g@mail.gmail.com/T/#u
669 名前:デフォルトの名無しさん mailto:sage [2022/10/30(日) 09:36:57.12 ID:b5HYhcbp0.net] >>647 おつかれ。 慣れてくると git log とかは全ログ対象にはしなくて、素でレンジ指定するので、この手のリソース問題は見つけ難いんだよな。
670 名前:デフォルトの名無しさん mailto:sage [2022/10/30(日) 12:37:33.31 ID:IOU525bY0.net] >>648 初心者は意味不明な使い方を無自覚でやるから、どうしてもマイナーバグに当たりやすい。 なるほどタグを付けてgit logでは範囲指定がデフォか… ってそのままtutorialに書いてあったわ。やっぱちゃんと読まなきゃ駄目だったorz > https://www.git-scm.com/docs/gittutorial つまるところ、今までこんな馬鹿げた使い方をした奴は居なかっただけだな。
671 名前:デフォルトの名無しさん (ワッチョイ 497b-vCJ4) mailto:sage [2022/10/30(日) 18:58:14.60 ID:IOU525bY0.net] git diff の出力はデフォでpatchになってるのだが、これどうやったら切れるんだ? > https://www.git-scm.com/docs/git-diff#Documentation/git-diff.txt--p 既にフォーマッタを持っているので、 unixコマンドのdiffのデフォルト出力と同じ物が
672 名前:欲しい。 切るオプションも無いし、下の方のCONFIGURATIONにもそれらしい設定が見つからない。 diff.externalでdiffごと入れ替えないと駄目とかいうクソ仕様? -s や --no-patchでは出力そのものが出なくなる。ただし > or to cancel the effect of --patch. と書いてあるから、かつては--no-patchではdiffのデフォ出力で、-sで出力無しだった気配はあるが。 [] [ここ壊れてます]
673 名前:デフォルトの名無しさん (ワッチョイ 8bbb-VzUj) mailto:sage [2022/10/30(日) 21:37:56.23 ID:b5HYhcbp0.net] >>650 git diff は git diff 形式 (unified diff 形式の変形) で出力される。それ以外の形式が欲しい場合は外部コマンド使うしかない。
674 名前:デフォルトの名無しさん mailto:sage [2022/10/30(日) 22:10:12.22 ID:IOU525bY0.net] >>651 マジかー。クソ過ぎ。仕様考えた奴馬鹿すぎ。 スクリプトに食わす為に先頭の+-の文字を変更するオプションとかあるのだけど、 これでいいと思った奴は死ねだな。
675 名前:デフォルトの名無しさん mailto:sage [2022/10/30(日) 22:14:38.98 ID:b5HYhcbp0.net] >>652 git はパッチ管理システムなんだから、それ以外が考慮されてると思う方が贅沢。
676 名前:デフォルトの名無しさん mailto:sage [2022/10/30(日) 22:34:52.61 ID:IOU525bY0.net] >>653 いやそうじゃねえ。というかこれはソフトウェアの構成を間違ってるよ。 diffだってバグはあるのだから、内製は止めて、普通にdiffのdllをコールすべきなんだよ。 GitはLinusが1日で作ったらしいし、最初はどう考えてもそうなっていたはず。 だから俺は config の中にデフォで diff -u みたいなエイリアスがあるのかと思ってた。 diffを内包する事に、何のメリットもない。 この名残がexternal driverで、それが使えればいいという事なのだろうけど、 ご丁寧にこれを禁止するオプションまである。(-no-ext-diff) 多人数の開発では、同じ画面を見ていた方が何かと楽だから、揃える方向で努力するのはごもっともだが、 禁止するのは違う。どこかでおかしな思想が混入しているよ。 そもそも、それ以外を考慮しない=外部コマンドで十分出来る事はdllを呼ぶ、であって、 この構成だとGitがdiffも構成してるから、君は認識を間違ってる。 Gitは明らかにおかしい方向で無駄な事をやってしまっている。 そしてそれは君の価値観的にもNGなはずだよ。
677 名前:デフォルトの名無しさん mailto:sage [2022/10/30(日) 23:37:53.37 ID:b5HYhcbp0.net] >>654 Linus のこと知ってるのなら長文書く前に調べろ。 git 作る以前から、みんなが勝手なフォーマットでパッチ送って来るのは非常に困るので推奨のパッチ形式を決めてあったんだよ。 で git 作る時に強制的にその形式に統一されるようにした。どうしても他の形式で出したい場合はひと手間かかるのが設計意図どおり。
678 名前:デフォルトの名無しさん mailto:sage [2022/10/30(日) 23:53:15.06 ID:LXgcbV870.net] Linusも言ってたような気がするけど、気に食わなければ自分で作れ 以上
679 名前:デフォルトの名無しさん mailto:sage [2022/10/30(日) 23:58:47.31 ID:IOU525bY0.net] >>655 Linusはデフォを -u にして、patch送るならオプション無しで送れ、としただけでしょ。 これは間違ってない。 問題は、元のdiffの形式の出力が出来なくなってる事だよ。 オプションで出来るよ、でよかっただけ。 オプションすら禁止なら、今のgit diff に各種出力オプションがあること自体が君的に矛盾するだろ。 何故君がそんな意味不明なポジショントークをするのか分からないが、 Gitが方針を間違ってるのは事実だよ。 オプション禁止なら、git diff にオプションを何一つ付けてはいけない。 (仮にこれであれば、賛同はしないが理解はする) ただまあ、ドキュメントの雰囲気だと、 おそらく昔は --no-patch で元のdiff形式が出せたのではないかと推測される。 君がどこまで知っているのか知らないけど、多分君の歴史理解も間違ってると思うよ。
680 名前:デフォルトの名無しさん mailto:sage [2022/10/31(月) 00:04:41.05 ID:h5Hfu9WR0.net] >>657 お前以外は誰もオプションとか必要ないから作ってないだけだよ。むしろ邪魔。どうしてもやりたければ外部コマンド指定でできるんだからオプションとかでやるよりよっぽど汎用性がある。 オープンソースなんだからオプション必要ならお前が自分でつくればいい。
681 名前:デフォルトの名無しさん mailto:sage [2022/10/31(月) 00:08:19.51 ID:h5Hfu9WR0.net] あと −−no-patch には昔からパッチ出さない機能しかないぞ。頭悪い推測とかする暇があったら過去のソース確認してこい。 それこそ git で調べればすぐだぞ
682 名前:デフォルトの名無しさん mailto:sage [2022/10/31(月) 00:21:01.40 ID:J+3pjzxx0.net] >>859 そうか?ならマニュアルの > to cancel the effect of --patch の部分は明らかに不要だから削除要請出しといてくれ。 というか君の「昔」がどれ位か知らんが、Linusの言ってた?フォーマットが統一されてないってのは、 diffの各種オプションではなく、edやsharに対してだと思うぞ。
683 名前:デフォルトの名無しさん mailto:sage [2022/10/31(月) 00:43:54.22 ID:h5Hfu9WR0.net] >>660 不要だと思ってるのはお前だけ。その思い込みが勘違いの原因だろ。
684 名前:デフォルトの名無しさん (ワッチョイ 497b-vCJ4) mailto:sage [2022/10/31(月) 07:08:10.92 ID:J+3pjzxx0.net] 色々確認したが、Gitの現状認識としては651であってるっぽい。 そして外部ツール使うしかないが、これは環境設定無しでコマンドだけで出来る。(動作確認済み) git difftool --extcmd=/usr/bin/diff <commit> <commit> > https://qastack.jp/programming/255202/how-do-i-view-git-diff-output-with-my-preferred-diff-tool-viewer ついでにその中、 > Gitについて学ぶほど、それは1人の人、つまり元のプログラマーのために作られたものだと感じます。 これもよく言われてるようだが、俺も今回の件で同意だ。 合理性に欠ける判断をしているのだから色々文句言われるのも当然だ。 ただLinusは自分用に作った物を公開したら勝手に使われてるだけだから、知ったこっちゃ無いってのも分かる。 ただそれならそうと、いつもの調子でドキュメントにも書いててくれないと困るね。 合理的な構成を推定すると迷子になってしまう。 俺は絶対に diff -u 以外のフォーマットを許さない!絶対にだ! とか書いてあれば、最初から諦めるので無駄に探す必要はなかった。 俺はLinusのこういった感情的な部分はわりと好きなのだが、まあ昨今の code of conduct では書いても消されるんだろうけども。
685 名前:デフォルトの名無しさん mailto:sage [2022/10/31(月) 10:11:41.92 ID:J+3pjzxx0.net] てかGitってまさかのモノリシックかよ! こりゃ文句言われるのも分かるわ。完全に方向を間違ってる。 結果的に肥大化していったのだろうけど、現在の状況でこれは駄目だよ。 つかこれシェル化する方向のプロジェクトはないの? 子コマンド群のバイナリだけ貰いたいんだけどさ。
686 名前:デフォルトの名無しさん mailto:sage [2022/10/31(月) 10:39:47.64 ID:sko8U7ef0.net] >>663 好きに fork しなよ。
687 名前:デフォルトの名無しさん mailto:sage [2022/10/31(月) 12:23:13.35 ID:h5Hfu9WR0.net] 自分でやってみればいいよ。 自分で多数の人が参加する巨大なプロジェクトを管理するようになれば、形式が統一されていることがどれだけ重要かわかる。 仕様を強制されているようでも、これこそが git の使い易さ、戦闘証明済の実力だと気付くよ。空想と現場は違う。
688 名前:デフォルトの名無しさん mailto:sage [2022/10/31(月) 13:21:07.66 ID:J+3pjzxx0.net] >>665 それが従来形式のdiffの出力をさせない理由なら、 現在のGitプロジェクトの思想は俺とまるで合わない。 今時モノリシックとか、多分じきにこのプロジェクトは頓挫するよ。 multicsの再来だね。(俺は使ったこと無いけど) 自覚症状もあるみたいだし。 > Git is a fast, scalabl
689 名前:e, distributed revision control system with an unusually rich command set > unusually > https://www.git-scm.com/docs/git ただまあ本当にdiffも内製しているようで、ちょっと驚きだよ。 ただwikiによると当初はローレベルエンジン+シェルスクリプトで、これは俺の思想と合致してる。 windowsに移植する際にシェルスクリプトをCに書き換え、そこでモノリシック化したようだ。 それで環境変数を見るとか、完全に開発の方向性を間違ってる。 当初のシェルスクリプト方式ならdiffを呼ぶだけだから、シンボリックリンクで好きなのと簡単に交換出来た。 この場合、Git側にコードは全く必要ないし、ユーザー側に予備知識も必要ない。 それをモノリシックにしてしまったから、環境変数を読むコードを必要とし、 ユーザーはマニュアルを読むことを強制させられる。 お互いに完全に無駄だ。 このメンテナは、ソフトウェアアーキテクチャはどうあるべきか、全く理解出来てない。 今ですらGitは難しすぎると文句言われてるだろ。 コードを書く為にコード管理システムの勉強が必要とか、完全に本末転倒だし。 じきに巨大な躯体を支えきれなくなって、分割プロジェクトが発生すると思うぜ。 それが多分Next-gitになるのだろうよ。 つか、何でGitはモノリシックを選択してんの?全く意味ねえと思うぞマジで。 本当にdiffとかを絶対に交換させない為?ならマジで死ねでしかないね。 [] [ここ壊れてます]
690 名前:デフォルトの名無しさん mailto:sage [2022/10/31(月) 14:15:23.19 ID:Yrczlr02M.net] Simple is not easy Gitは後者を選択することでSIerのドカタまで幅広く受け入れられたということだ
691 名前:デフォルトの名無しさん mailto:sage [2022/10/31(月) 14:29:14.51 ID:Pk1WyFqz0.net] (だからgit difftoolが用意されてんだろと言いたいけど、linux原理主義者みたいだし黙っとこう)
692 名前:デフォルトの名無しさん (ワッチョイ 497b-vCJ4) mailto:sage [2022/10/31(月) 15:04:18.65 ID:J+3pjzxx0.net] >>667 他よりましなだけだろ。 ただ俺が思うに、Gitはもっと簡単に出来て、 ・勉強しないといけないGit(今) ・勉強しなくてもなんとなく使えちゃうGit(次世代) に分離すると思うよ。次世代版の需要圧力はもう既に十分あるし。 実のところ、今のgitにラッパシェルスクリプト群を被せれば次世代版出来ちゃうし、 (勿論見た目だけだがそれが重要) 俺はそれ作って使おうかとも思案中。 Gitは業務プロセス名のコマンドだから、実際何が起こっているのか分かりにくいのが一番の問題だよ。 コマンド名変えるだけでも相当変わる。
693 名前:デフォルトの名無しさん (ワッチョイ 497b-vCJ4) mailto:sage [2022/10/31(月) 15:05:02.85 ID:J+3pjzxx0.net] >>668 それに辿り着くのにググったりマニュアルを読まないといけないのが問題なんだよ。 今のGitは世界中のプログラマに努力を強いてて、その犠牲の上に成り立ってる。 3時間程度あれば、再現コード付きのバグ報告が出来てしまう。 それをマニュアルを読むのに費やしてるのだから、無駄でしょ。 世界中のプログラマが3時間を世界が進歩する方向に費やせたら、Gitももっとよくなってたはずだよ。
694 名前:デフォルトの名無しさん mailto:sage [2022/10/31(月) 15:39:10.00 ID:oV1LtMOH0.net] それは世界中の人が俺に1円を恵んでくれたら 俺は大金持ちになっていたと言っているようなもんだな
695 名前:デフォルトの名無しさん mailto:sage [2022/10/31(月) 15:57:50.61 ID:h5Hfu9WR0.net] >>670 もっと良い物ができると主張するんなら作って広めてから出直してこい もともと git を使ってきたやつらがどういう連中かわかって無さ過ぎ linux カーネルコミュニティとか、文句言ってる暇があったらコード書いて変更した方が速いってやつらばかりだぞ そういう連中がのべ何万人も十年以上使い続けた結果で今の仕様になってる。本当に問題だったら誰かがとっくに直してる お前にはこの言葉を贈ろう「馬鹿でも使えるものは馬鹿しか使わない」
696 名前:デフォルトの名無しさん mailto:sage [2022/10/31(月) 16:18:24.02 ID:SCCWpcRv0.net] gitにdiffの書式の多様性を求めるなら、自分が使ってるコマンドの方を多様性を受け入れるようにすれば良いんじゃね