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 Windows版のSourceTreeがクソダサなのは何かの嫌がらせなの 以前GitHubへSSH認証で接続したことがあったので、
GitBashでssh -T git@github.comと入力してみたのですが、
Permission denied (publickey).と表示され、接続を拒否されてしまいました
どう対処すればよいでしょうか？ gitに関係ないのでこっちで質問してください
ｿｰｽｺｰﾄﾞ ﾎｽﾃｨﾝｸﾞ総合【GitHub,GitLab,Bitbucket等】
https://mevius.5ch.net/test/read.cgi/tech/1531824290/ >>547
SourceTreeなんてゴミ使うかよｗ
よっぽどTortoiseGitの方が使いやすいわｗ >>547
ワーキングツリーの差分をフラットに扱う、について詳しく教えてもらえませんか。
fetchするときだけSourceTree使ってるんですが、いい点があるなら知りたいです
差分の見た目はgitkと同じだと感じてまして。 あ、わかりました。
TortoiseGitの、エクスプローラのオーバーレイと比較してるんですね。 TortoiseGitのオーバーレイって別に全OFFでもいいんだよな
もっさり感とかのマイナスイメージの原因でもある
コンソールを開いてないときに全体がダーティかどうかが見えるか程度のメリット TortoiseGitはシェルエクステンションの時点でインスコする気失せる git使うなら開発者が愛用してるEmacsのmagitを使おうぜ そうなんだ、fork使ってみようかな
windowsしか知らないけど、sourcetreeだとdiffの横スクロールが使いづらい。
hunkごとに子scrollviewで表示するんだけど、親のscrollviewを下にスクロールしてからじゃないと、子の横スクロールバーが出てこない。
あとダブルクリックでExternal diffできないのも辛い。
さらにコミット画面が、履歴と別の画面なのが個人的にはイヤ。
履歴表示で、コミットをつなぐ線にヒット判定がないのも見ずらい。 fork使ってみましたがなかなかいいですね。
自分にはSourceTreeより合っているようだ。 女性二人が書いた売れ筋の入門書を読んでいてもGitについて、どういうものなのかハッキリしないのですが、
分かりやすく解説している本またはサイトを教えてください。 使い方が分からないという話？
それともソース管理がイマイチ分からない話？ なんでGitが必要なのでしょうか？
シェルスクリプトでcpしてdiffを使って差分を見ればいいのではないでしょうか？
バイナリ形式で保存されていて将来データが取り出せなるので困ります。 >>565
知らんがな。
Git採用を決定したヤツに言えよ。 決定してませんよ
うちの学生にはシェルスクリプトで全部やらしています
流行り物のバージョン管理ツールなんて使わせません >>565
お前はいつ、誰が、何のために変更したか全部覚えておけるの？
どの変更とどの変更が一緒の組でどれが独立した修正か、差分見ただけですぐに区別できる？
多数の変更案の中から必要なものだけをすぐに組み合わせられる？
開発人数が多くなっても同じことができる？
1万回修正したとして、その差分を全部コピーで持っておくの？
その無数のコピーの中から必要なコピーを見つけるのはどうやってやるの？ >>567
この「うちの学生」とは、あなたの想像上の存在に過ぎないのではないでしょうか。 >>569
実際に教えていますが何か？
https://richlab.org/coterie/lpf.html
そんな中，まさにその疑問や悩みに応えるような内容の講義
「シェルスクリプト言語論」を金沢地区の大学向けに、2016年から
開講してきました．ここまで4回（4年）開講し，内容が洗練されてきたところでついに書籍化しました． バイナリでも別に過去の履歴は取って来れるような
ただリポジトリは肥大化するしバイナリの管理の為に作られたものでは無いから
相性が良い訳では無いのは分かるのだが
プログラム開発の世界でバイナリと言えば大抵はエクセルなどのオフィス系のファイルだが
正直これらをgitでバージョン管理する必要は無い気はしなくもないｗ
（でも大抵の会社はバイナリだろうがgitで管理しているが） >>571
なにか勘違いしているようだな
gitはテキストデータでも保存するときに
バイナリ形式を使っているから将来データが取り出せなくなると言っておるのだ
そのようなものは使わん ん？将来？別に好きな履歴を取り出せるが？
何の話だ？ いつもの粘着荒しじゃないの
途中で句読点のスタイルが変わってるし半分コピペの創作だろ
あの手この手で相手してほしいんじゃね バイナリ形式だから将来取り出せないって、何を心配してるんだろう？ 文明崩壊後でコンピューターが使えなくなった時？ 岩に刻んでおく？ 間抜けなPOSIX原理主義者がまた論破されて敗走したのか >>563
俺もその本読んだけど、何となくGitの存在意義分かったよ
例えば会議の備忘録がこんな感じで複数あるとしたら？
・備忘録_1.txt
・備忘録_2.txt
・備忘録_1改.txt
・備忘録_最新.txt
・備忘録_3.txt
どれが最も新しいかピンとこない、どの順に更新されたのかピンとこない、
誰がどのファイルにどんな更新を加えたの分からない
そんな問題を解決してくれるのがGitのようなバージョン管理ツール(って書いてある) >>563
YouTube で「git 使い方」「git 入門 」などで検索！
山浦清透・せお丸・くろかわこうへい・しまぶーなど、色々ある >>577
UNIX哲学ではバイナリ形式は禁止されている
愚か者め >>583
話のわからんやつだな。この本を買え。全部書いとるわ。
https://techbookfest.org/product/5743917710442496
我らが一番問題だと思っているのは、リポジトリーの中身の多くが訳のわからぬバイナリーデータになって
いることだ。そのバージョン管理ソフトウェアが滅んだら復元は絶望的だ。テキストデータ形式ならば眺めれ
ば方策も見えてくるのでまだ何とかなりそうな気がするというのに。「データはテキスト形式で保存せよ」とは
UNIX 哲学でも言われてきたことだ。一体何を考えているのか。 移り行くトレンド
古参のプログラマーなら、これまでどんなバージョン管理ソフトウェアが台頭してきたか振り返ってみよ。す
ぐ思いつくものだけでも、RCS、CVS、SVN、そしてGit。これらは同時期に存在して覇権を争っていたのでは
ない。それぞれが時代を担ってきたといっても過言ではない。時代によって使うものが替わり、新しいバージョ
ン管理ソフトウェアが流行り出せば、その使い方を覚え直し、時にはリポジトリーの移行を強いられてきたこと
だろう。よくまぁ、懲りもせずにといったところだが、我らはもうたくさんだ。もしかすると、諸君は「Git を
覚えれば安泰だ」などと思っているかも知れんが、あと数年、遅くとも5 年も経てばきっと次のバージョン管理
ソフトウェアが登場し、覚え直しとリポジトリーの移行を余儀なくされることだろう。 目的を見失っったバージョン管理ソフト
バージョン管理ソフトウェアのそもそもの目的は何だったのか。開発を続け、バージョンアップしていくソフ
トウェアの維持管理に要するコストの抑制であったはずだ。これは、POSIX 原理主義を崇拝する我らがソフト
ウェアを5 年、10 年と生き長らえさせようとする、その根底に流れる目的そのものである。
ソフトウェアはバージョンアップする。新しいコードを加え、古いコードは切り捨て、時には依存するライブ
ラリーを付け替えもする。その変わる様をすべて見届けることがバージョン管理ソフトウェアの役割であり、そ
れができて初めてまともに維持管理コストの抑制が実現する。ゆえに、
バージョン管理ソフトウェアは、ライブラリーの類よりも遥かに長く生き長らえなければ意味がない。
ところが実際はそうなっていない。「バージョン管理ソフトウェアの維持管理」を強いられる。本末転倒もい
いところ。お前は何を言っているんだ。 覚え直しと移行すりゃいいじゃん
その時期がくれば便利な移行ツール（git svnコマンドのような）が出回るし、簡単なことだよ
そんなちっぽけなことを恐れて、完全無欠の理想通りじゃないからと今のベターな現実解を忌避するのはあれだ
こだわりが強すぎて社会生活に支障が出るタイプの典型的症例 >>587
何度も何度も覚え直しでお前は成長してると言えるのか
シェルスクリプトだけでなんでもできる >>587
中身がわけのわからんバイナリデータなのだから壊滅的だ
データは取り出せなくなり移行なんかできん
バージョン管理ソフトウェアが滅んだら復元は絶望的だ 中身がわからんのはお前が無能だからだろ。ソースも公開されてるし、中身の形式も公開されてるので読んどけ。プロプラな機密ソフトの基準で語ってんじゃねーよ。
中身が完全にわかっているという意味ではテキストと同等かフォーマットが決まってる分それ以上に効率が良い。 >>582
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている テキストで保存した結果
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
↓
繝励Ο繧ｰ繝ｳ繝溘Φ繧ｰ縺｣縺ｦ菴包ｼ >>588
成長？
最適なツールを選ぶときに成長とか関係ある？
淡々と使うだけだろ
何度も何度もっていったい何百年生きるつもりなんだ 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指定したほうがいい？ >>612set-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 ■ このスレッドは過去ログ倉庫に格納されています
