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 USP研究所のシェルスクリプトマガジンを購読しているけど、 こんな人がライターなのか? いささかガッカリした。 バイナリに見えるのはgzip圧縮されてるだけでgitconfigに compression=0 loosecompression=0 を書いておくと無圧縮のテキストになったような >>593 せっかく覚えたのにバージョン管理ツールが変わって知識が役に立たなくなると言っておるのだ シェルスクリプトなら20年後も今の知識が通用する https://www.slideshare.net/ShellShoccarJpn/posix-59780910 ちなみにgitのリポジトリは、ブランチ、コミット履歴、データ(ファイル)の3種類を それぞれsha1ハッシュで繋いでいるだけのシンプルな構造 リポジトリをバラしてファイルを取り出すだけのプログラムなら大体の人は1日もあれば作れるよ >>598 さすがに1日もかからんやろ。スクリプト言語使って15分とかそんな感じでは。 >>598 ならばそのsha1ハッシュをPOSIXの範囲で作ってみよ POSIX準拠で仕様が許されてるハッシュ化コマンドはcksumのみだ 我らはbase64コマンドをawkで作ってみせた >>602 アホはスクリプト言語で書いた。 普通の人は速度出したいのでそういう用途にはCコンパイラ使う。POSIXにC言語の規定がないとでも思ってるんだろうな。 >>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つの利点がある. >>604 シェルスクリプトが遅いなどというのも間違いだ。 それはストリーミング型の書き方を知らない愚か者の戯言だ 3.1.1 開発効率と処理効率の両立 シェルスクリプトはC言語と比べて処理の遅さを指摘されるが,それは必ずしも正しい認識ではない. シェルスクリプトはインタプリタ型言語であるため,ステップ数が多いほど処理効率は悪化する. また各ステップに外部コマンドを起動する記述があればそれも大きな処理効率悪化につながる. しかし,手続き型の書き方からストリーミング型の書き方に改めるように工夫すれば, ステップ数の増加を抑えられ,処理効率は大きく改善する. >>606 じゃあ、お前がシェルスクリプトで git 書けばいいんじゃね? 俺はバイトオーダーに依存しないCプログラムの書き方知ってるのでそっち使うけど。 >>607 我らはすでにシェルスクリプトでバージョン管理を行うすべを持っておる gitを書く必要などない 知りたくばこれを買ってPOSIX主義的バージョン管理概論を読め https://richlab.org/coterie/lpf.html >>608 ゴミを勧めんな。オライリーに訴えられてろ。 >>609 ゴミならば大学の教科書になっておらぬわ forkで2つのコミットの差分どうやって見るの? 履歴から2つ選択しても出ない。コンテキストメニューも。未実装? 以前作ったリポジトリの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して古いリポジトリは退避、以後は新しいのを使うことも考えてますがどうでしょうか >>610 大学には頭おかしいのがおらんとでも? 大学全体の何割が使ってるか言ってみ。 どうせ安全じゃないだろw >fatal: detected dubious ownership in repository at こんなものつけるなよカス >>613 大学だけじゃないぞ プログラマならシェルスクリプトマガジンぐらい知っておろう そこに長期連載されているほど、普及しておる 頭がおかしいなら、こんなに長く連載されるはずがないな >>615 シェルスクリプトなぁ……簡単な作業の自動化用途だな。 なんでgitスレでこんな話題が? NG指定したほうがいい? >>612 set-headサブコマンドが使えるみたい >>616 愚か者め。シェルスクリプトは何でも出来る。CGIも作れた。 この間はUNIX哲学に基づいてリアルタイムカーネルなしに シェルスクリプトだけでリアルタイム処理を実現してみせたわ https://www.sea.jp/ss2021/download/11-SS2021.pdf >>616 gitのような目的を見失ったバージョン管理ソフトを使っているからだ バージョン管理ソフトはライブラリよりも長く行き続けなければならんものだが リポジトリでわけのわからんバイナリ形式を使っておるから バージョン管理ソフトが滅んだら復元は不可能になる。一体何を考えておるのか。 「データはテキスト形式で保存しろ」とはUNIX哲学でも言われている。 容れ物が古くなったら新しい容れ物に中身を移すだけ。 >>620 よくもまあ懲りもせずにといったところだな そうやって古くなったソフトを捨て新しいものに入れ替え せっかく覚えた知識は無駄になり移行作業で苦しむ POSIX原理主義なら一度覚えた知識は一生使うことが出来る 新しいことを覚える必要はない 啓蒙したいんだろうけど >新しいことを覚える必要はない これ読んで「そんなメリットがあるなら俺もPOSIX原理主義に入信しよう」と考えるエンジニアがいるもんかね。 >>617 git remote set-headだとリモートトラッキングブランチのHEADが変わっただけでベアリポジトリ側のHEADは変わらず、 HEADが指してるブランチ(master)も削除操作が利かないままだったんですが、もうちょっと教えてもらえませんか >>621 いいから、お前は黙ってシェルスクリプトでOSカーネルでも書いとけ。完成するまで戻って来るな。 啓蒙したいんじゃなくて単に荒らしたいだけだから だいたいオープンソースなのにソフトウェアが滅ぶとか意味がわからん シェルスクリプトのヤツは釣りだろ? マジでいってんだったら頭おかしいだろw (基地外を釣るエサ投下) >>627 いいからお前はシェルスクリプトでカーネル書く作業に戻れ。シェルスクリプトがあれば何でもできるんだろ。 >>628 勘違いしてるぞ。俺は人格者(笑)って書き込んだだけだぞ Shelling at Russian power plant leaves Belgorod without electricity https://www.youtube.com/watch?v=n32nblVVz1g 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しないでやってるとしか思えないが、何かそうなる理由ある? あと、オプション等で回避する方法があれば教えて。 LooseCompressionの全展開用の領域 2MB*2800=5.6GB git logは内部でlessにパイプでデータを渡してるから パイプバッファも含めて約2倍だろうか Packしなけりゃ少しはマシかもしれない(未確認) >Pack git gcのことか? なら実は当初はしてなくて1.2GBあったが、その時からコケてた。少なくとも2GBは食ってる。 その後gc出来ると知り、やってみたが、実際は自動で何回かやってるようだし、多分大勢は変わりない。 (実は全部新たにコミットし直すのも試してる) なお愚直にgit show -> 切り出し -> diff を繰り返すだけのスクリプトを作って試してみた。 メモリは普段の使用と変わりなかった。 ただ問題は時間で、12分程度かかる。これでは気軽には使えない。 MINGW64だと2分程度で済む。 時間がかかるのは一々ファイルにしてるから?だから、 /dev/fd/3等で全部でパイプに出来れば短縮出来るかも?、というところ。 (システムキャッシュに完全に載るサイズだから関係ないかも?だし、 そもそも2回ずつ使うのでパイプにフィットしないが) ただ現在でも初期画面は数分で出るし、出なければ大昔のコミットなのでどうせ問題なく、 実際の運用としては及第点ではある。でも速ければ速いに越した事はない。 Gitはおそらく速度重視なのだろう。 自動増加スワップのMINGW64環境なら現実的には大した問題にはならない。 ただ、全部メモリ上に展開する意味もメリットもないはずなので、 途中で一回もfreeしてないであろうこのコードは、コードとしては大問題だとは思うよ。 (ジョークで言われてる、Javaしか知らない奴が書いた、freeが一つもないコード、になってる) パイプへの変更は厳しいので、一時ファイルを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超掴みに行くのは使用勝手が悪い。そもそも最初の方の履歴なんてほぼ要らんし。 >>638 実はそこは初心者過ぎてよく知らないんだわ。 git log HEAD~100 では制限出来なかったけど、どう書くべきなの? とりあえず公式マニュアルでは -n が最初に載ってるので、-n が一番お手軽なのだと思う。 これが効かないのは、多分実装忘れじゃないかと。 > https://www.git-scm.com/docs/git-log >>639 多分、メモリ大量使用は仕様で、-n が効かないのはバグだね。 合理性のないメモリ使用があるなら実害があるユーザーが改善のリクエストをバグレポートで出せばいい そういうもん レアケース扱いされることもあれば皆が困ってるようなら優先的にチューニングされる 仕様なのでは!?と空気読んで黙ってるのは奥ゆかしいニンジャ精神 >>641 なるほどその通りだ。 ガイドラインが糞長げえ…orz が、数日のうちにレポートする方向でやります。 > https://www.chiark.greenend.org.uk/ ~sgtatham/bugs.html > https://www.git-scm.com/community 内の this guide が上記 >>640 手練れのエンジニアとお見受けするが、どのジャンルで仕事されているので? >>640 HEAD~100..HEAD みたいなのを最後につけてレンジを制限する話だけど効かない? >>645 -100 と -n 100 と --max-count=100 は同じ意味で表示するログの数を制限する A..B はログを検索する対象を制限する。(Bには存在するけどAには存在しないコミットという意味になる) >>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 >>647 おつかれ。 慣れてくると git log とかは全ログ対象にはしなくて、素でレンジ指定するので、この手のリソース問題は見つけ難いんだよな。 >>648 初心者は意味不明な使い方を無自覚でやるから、どうしてもマイナーバグに当たりやすい。 なるほどタグを付けてgit logでは範囲指定がデフォか… ってそのままtutorialに書いてあったわ。やっぱちゃんと読まなきゃ駄目だったorz > https://www.git-scm.com/docs/gittutorial つまるところ、今までこんな馬鹿げた使い方をした奴は居なかっただけだな。 git diff の出力はデフォでpatchになってるのだが、これどうやったら切れるんだ? > https://www.git-scm.com/docs/git-diff#Documentation/git-diff.txt--p 既にフォーマッタを持っているので、 unixコマンドのdiffのデフォルト出力と同じ物が欲しい。 切るオプションも無いし、下の方のCONFIGURATIONにもそれらしい設定が見つからない。 diff.externalでdiffごと入れ替えないと駄目とかいうクソ仕様? -s や --no-patchでは出力そのものが出なくなる。ただし > or to cancel the effect of --patch. と書いてあるから、かつては--no-patchではdiffのデフォ出力で、-sで出力無しだった気配はあるが。 >>650 git diff は git diff 形式 (unified diff 形式の変形) で出力される。それ以外の形式が欲しい場合は外部コマンド使うしかない。 >>651 マジかー。クソ過ぎ。仕様考えた奴馬鹿すぎ。 スクリプトに食わす為に先頭の+-の文字を変更するオプションとかあるのだけど、 これでいいと思った奴は死ねだな。 >>652 git はパッチ管理システムなんだから、それ以外が考慮されてると思う方が贅沢。 >>653 いやそうじゃねえ。というかこれはソフトウェアの構成を間違ってるよ。 diffだってバグはあるのだから、内製は止めて、普通にdiffのdllをコールすべきなんだよ。 GitはLinusが1日で作ったらしいし、最初はどう考えてもそうなっていたはず。 だから俺は config の中にデフォで diff -u みたいなエイリアスがあるのかと思ってた。 diffを内包する事に、何のメリットもない。 この名残がexternal driverで、それが使えればいいという事なのだろうけど、 ご丁寧にこれを禁止するオプションまである。(-no-ext-diff) 多人数の開発では、同じ画面を見ていた方が何かと楽だから、揃える方向で努力するのはごもっともだが、 禁止するのは違う。どこかでおかしな思想が混入しているよ。 そもそも、それ以外を考慮しない=外部コマンドで十分出来る事はdllを呼ぶ、であって、 この構成だとGitがdiffも構成してるから、君は認識を間違ってる。 Gitは明らかにおかしい方向で無駄な事をやってしまっている。 そしてそれは君の価値観的にもNGなはずだよ。 >>654 Linus のこと知ってるのなら長文書く前に調べろ。 git 作る以前から、みんなが勝手なフォーマットでパッチ送って来るのは非常に困るので推奨のパッチ形式を決めてあったんだよ。 で git 作る時に強制的にその形式に統一されるようにした。どうしても他の形式で出したい場合はひと手間かかるのが設計意図どおり。 Linusも言ってたような気がするけど、気に食わなければ自分で作れ 以上 >>655 Linusはデフォを -u にして、patch送るならオプション無しで送れ、としただけでしょ。 これは間違ってない。 問題は、元のdiffの形式の出力が出来なくなってる事だよ。 オプションで出来るよ、でよかっただけ。 オプションすら禁止なら、今のgit diff に各種出力オプションがあること自体が君的に矛盾するだろ。 何故君がそんな意味不明なポジショントークをするのか分からないが、 Gitが方針を間違ってるのは事実だよ。 オプション禁止なら、git diff にオプションを何一つ付けてはいけない。 (仮にこれであれば、賛同はしないが理解はする) ただまあ、ドキュメントの雰囲気だと、 おそらく昔は --no-patch で元のdiff形式が出せたのではないかと推測される。 君がどこまで知っているのか知らないけど、多分君の歴史理解も間違ってると思うよ。 >>657 お前以外は誰もオプションとか必要ないから作ってないだけだよ。むしろ邪魔。どうしてもやりたければ外部コマンド指定でできるんだからオプションとかでやるよりよっぽど汎用性がある。 オープンソースなんだからオプション必要ならお前が自分でつくればいい。 あと −−no-patch には昔からパッチ出さない機能しかないぞ。頭悪い推測とかする暇があったら過去のソース確認してこい。 それこそ git で調べればすぐだぞ >>859 そうか?ならマニュアルの > to cancel the effect of --patch の部分は明らかに不要だから削除要請出しといてくれ。 というか君の「昔」がどれ位か知らんが、Linusの言ってた?フォーマットが統一されてないってのは、 diffの各種オプションではなく、edやsharに対してだと思うぞ。 >>660 不要だと思ってるのはお前だけ。その思い込みが勘違いの原因だろ。 色々確認したが、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 では書いても消されるんだろうけども。 てかGitってまさかのモノリシックかよ! こりゃ文句言われるのも分かるわ。完全に方向を間違ってる。 結果的に肥大化していったのだろうけど、現在の状況でこれは駄目だよ。 つかこれシェル化する方向のプロジェクトはないの? 子コマンド群のバイナリだけ貰いたいんだけどさ。 自分でやってみればいいよ。 自分で多数の人が参加する巨大なプロジェクトを管理するようになれば、形式が統一されていることがどれだけ重要かわかる。 仕様を強制されているようでも、これこそが git の使い易さ、戦闘証明済の実力だと気付くよ。空想と現場は違う。 >>665 それが従来形式のdiffの出力をさせない理由なら、 現在のGitプロジェクトの思想は俺とまるで合わない。 今時モノリシックとか、多分じきにこのプロジェクトは頓挫するよ。 multicsの再来だね。(俺は使ったこと無いけど) 自覚症状もあるみたいだし。 > Git is a fast, scalable, 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とかを絶対に交換させない為?ならマジで死ねでしかないね。 Simple is not easy Gitは後者を選択することでSIerのドカタまで幅広く受け入れられたということだ (だからgit difftoolが用意されてんだろと言いたいけど、linux原理主義者みたいだし黙っとこう) >>667 他よりましなだけだろ。 ただ俺が思うに、Gitはもっと簡単に出来て、 ・勉強しないといけないGit(今) ・勉強しなくてもなんとなく使えちゃうGit(次世代) に分離すると思うよ。次世代版の需要圧力はもう既に十分あるし。 実のところ、今のgitにラッパシェルスクリプト群を被せれば次世代版出来ちゃうし、 (勿論見た目だけだがそれが重要) 俺はそれ作って使おうかとも思案中。 Gitは業務プロセス名のコマンドだから、実際何が起こっているのか分かりにくいのが一番の問題だよ。 コマンド名変えるだけでも相当変わる。 >>668 それに辿り着くのにググったりマニュアルを読まないといけないのが問題なんだよ。 今のGitは世界中のプログラマに努力を強いてて、その犠牲の上に成り立ってる。 3時間程度あれば、再現コード付きのバグ報告が出来てしまう。 それをマニュアルを読むのに費やしてるのだから、無駄でしょ。 世界中のプログラマが3時間を世界が進歩する方向に費やせたら、Gitももっとよくなってたはずだよ。 それは世界中の人が俺に1円を恵んでくれたら 俺は大金持ちになっていたと言っているようなもんだな >>670 もっと良い物ができると主張するんなら作って広めてから出直してこい もともと git を使ってきたやつらがどういう連中かわかって無さ過ぎ linux カーネルコミュニティとか、文句言ってる暇があったらコード書いて変更した方が速いってやつらばかりだぞ そういう連中がのべ何万人も十年以上使い続けた結果で今の仕様になってる。本当に問題だったら誰かがとっくに直してる お前にはこの言葉を贈ろう「馬鹿でも使えるものは馬鹿しか使わない」 gitにdiffの書式の多様性を求めるなら、自分が使ってるコマンドの方を多様性を受け入れるようにすれば良いんじゃね gitにとってファイルの差分を抽出する機能は、単にユーザへ表示したりパッチをつくるだけじゃなくて、gitの特徴的なマージやリベースを実現するための核心的機能なんだよ なので専用のものを内製する意味はある >>671 OSSが世界中のプログラマからの元気玉なのは事実だろ 元気をマニュアルに消費されてなければ、もっと大きな元気玉になってただろうよ 初歩的な質問ですが教えてください。 コミットの履歴が汚くなった場合、皆さんはどのように管理されてますでしょうか? 具体的には、 gitでdevelopからブランチを切ったAで作業しました。 ブランチAのコミット履歴が汚くなったので 新たに作成するブランチBにブランチAで変更したファイルを 一回のコミットで整理したいです。 git cherry-pick -n fromID..toID などで整理しているのでしょうか? >>672 > のべ何万人も十年以上使い続けた結果 それは言いすぎ。カーネルコミュニティって400人規模と聞いた覚えがある。 毎年全員入れ替わっても1万人規模だよ。 まあこれは本質ではないのでいいが。、 > 「馬鹿でも使えるものは馬鹿しか使わない」 これって誰の言葉だ?Linusが > マジで、Cを選択する理由が「何もなかった」としてもだ、C++プログラマー避けになるというだけで、Cを使う大義名分になる。 > https://cpplover.blogspot.com/2013/05/linus-torvalsc.html と言ってるのは知ってるが。(しかもこれはGitの話らしい) ちなみに俺はLinusの意見にも賛同する。プロジェクトに馬鹿が混入しないことは本当に重要なことだ。 ただ君と根本的に違うのは、「簡単は正義」と思ってることだ。 簡単に出来るのなら、簡単な方がいい。 馬鹿をふるい落とす為に敢えて難しい構造やコードにすることはない。 俺が見る限りLinusもそうしているわけではないが、君がそうしたいのは理解した。 まあ機会があれば実装して広めることになるかもしれない。 ただ俺は別のことをやろうとしてるから、Gitなんて動けば何でもいい程度でしかないので、優先順位は極めて低い。 あとたぶん、君は > 文句言ってる暇があったらコード書いて変更した方が速い の意味を誤解している。が、これは今言っても通じないと思う。 しょう1「かけざんよりもたしざんのほうがかんたんだ!かんじよりもひらがなのほうがかんたんだ!」 >>678 > ただ俺は別のことをやろうとしてるから、Gitなんて動けば何でもいい程度でしかないので、優先順位は極めて低い。 これまでの開発者を含めて他の人もそうだっただけという可能性に思い至れば何の不思議もないことなのに。 >>674 不可欠な機能ではあるが、核心的機能ではない。 事実として、Git内のdiffをGNUdiffに差し替えても、マージやリベースが出来なくなるわけではないだろ。 Gitは方針を間違ってる。 もし仮にGNUdiffのアルゴリズムが糞過ぎて出力が糞でマージが出来ないとしても、 アルゴリズム部分はGNUdiffにcontributeし、Gitがそのソースコードを使えばいいだけ。 Git内のdiffもGNUdiffからforkしたのだろうし、普通はこうすると思うけど。 別に実装すべきなのはフォーマッタで、--word-diffとかの部分だよ。 勿論GNUdiffに入れるのがベストだが、この辺は断られてもおかしくないし。 ただこれも人間用であって、マージする為に必要な機能部分ではないから、 君らから見てもGitではなくdiffに入れておけ、となるはずだが。 まあdiffに手を入れたくなるのは分かるが、それはソフトウェア開発ではやってはいけない方向で、 我慢してGNUdiffにcontributeしておく方が全体の長期的利益になるんだよ。 Gitがこの辺、アルゴリズムとViewをごちゃ混ぜに扱ってるのも気になる。 MVCとかまるで言われない世界ではあるけど、それでも基本として理解しておくべきだよ。 ビューを分離しておくことはものすごく重要だから。 え?まさかgit diffを差分を見るだけのツールだと思ってるの? GNU diffに依存したら、GNU diffが使われないところで 動かないってわからんかなぁ diffは移植性低いんだよ? ちなみに652で既に言ったが > --output-indicator-new=<char> > --output-indicator-old=<char> > --output-indicator-context=<char> > Specify the character used to indicate new, old or context lines in the generated patch. Normally they are +, - and ' ' respectively. > https://www.git-scm.com/docs/git-diff このオプションが相当にヤバい。 これはデフォで diff | less となってる部分を、 diff --output-indicator-new='>' | less とすれば幸せになれますよ、ということだが、これは diff | sed 's/^\+/>/' | less とすれば出来ることなので、gnuにこれを提案しても当然「そんなんイラネーよ」で終わってしまう。 Cで実装すべき案件ではないから。 そこで何故断られたのかを理解せず、だったらforkしますのノリなので、完全に無能の働き者だよ。 多分こいつらは本当にCしか書けない、Cしか知らない連中だ。 sed/awk/perl/python/rubyのどれかでも少しでも出来れば、この発想にはならない。 コントリビューターがこれを出してくるのも、メンテナがこれを止めないのも狂ってる。 プロジェクトにはいまだに正規表現を書けない老害しかいないと分かる。 だからこのオプションは、Linus的に言えば、常識的なプログラマー除けにはなってしまってるだろうよ。 git diffはパッチファイルを作るために利用されるし、 diffは環境依存するコマンドなんだから、 そんなのに依存したら、gitの移植性が低くなる 別の環境で実行したら、diffコマンドの出力がおかしくて 正しくパッチ当てられませんとかなったら困るやろ 常識で考えろや >>685 > とすれば出来ることなので、gnuにこれを提案しても当然「そんなんイラネーよ」で終わってしまう。 あのさぁ、提案するのはGNUだけじゃだめだって理解してないの? >>684 どういう意味? 少なくともどのプラットフォームにもdiffはあるだろ。 >>682 diff.externalやdifftoolによる置き換えは差分表示に使うdiffを置き換えるだけで、git内部でマージやリベースを行うための差分抽出には使わないだろ ん? これはもしかして以前来てたPOSIX原理主義者氏か? >>688 全部同じ実装じゃねーよ それぞれ全部細かい違いがある すべてのプラットフォームのdiffにまで対応するなんて 大変な作業なんて誰もやろうとは思わん 例えば2004年版のdiffには-uがないからな The Open Group Base Specifications Issue 6 https://pubs.opengroup.org/onlinepubs/009604499/utilities/diff.html >>686 > diffは環境依存するコマンド は? まあ仮にそうだったとして、Git内のdiffがあらゆる環境で同じdiffを生成するように小細工してるとでも? ただまあこの場合、ぶっちゃけ、小細工出来る=原因が分かってる≒多分Intサイズとかの違い、だから、 リモートリポジトリのマージで(俺は実際何を送ってくるのか知らんが)diffを送ってくるのなら、 それはマージ時点で鯖に問い合わせてdiffで済むかファイル本体を送らせてローカルでdiff取るかすればいいだけでしょ。 正直、原因究明して小細工するより後者の方が断然楽なので、合理的判断ならそうしてると思うけど。 >>691 前後したが上記。 >>689 その内部でマージやリベースを行う為のdiffをGNUdiffのdllコールと置き換えて、 マージやリベースが動かなくなるかって話だよ。普通に動くと思うけど。 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる