22/07/25 23:39:16.54 ahGXQIib0.net
>>382
fetch origin devは、fetch origin refs/heads/dev:refs/remotes/origin/devの省略形で、後者で書いてもfetchできる。
これは、originにある.git/refs/heads/devを、ローカルレポジトリの.git/refs/remotes/origin/devにコピーするということ。
だから、fetch origin develop:devと書けば、originのdevelopを、ローカルにdevという名前で保存することも可能。
ただしトラッキングブランチの設定がある場合は、もう少し前処理が入る。(説明が冗長になるので省略。ただし、ほとんどの場合はリモートトラッキングの設定しているはず。)
ここで、fetch origin/devと書くことが何をしているかは分かりますか？
何を省略しているかを考えれば想像できると思います。
答えは書きませんので、自分で実験するなり考えてみてください。
(普通このコマンドは失敗します。そのようなrefを普通は作らないからです。)
ちゃんと知りたければ、自分でヘルプ読んだほうがいいよ。
push, fetch, pull, refspecなどを読んでみて。
392:デフォルトの名無しさん
22/07/25 23:48:16.63 ahGXQIib0.net
>>383
誤記あったので訂正。
> fetch origin/devと書くことが
→ fetch origin origin/devと書くことが
以上。
ちなみにfetch origin/devは必ず失敗すると思います。
その位置にはrefではなくてリモートレポジトリ名を書くわけだが、origin/devってい名前は作らないと(多分作れない)思うので。試したことないけど。
393:デフォルトの名無しさん
22/07/25 23:59:56.84 ahGXQIib0.net
refspec使った例で、自分がたまにやるやつを紹介して補足すると、
pushの例になるけど、
git push origin @~2:developとかは使うかな。
update update ...っていくつかコミットしたあとに、2つ前までのやつならちゃんと作れてるから、それをpushしておこうなんてときに。
fetch方向だとそういう工夫は必要ないと思うから、追跡してるとおりに取ってきちゃうけど。
394:デフォルトの名無しさん (ﾜｯﾁｮｲ 13f2-geFY)
22/07/26 00:11:33 BPsr0FTg0.net
あと、上にorigin以外を...って話があるから、自分のユースケース紹介しておくと、
自分だけが使うようなコンフィグファイルの設定とかを、backupっていうリモートレポジトリの名前で、別のフォルダに向けておいて、
git push backup myconfig1とかやることあるかな。
この場合は、リモートブランチとしてbackup/myconfig1っていうのが作られるよ。
リモートレポジトリはoriginだけじゃなくてもよくて、
ローカルレポジトリに、backup/myconfig1はorigin/developと共存してる状態だよ。
ごめんね、自分語りが長くて。
395:デフォルトの名無しさん (ﾃﾃﾝﾃﾝﾃﾝ MMeb-HyOX)
22/07/26 12:40:11 iEhVjhlSM.net
gitクライアントからボタン一つクリックするだけで完了するような操作を、いちいちターミナル立ち上げてタイプしてる人は何？
しかもタイピングが遅いからまどろっこしくて仕方ないw
396:デフォルトの名無しさん
22/07/26 15:46:31.59 LlJvHA5t0.net
>>387
コマンドでgitを使う=タイピングが遅い
決め付けの激しい人だな
397:デフォルトの名無しさん (ﾌﾞｰｲﾓ MM4d-W0Yq)
22/07/26 16:14:03 FjX46+h7M.net
そもそも普段からキーボード打つ方が、何十倍も早いだろ。煽るにしてもレベル低すぎ。
それともマウスでプログラム組んでるとか主張するんだろうか？
398:デフォルトの名無しさん
22/07/26 17:29:56.27 AlqtQl//0.net
>>377
origin/devはgit logで表示されるorigin/devと同一という理解であっていますか？
であれば、git logをした際にdevブランチの方がorigin/devよりも上（新しい）に表示されることがあるので
必ずしもorigin devのローカルコピー版であるorigin/devは最新ではない という説明には納得がいきます。
>>381
冒頭に書いてあることは、リモートブランチもリモート追跡ブランチと同様に、ローカルリポジトリ上に存在する という理解でよいですか？
399:デフォルトの名無しさん
22/07/26 17:53:40.65 aK/PU7Z0M.net
>>388
そうとは言ってないだろ
文書が読めるようになってからレスしろよ
400:デフォルトの名無しさん
22/07/26 19:18:08.90 cKNkMgD2r.net
「タイピングが遅い」っていうのは自分のことを指していってるんじゃないかなぁ
たぶんある種の自虐かと
401:デフォルトの名無しさん
22/07/26 19:34:51.51 wvY0b08ra.net
いやよく読もう
> いちいちターミナル立ち上げてタイプしてる人は何？
> しかもタイピングが遅いからまどろっこしくて仕方ないw
タイピングが遅いはどう考えても一般論じゃないんだから、身近にそういう変わった人がいるという質問風の愚痴だろ
「ほーん、で？」「それは大変だったね」「しらんがな」とか答えてあげるかスルーすればいい案件
402:デフォルトの名無しさん
22/07/26 19:38:48.45 LlJvHA5t0.net
特定の誰かがタイピング遅いから全員gitコマンド使うなという主張だよ
403:デフォルトの名無しさん
22/07/26 19:42:06.64 wvY0b08ra.net
被害妄想じゃね
404:デフォルトの名無しさん
22/07/26 19:43:23.18 ZFH6mJGl0.net
いちいちターミナルを立ち上げって書いてあるけど、普通ターミナルなんて立ち上げっぱなしだよなあ
405:デフォルトの名無しさん
22/07/26 19:49:04.16 wvY0b08ra.net
開いてあるターミナルでコマンド履歴を呼び出したり git switch - 打ったりはコマンドが早いな
エイリアスがあればさらに早い
そのタイピングが遅い人はgitの練習かタイピングの練習がしたいんじゃね
406:デフォルトの名無しさん
22/07/26 19:56:26.38 StEemcQzM.net
>>390
はい。わたしは>>381には、リモートブランチとリモート追跡ブランチが同じ意味で書いてます。
前半は自分にはわからなかったです。
どのorigin/devが、logのorigin/devと同じと言っているんだろう。
origin/devは普通.git/refs/remotes/origin/devの省略形として使われるのであって、
git logの引数の説明に、refspecとかrevisionとか書いてあったらそうだろうと思います。
自分はそういうつもりで使ってますが、ちゃんと知りたいなら調べてみたらどうでしょう？
文脈によっては.git/refs/heads/origin/devかもしれないですね。これは難癖ですが。（つまりorigin/devっていう名前のローカルブランチ。でもコマンドミスで、たまに作ってしまう…）
407:デフォルトの名無しさん
22/07/26 19:59:34.56 StEemcQzM.net
>>398
話が長くてすまんが、要はorigin/devはなにかの省略形で、それは文脈によって決まるということです。
origin/devっていったら、普通はアレのこと、というのはありますが、一つの言葉に固執している様子を感じたので、原著に当たったほうがいいよというアドバイスになります。
408:デフォルトの名無しさん
22/07/26 20:52:33.24 AlqtQl//0.net
>>399
ああ、そういうことですか。腑に落ちました。
仰るとおり、一つの言葉の意味を一つに定めようとしていました。
origin/devといっても脈絡次第でそれが何の略であるか、いくつか解釈パターンがあるんですね。
原著はgit-scm.com/docｓ/であってますか？
tagやcommit等を調べるときはこのページを利用しました。
このスレの皆さん、リモート追跡ブランチが何であるかを理解した時も原著を参照されたのですか？
書籍等でわかりやすく日本語でまとめられた情報等は購入されていないのでしょうか？
参考までに教えて頂けると助かります。本当は自分でわからないことをすべて調べられるのなら理想なのですが
まだその段階には至っていないようです。
409:デフォルトの名無しさん
22/07/26 21:27:22.81 BPsr0FTg0.net
>>400
用語はそのurlからgitglossaryで検索すると見れます。
というか、コマンドラインからgit help gitglossaryで、使ってるバージョンのヘルプページが開きます。
この中を、remote-tracking branchをページ内検索す�
410:黷ﾎリモート追跡ブランチの説明があります。 あと、git help gitで、使えるコマンドの大枠が見れます。 本については、10年以上前ですが自分はjunio c hamanoが書いた本で学びました。日本語です。その後3冊買いましたが、最初ので十分でした。 オンラインで無料で読めるやつならpro gitが一番読みやすいと思います。日本語訳があります。 ただしこれはツールとしての使い方が主です。
411:デフォルトの名無しさん
22/07/26 21:35:13.51 BPsr0FTg0.net
>>401
ProGit後半の方には内部実装に踏み込んだ説明もあるので、あなたの知りたいことは、こちら寄りかもしれません。
多くの人は、ツールを一般的なユースケースで使えればいいのであって、origin/devとorigin devはどう違うのか、といった疑問は感じないか、もしあってもすぐに忘れます。
origin/devとorigin devの違いだけを知りたい場合はすでに説明したとおりです。
でも更に疑問が出てくると思います。
あなたの疑問は、定義をしっかり知ったほうが理解につながるものだと思うので、地道にヘルプなどのドキュメントをたくさん読んで、自分の頭で探し方を学んだほうがいいものだと思います。
412:デフォルトの名無しさん
22/07/26 23:28:02.96 khPn0eWd0.net
commitはメッセージが改行付きで長めになるのでGUIでやってるｗ
status,checkout,push,pull,mergeみたいなのはコマンドラインでやってるなぁ
413:デフォルトの名無しさん
22/07/27 00:32:02.65 t+HDDZmX0.net
commitコマンド実行したときにエディタ立ち上がるようにしてないの？
414:デフォルトの名無しさん
22/07/27 02:00:04.13 CxAuph4lH.net
環境依存な話ですが、Macでターミナルからgit difftoolした時に外部diffビューアを立ち上げ
たいのですが、皆さんどうしてますか?
ググってopendiff (-> FileMerge)を呼ぶ設定にしてみたのですが、複数の変更ファイルが
あるとき、FileMergeが2番目以降のファイルを開いてくれません
415:デフォルトの名無しさん
22/07/28 16:17:00.66 Lt0nllDPM.net
呼び方が混乱してるのかも。通常の使い方だと、以下の通り。
origin dev 「リモートブランチ」、 origin という名前のリポジトリ上にある dev という名前のブランチ。
origin/dev 「リモート追跡ブランチ」、origin/dev という名前のローカルブランチ、上記のリモートブランチを追跡するように設定されている。
dev 「追跡ブランチ」、dev という名前のローカルブランチ、上記のリモート追跡ブランチ(origin/dev)が上流に設定されている。
（注:あくまでデフォルトなので変えることはできる…）
416:デフォルトの名無しさん
22/07/28 16:29:18.98 11jlioVlM.net
ターミナルにコマンド入力してのがかっこいいと思ってる人いる？
417:デフォルトの名無しさん
22/07/28 17:09:52.93 9SWmz8k0d.net
>>407==>>387
どんだけコマンド敵視してんだよ
418:デフォルトの名無しさん
22/07/28 17:16:34.57 DCbd1n5j0.net
>>407は凄くかっこ悪い
419:デフォルトの名無しさん
22/07/28 18:31:06.84 kDNwoqB9a.net
煽り耐性なさすぎだろ…
ところで origin dev というフレーズに意味があると捉えてるのいいのかな
単に<repository>と<refspec>を順に受け取るコマンドが多いだけで、origin dev と oringin/dev を同格の概念だと捉えるのは理解を妨げると思うんだが
420:デフォルトの名無しさん
22/07/28 19:32:20.12 Lt0nllDPM.net
>>410
厳密に言えば違うけど、どっちもブランチを指定しているという意味では同格だろ。
ローカルブランチと、リモートブランチを取るコマンドで引数の指定方法が異なると理解しとけば良い。
421:デフォルトの名無しさん
22/07/28 20:04:25.84 onozgSw3a.net
我流で変な理解をするよりも、上で丁寧にわかりやすく説明してくれてくれてる人が言うようにちゃんとヘルプ見たほうがいいと思うけどね
中級者と本当に詳しい人の差はそこで出ると思う
refspecとは何か、tree-ishとは何かを説明できるかどうかはポイントの一つだと思う
422:デフォルトの名無しさん
22/07/28 21:31:34.95 cm
423:Nt05vA0.net
424:デフォルトの名無しさん
22/07/28 22:20:18.72 +DkG6hq80.net
gitのことを知らないんだからsvnのデメリットにも気付かないよ
425:デフォルトの名無しさん
22/07/28 22:40:17.73 pS32MLV5d.net
ドカタ開発はもっと理不尽なことがいくらでもあるからその程度は大した問題じゃないんだよ
VCS使ってるだけマシ
426:デフォルトの名無しさん
22/07/29 01:55:35.40 eL4dVDXxM.net
>>408
なんで敵視？
427:デフォルトの名無しさん
22/07/29 02:26:57.20 g45EDnWs0.net
デメリットなんて気付くわけないさね
スマホを使ったことがない人はガラケーの劣る点に悩まないし、自動車がなかった時代に初の自動車を見てもこのヘンテコなカラクリ仕掛けが世界を変えるとは考えられない
保守的な人やいつも忙殺されて余裕のない人は損失回避バイアスによって変化のリスクを過大に見積もり現状維持を選ぶし
いよいよ心が老人になると自分の慣習や価値観を否定されたと感じて怒り出す始末
428:デフォルトの名無しさん
22/07/29 06:43:18.42 KqiKNtRU0.net
>>413
その2点に慣れてしまうともう戻れないよな
コーディング方法さえ変えてしまうほど便利
429:デフォルトの名無しさん
22/07/29 10:26:37.17 nIcw6oQba.net
>>396
++
tmux最強
430:デフォルトの名無しさん
22/07/29 10:28:01.90 nIcw6oQba.net
>>393-394
判りやすい
431:デフォルトの名無しさん
22/07/29 11:55:40.15 UFMUx9C4M.net
CVS使ってた現場で、コミット漏れによる先祖返りで障害が起きた対策として、下記の作業手順が定められた
1. 一切コミットすることなくソースの変更とテストとレビューを済ませる
2. 本番からソースをダウンロードし、ワーキングセットとの差分を取る
3. ワーキングセットを本番にデプロイする
4. CVSにコミットする
もはやバージョン管理とは何なのかと思ったね
432:デフォルトの名無しさん
22/07/29 12:45:43.04 kJOM8zsPM.net
>>421
ローカルとかチームではgit使って、サーバーだけcvsにした方が良さそうだな。
433:421 (ﾌﾞｰｲﾓ MM9d-vZl0)
22/07/29 13:13:28 UFMUx9C4M.net
あーちょっと不正確だった。正しくは、1の前に
0. 本番からソースをダウンロードし、CVSとの差分がないことを確認する
が入る。簡単に言えばVCSを一切当てにしないで本番環境にあるソースをマスターにしましょうってことだ。
こんなのCVSかGitかとかいう以前の問題で、ルール決める人間がVCSを理解してないんだからツールを何使おうが絶対に間違えるんだよ。
仮にGit使ってたとしても同じことになってるだろうね。
434:デフォルトの名無しさん
22/07/30 04:13:51.24 5b4tKXes0.net
>>421
cvsがただのソース置き場になってるな
zip管理してるのと変わらん
それで回るのなら、cvsやめてzip管理でええやん
435:デフォルトの名無しさん
22/07/31 02:06:31.57 usagdBtl0.net
例えばgoogle trendで検索すると日本はgitに対するsvnの比率が世界最上位クラスに高いのが分かる
より良い技術を取り入れていこう勉強していこうってタイプの人が全然いないのかな
そんなものより動く製品作るのが大事だろ、知ってる技術使えばいい�
436:ｾろ、勉強する時間が無駄みたいな
437:デフォルトの名無しさん
22/07/31 02:15:39.82 umZ4cEVU0.net
>>425
すまん俺が svn 糞 とかでググってるせいだわ
438:デフォルトの名無しさん
22/07/31 02:22:27.63 usagdBtl0.net
>>421
cvsじゃなくてtfvcだけどまさにそんな感じ
ブランチが開発差分じゃなくて、各モジュールを表すものになってるんだよねうち。メインに共通部品が置いてあるのよ
じゃぁこのブランチで開発してね他の人はいじらないから、みたいなこと最初に言われたとき、お前バージョン管理をなんだと思ってるんだってなったわ
>>424の言う通りだし、そもそも「バージョン管理」って概念自体がよく分かってない人結構いるのかもしれない
439:デフォルトの名無しさん (ﾜｯﾁｮｲ d68f-mUOZ)
22/07/31 05:29:08 Q1ZzrLT30.net
>>425
svnを敵視する人はこれだから困る
440:デフォルトの名無しさん
22/07/31 15:16:33.83 5HP0foYyM.net
>>427
テンプレートからフォークしていく運用自体はそんなに珍奇ではないと思うよ
TFVCはよく知らないけどGitほど複数リポジトリに跨った管理が得意とは思えないから、
フォークの際にGitでクローンする代わりにブランチを使うのはまあアリなんじゃないか
441:デフォルトの名無しさん (ﾜｯﾁｮｲ 4110-YjMm)
22/08/01 09:23:36 x4rTNfSD0.net
Hamano氏のインタビューが載ってる URLﾘﾝｸ(git.github.io)
442:デフォルトの名無しさん
22/08/06 16:17:32.37 PoK0MHTD0.net
おまえらってgitを使ってなにを管理してんの？
どうせ人には見せれない、クソコードをprivateにして遊んでるだけだよなｗ
443:デフォルトの名無しさん
22/08/06 16:19:29.02 PxmA7nyT0.net
確かに見せられないな、機密情報だから
ごめんねー
444:デフォルトの名無しさん
22/08/06 22:54:01.88 PoK0MHTD0.net
恥ずかしくてみせないよな
ｗｗｗｗｗ
445:デフォルトの名無しさん
22/08/06 22:55:49.69 Kw1pprEh0.net
そんなにみたいなら見せてやるよ
最新作だ
URLﾘﾝｸ(github.com)
446:デフォルトの名無しさん
22/08/07 06:13:33.06 xRSduvLwr.net
相変わらずのダサいコードで笑う
447:デフォルトの名無しさん
22/08/07 10:36:56.12 JIUI9FIi0.net
>>434
なにこれ？
この程度ものを管理する必要があるのか？
しかも公開してｗｗｗｗ
やっぱり、偉そうにいうわりにはクソみたいなソフトしか作れないんんだろ
448:デフォルトの名無しさん
22/08/07 13:36:16.69 Rb+FepPS0.net
>>436
コミケで販売するから文句はそれ買ってから言え。通販もしてるぞ。
あなたのシェルスクリプトに正確な「時」をデリバリー
トキデリ Rich Mikan 著
URLﾘﾝｸ(richlab.org)
449:デフォルトの名無しさん
22/08/08 13:17:15.57 AVRRjrX2r.net
資源の無駄
450:デフォルトの名無しさん
22/08/08 13:28:32.63 CyzYFgqfa.net
githubの話はgitスレでしないでくたさーい
451:デフォルトの名無しさん
22/08/09 23:25:41.25 3+5sY31X0.net
githubとgitは別物だぞ
452:デフォルトの名無しさん
22/08/10 01:11:45.77 81VFPbKx0.net
>>440
gitを使ったシステムなんだから別物ではない
453:デフォルトの名無しさん
22/08/10 01:28:37.91 S6X0Gjf0a.net
え？
454:デフォルトの名無しさん
22/08/10 02:07:21.61 ek7aVcHb0.net
DNAと人間は同じだから
455:デフォルトの名無しさん
22/08/10 02:47:33.52 RODVWlnt0.net
repoってgithubとかgitlabみたいなもん？
456:デフォルトの名無しさん
22/08/10 07:15:46.58 g2r8Vobb0.net
>>444
ホスティングサービスではなくて、gitを補佐するクライアントソフトらしい
457: 複数のリポジトリを一括で操作できるのが特徴とか ライブラリが多いとか、扱うリポジトリが多いプロジェクトなんかだと重宝するかも 個人的にはいらんなぁ
458:デフォルトの名無しさん (ｱｳｱｳｳｰ Sa55-2+m5)
[ここ壊れてます] .net
自分も会社の業務以外でほとんど使用したことはないな
そもそも個人レベルのプロジェクトで複数のリポジトリ扱うことないし
Android SDKのソース落としてくる時に使ったぐらい
459:デフォルトの名無しさん
22/08/13 07:41:00.55 TsW0bL7n0.net
Git v2.37.2
460:デフォルトの名無しさん
22/08/13 19:37:20.99 HRISK7Hh0.net
個人レベルでgitを使う必要ある？
そもそも自分ひとりで書いてるなら大抵は覚えてるだろｗ
461:デフォルトの名無しさん
22/08/13 20:04:36.06 WN46//k40.net
個人レベルだからこそ簡単に導入出来るgitを使う
別にリモートにpushやらしなくても所々コミットしておけば戻るのも簡単だし
便利だと思うのだけどね
ただバイナリ（excelのファイル)みたいなのには使わないが
462:デフォルトの名無しさん
22/08/14 02:14:02.08 XCwSZ99k0.net
新機能を実装する時は、変更前のソースを参照できるようにしておかないと面倒。
バグが発生したときは差分をすぐに参照できるようにしたいしな。
463:デフォルトの名無しさん
22/08/14 02:16:52.49 TBJygn0f0.net
>>448
ローカルリポジトリだけでも完結できるのにgitをわざわざ忌避する理由がない
464:デフォルトの名無しさん
22/08/14 13:58:00.56 eEFpmmgP0.net
>>448
数万行のコードなんて覚えてられない
どうせおまえがやってるのは100行以下のサンプルコードだけだろｗ
465:デフォルトの名無しさん
22/08/14 15:10:31.19 hteYaGpv0.net
>>452
どうせ公開できないんだろｗ
何とでもいえるわなｗｗｗ
俺なんてカーネル開発してるよ
466:デフォルトの名無しさん
22/08/14 15:48:56.36 eEFpmmgP0.net
>>453
たった数万行に驚いてるのか？
467:デフォルトの名無しさん
22/08/14 16:47:19.54 psUND9lqa.net
そもそも描いたこと無いからイキれるんだな
468:デフォルトの名無しさん (ﾜｯﾁｮｲ 31ab-5Ix7)
[ここ壊れてます] .net
一日100行でも一年経てば20000行
469:デフォルトの名無しさん
22/08/15 20:10:11.85 KNym4Y6d0.net
svn脳の人はローカルリポジトリの概念がないからvcs使うことを大層に考えてしまうんだよな
470:デフォルトの名無しさん
22/08/15 20:22:20.12 1icmhpVn0.net
リモートリポジトリが要らないというのは革命的だと個人的には思うけど、あんまりそういう話は出てこないよね。
リモートリポジトリ無しってgit登場時点で普通の話だったっけ？
471:デフォルトの名無しさん
22/08/15 21:27:50.09 dRxXQoxWM.net
リポジトリーのローカルコピーも含めてGitの機能的な部分はBitKeeperから持ち込まれたものだろ
472:デフォルトの名無しさん
22/08/15 22:34:37.88 vxI8O7UY0.net
>>458
SCCSとかRCSとか。
473:デフォルトの名無しさん
22/08/15 23:18:53.39 f21eh4iaM.net
Gitの開発経緯を考えるとリモートリポジトリの存在はむしろ超大前提で、ローカルだけで使えるのは副産物みたいなもんでしょ
まあリモートと言ってもGithubみたいな中央集権型ではなくて、無数のリモートリポジトリがあってパッチを送り合うような開発スタイルが本来のGitの姿
474:デフォルトの名無しさん
22/08/16 01:17:15.07 yNxxslbt0.net
URLﾘﾝｸ(ezoeryou.github.io)
gitの10周年を記念したLinus Torvalsへのインタビューの翻訳
＞ しかし、BitKeeperがやってきてからというもの、ソース管理に対する見方が変わったね。
＞ BitKeeperは大抵のことを正しく行っていた。
＞ レポジトリのローカルコピーがあることと、分散マージはでかかった。
475:デフォルトの名無しさん
22/08/16 23:52:04.96 zXGOFEoi0.net
>>448
gitに�
476:ﾀらんけど、VCSって個人レベルでも機能追加とバグ修正並行して進める時は楽だ
477:デフォルトの名無しさん
22/08/18 11:54:41.84 p/limWqpa.net
gitとgithubの区別がついてないんだろ
478:デフォルトの名無しさん
22/08/25 00:47:44.66 x22ro4Sl0.net
初歩的な質問になるけれど…
異なるローカルブランチ「debug」と「genbug」が存在する。
両方のブランチに全く等しい「iam.txt」と「whoyou.txt」いうテキストファイルがあって、
どちらのテキストファイルも両ブランチの最新コミット内に存在するものとする。
「Iam.txt]の中身は"I am a dog."
「debug」ブランチで【rm whoyou.txt】と打って「whoyou.txt」を削除し、「Iam.txt」の中身を"I am a cat."に変更してステージングをしないまま、
【git checkout genbug】 と打って「genbug」ブランチに切り替え、ワークツリーを確認してみると、「Iam.txt」の中身は"I am a cat."に変更されているのに、
「whoyou.txt」は削除されていない（というより復活している）。
これはなぜなのだろうか？（whoyou.txtをgitリポジトリから消したいならrmコマンドではなくgit rm --cachedを使うべきなのはわかる）
いまいち、git checkoutをしたときのワークツリーの挙動が掴めない
479:デフォルトの名無しさん
22/08/25 02:38:58.44 W0zamWK80.net
「git checkout ブランチ」するとき、
checkout前のブランチにおけるワークツリー上でのファイルの編集や削除は、
checkout前のブランチにコミットされているそのファイルとcheckout後のブランチにコミットされているそのファイルが等しい場合、
checkout後のブランチにそのまま引き継がれる
つまりIam.txtが変更されているのは正しいが、whoyou.txtが復活するのは何か操作を勘違いしていると思う
ちなみに、
checkout前のブランチとcheckout後のブランチにコミットされているファイルが等しく無い場合、
checkoutすることでcheckout後のブランチにコミットされているファイルへ置き換わるが、
checkout前のブランチにおいてワークツリー上でそのファイルを編集や削除していると、
checkoutが失敗する
480:デフォルトの名無しさん
22/08/25 02:40:02.58 W0zamWK80.net
$ git status -sb
## debug
$ ls
iam.txt whoyou.txt
$ cat iam.txt
I am a dog.
$ echo "I am a cat." > iam.txt
$ rm whoyou.txt
$ git status -sb
## debug
M iam.txt
D whoyou.txt
$ ls
iam.txt
$ cat iam.txt
I am a cat.
$ git checkout genbug
M iam.txt
D whoyou.txt
Switched to branch 'genbug'
$ git status -sb
## genbug
M iam.txt
D whoyou.txt
$ ls
iam.txt
$ cat iam.txt
I am a cat.
481:デフォルトの名無しさん (ﾜｯﾁｮｲ 1f5f-SiT/)
[ここ壊れてます] .net
>>466-467
whoyou.txtが復活するのは勘違いしていたみたい すまん
「checkout前のブランチにおけるワークツリー上でのファイルの編集や削除は、
checkout前のブランチにコミットされているそのファイルとcheckout後のブランチにコミットされているそのファイルが等しい場合、
checkout後のブランチにそのまま引き継がれる」
こんな仕様があったのか。知らなかった。ありがとう。
ワークツリー上で行った操作をなかったことにしたい場合「git checkout .」で良いと思うんだけど
ワークツリー上で行ったgit操作履歴（というかローカルリポジトリへのコミット内容との差分）を確認する方法ってないのかな
482:デフォルトの名無しさん (ﾜｯﾁｮｲ 9fe4-hHkJ)
[ここ壊れてます] .net
>>468
ワークツリーでの操作に関しては履歴は残らない
カレントブランチにコミット済みとワークツリーとの差分については、上でもやってるけどgit statusや、git diffでもできる
git diff # 差分の内容を表示
git diff --name-status # 差分があるファイル名とそのステータスを各1行で表示
git status # 差分があるファイル名を含めたワークツリーの状況を詳しめに表示
git status -s # 差分があるファイル名とそのステータスを各1行で表示
git status -sb # ブランチ名を表示した下にgit status -sと同じものを表示
483:デフォルトの名無しさん (ﾜｯﾁｮｲ 7f7c-tEjH)
[ここ壊れてます] .net
git status -v
とかじゃダメなのか？
484:デフォルトの名無しさん (ﾜｯﾁｮｲ 9fe4-hHkJ)
[ここ壊れてます] .net
git status -vは-v無しと同じかな？
毎回git statusやると表示がうっとおしいので、git status -sbの方をシェル関数でgstに定義して良く使ってる
git status -vはmergeやrebaseが失敗したときに見る
485:デフォルトの名無しさん
22/08/26 18:45:49.38 8mS1vdmvM.net
たかだかpushするだけなのに、ターミナルからやった方がエモいですか？
486:デフォルトの名無しさん
22/08/26 19:07:22.83 m09WXDX9a.net
エモいと言う言葉の意味がわからない
487:デフォルトの名無しさん
22/08/26 19:30:50.57 WwYTVpIB0.net
>>472=>>407
488:デフォルトの名無しさん
22/08/27 07:34:04.59 cMY+Cqk70.net
エモいかどうかは知らんけど、
489:ターミナルの方が便利
490:デフォルトの名無しさん
22/08/30 12:28:50.29 CdxrcFTpM.net
興味本位でインストールしたけど、そもそも履歴を管理しなきゃいけないようなものが、個人にはないこと気づいてほったらかしwww
491:デフォルトの名無しさん
22/08/30 23:04:23.35 F66FctjD0.net
まあ、プログラマーくらいしか使わんかも
事務の人とか使ってるんかな？
492:デフォルトの名無しさん
22/08/31 08:44:21.38 hYROypry0.net
ファイル名で管理していて最新版がどれかわからんっていうネタはよく見るけど、最新版を追うためだけにVCSを導入するところは少ないでしょ
493:デフォルトの名無しさん
22/08/31 08:46:09.80 kba1lHfP0.net
Git v2.37.3
494:デフォルトの名無しさん
22/08/31 12:34:16.47 nUvaW37BM.net
>>478
最新はタイムスタンプ見れば一目瞭然だろ
パソコン初心者かよw
495:デフォルトの名無しさん
22/08/31 15:08:11.70 83s/Qhp/a.net
タイムスタンプω
パソコン初心者かよωωω=2πf
496:デフォルトの名無しさん
22/08/31 15:34:18.76 t/W0dlco0.net
gitがメジャーになったおかげで、ソースコードのタイムスタンプにゴチャゴチャ文句付けるオジサンを駆逐できて良かった
497:デフォルトの名無しさん
22/08/31 16:40:45.15 hYROypry0.net
あと、扱うファイル形式的にも難しそう
>>482
どういうこと？昔はタイムスタンプで何か言ってくる人がいたの？
498:デフォルトの名無しさん
22/09/01 01:20:40.38 v92yFclD0.net
>>481
涙拭けよ
499:デフォルトの名無しさん (ﾜｯﾁｮｲ 5dc2-nKCz)
[ここ壊れてます] .net
タイムスタンプみたいな信用できないものに依存するなよ
500:デフォルトの名無しさん
22/09/03 12:08:05.86 gEPymsC80.net
URLﾘﾝｸ(github.com)
これをビルドするのにMSYS2を入れて、git clone git@github.com:witwall/mman-win32とやったら、git@github.com: Permission denied (publickey).になっちゃったんですけど、githubのアカウントがないとダメなんでしょうか？
501:デフォルトの名無しさん
22/09/03 12:50:36.25 91ZlUxrsa.net
git clone github.com:witwall/mman-win32
502:デフォルトの名無しさん
22/09/03 12:56:48.05 ZbfA6K7G0.net
>>486
SSH接続はアカウント作って鍵を登録する必要がある
git@github.com: → URLﾘﾝｸ(github.com)
に読み替えてhttpsでやればいい
503:デフォルトの名無しさん
22/09/03 15:32:09.11 gEPymsC80.net
>>488
ありがとう
504:デフォルトの名無しさん
22/09/04 18:01:40.46 F3wqdiHv0.net
情報系卒ではじめて業務でgit触ったんだけど、これbranch newFunc -u みたいな感じで
origin/newFuncみたいなの脳死で追跡するように設定しちゃってもいい？
このコマンド一度打っておけば。そのブランチにpushするときいちいちoriginって入れなくてもよくなる
くらいの認識でしかないんだけども
505:デフォルトの名無しさん
22/09/04 18:03:08.45 F3wqdiHv0.net
日本語下手すぎたから書き直します
情報系卒の1年目で、最近はじめて業務でgit触ったんだけど、これ「git branch newFunc -u」で
origin/newFuncをup-streamに設定しちゃってもいい？
このコマンド一度打っておけば、そのブランチにpushするときいちいちoriginって入れなくてもよくなる（originが省略できる）
くらいの認識でしかないんだけども
506:デフォルトの名無しさん
22/09/04 18:09:17.04 ZgLwpFsc0.net
いいよ
間違ったとこにpushすることを防げる
507:デフォルトの名無しさん (ﾜｯﾁｮｲ 7fdb-Cgcv)
[ここ壊れてます] .net
おとなしくGUI使えよ
タイプするのが面倒で、間違ってpushなんてしてるようならｗｗｗ
508:デフォルトの名無しさん
22/09/05 01:29:30.11 +fm9JKxR0.net
>>493
push先を間違うのは頭の中の段階なので何UIでも関係ないです
509:デフォルトの名無しさん
22/09/05 01:33:50.45 CQl5AJDr0.net
>>494
論破しましたね
510:デフォルトの名無しさん
22/09/05 12:14:03.67 s3GaDdDqM.net
論破ww
久々に聞いた、平成かよw
511:デフォルトの名無しさん
22/09/05 14:19:44.96 vU9z3P6x0.net
ﾃﾃﾝﾃﾝﾃﾝがこうも粘着してgitのコマンド入力に憎しみを向けるの�
512:煢ﾟ去に完全論破されたのがよっぽど悔しかったんだろうな
513:デフォルトの名無しさん
22/09/05 16:50:12.49 dKgf+YLO0.net
ローカルブランチのソースコード中の
コメントアウトしてある説明とかの修整って
気付いたときに、いちいちコミットしてる？
それともstashとかにまとめといて後で一気にやる？
514:デフォルトの名無しさん
22/09/05 18:08:18.48 pTpxX+Uo0.net
別にこまめに修正してコミットしても良いのでは？
何かルールでもあるの？
515:デフォルトの名無しさん
22/09/05 19:17:05.40 dKgf+YLO0.net
>>499
ルールは無いよ
ただどうでもいいとこで無用にログが膨らむけど
皆は普段どうしてんだろ？って思って書いてみた
516:デフォルトの名無しさん
22/09/05 20:13:32.62 CQl5AJDr0.net
気が向いたらコミットしといてpushする前にsquashで複数コミットを1個にまとめる
517:デフォルトの名無しさん
22/09/05 23:32:13.90 vU9z3P6x0.net
気楽に思いつくままコミットして、ゴチャつきが気になったら後で rebase -i で美化運動する
518:デフォルトの名無しさん
22/09/10 14:36:31.13 4Ftb5IZI0.net
>>491
originしかないような状況ならまず困らないからOK
2つ以上のリモートリポジトリにpush/pullしたくなったら、ユースケースでデフォルトに設定するかその都度考えて打った方がいいか考えればok
519:デフォルトの名無しさん
22/09/10 17:37:58.38 EVlNSVx0M.net
.gitattributesで.rcファイルをUTF-16LE-BOMに指定してから、git cloneした時にエラーが発生するようになりました
書き方が間違ってるのでしょうか？
>error: failed to encode 'resource.rc' from UTF-8 to UTF-16LE-BOM
.editorconfig
------------------
root = true
[*]
end_of_line = crlf
charset = utf-8
indent_style = space
indent_size = 4
trim_trailing_whitespace = true
insert_final_newline = false
[*.rc]
charset = utf-16
------------------
.gitattributes
------------------
*.rc working-tree-encoding=UTF-16LE-BOM eol=CRLF
520:デフォルトの名無しさん
22/09/10 17:55:34.66 2MbFO6mH0.net
>error: failed to encode 'resource.rc' from UTF-8 to UTF-16LE-BOM
これが理由じゃないの？
そもそも、UTF-16LE-BOM を使う事ってある？
普通は、BOM 無しUTF-8 を使う
521:デフォルトの名無しさん
22/09/10 18:08:59.50 EVlNSVx0M.net
>>505
Visual Studioを使ってるのでUTF-16LE-BOMかShiftjisの二択なのです
resource.rcはUTF-16LE-BOMで保存してあります
522:デフォルトの名無しさん
22/09/10 18:17:08.28 kN9l3Zj10.net
>>505
使う理由があって使ってんのに難癖はやめとけ
523:デフォルトの名無しさん (ﾜｯﾁｮｲ a561-Z99o)
[ここ壊れてます] .net
>>504
リモートとのやり取り時に指定文字コードとUTF-8を相互変換するんだから.rcファイルpushし直さないとだめじゃね？
524:デフォルトの名無しさん
22/09/10 20:18:35.22 RL5Ydm0F0.net
素直に文字コード変換ソフト使ってからpushしたほうがイイんじゃね？
文字コードの問題は結構根深いとこあるし
525:デフォルトの名無しさん
22/09/10 20:23:42.76 1BX46xrY0.net
情報学部卒IT企業勤務1年目だけどGit難しいよ
よくみんな使いこなせるな
ブランチ切り替えとか発生した瞬間に混乱するわ
526:デフォルトの名無しさん
22/09/10 20:25:06.14 1BX46xrY0.net
とあるブランチで開発を進めていて、pushまで完了していつでもブランチ切り替えできる状態ではあるけど
新しくブランチ切ったからそこで作業してと言われた瞬間パニックになる ブランチ切り替えすると作業フォルダの中身変わるの緊張するわ
527:デフォルトの名無しさん
22/09/10 20:40:06.16 amn8zzJ5M.net
慣れないうちはコミットログやブランチ同士の関係をグラフ表示できるGitクライアントに頼ったほうがいいよ
ミスっても所詮は手元だけだから、適宜リモートにプッシュしてさえいれば操作は大胆にやればいい
ただしプッシュ前のチェックだけは入念に
528:デフォルトの名無しさん
22/09/10 21:23:42.21 EVlNSVx0M.net
>>508
リモートの.editorconfigと.gitattributesでUTF-16LE-BOMを指定してるので
.rcファイルもUTF-16LE-BOMで上がっているんじゃないのかな
cloneした.rcファイルはUTF-16LE-BOMになってます
>>510
よくわからないエラーで悩むよ
529:デフォルトの名無しさん
22/09/11 01:22:10.61 TANQ1xvy0.net
そもそもutf-16 leを推奨しているMicrosoftがおかしいからな(直す気もないらしい)
>>504
多分もう色々調べてると思うけど、もし見てなかったら参考に
URLﾘﾝｸ(developercommunity.visualstudio.com)
URLﾘﾝｸ(qiita.com)
530:デフォルトの名無しさん
22/09/11 06:37:15.30 ViMVDrAnM.net
>>514
ありがとうなんだか設定ミスのようだ
× charset = utf-16
〇 charset = utf-16le
× *.rc working-tree-encoding=UTF-16LE-BOM eol=CRLF
〇 *.rc text working-tree-encoding=UTF-16-LE-BOM eol=CRLF
531:デフォルトの名無しさん
22/09/11 08:17:11.62 p8irpA6n0.net
>>510
頭が良い悪いは関係なくて、単に慣れの問題だと思うよ
心配しなくても、そのうち慣れる
532:デフォルトの名無しさん
22/09/11 12:15:22.07 EZu34myO0.net
ある程度の難しさがあるのは確かだと思うので地図を読むことの得手不得手みたいな適性は何かしらあるかもしれない
533:デフォルトの名無しさん
22/09/11 12:17:08.26 EZu34myO0.net
けどブランチ切り替えくらいなら慣れだな
分散開発で計画やマージを任せられるとなると人によって難しい
534:デフォルトの名無しさん
22/09/15 14:34:12.65 cRBlrBBnF.net
githubの質問ってここで良いのかな？
フォーク基のリポジトリをPublicからPrivateに変更したら、Publicの時にフォークしたユーザーのリポジトリに影響って出る？
535:デフォルトの名無しさん
22/09/15 23:28:16.29 GwVm0Djk0.net
>>519
こっちでお願いします
ｿｰｽｺｰﾄﾞ ﾎｽﾃｨﾝｸﾞ総合【GitHub,GitLab,Bitbucket等】
ｽﾚﾘﾝｸ(tech板)
536:デフォルトの名無しさん
22/09/16 13:09:50.05 QQvhz5cq0.net
Git v2.38.0-rc0
537:デフォルトの名無しさん
22/09/23 16:47:47.90 UblpnXcK0.net
Git v2.38.0-rc1
538:デフォルトの名無しさん
22/09/27 03:57:55.82 x8Dmf6Id0.net
c:\gittest\server\proj01
c:\gittest\client\proj01
というフォルダ作って上から下にcloneはできて下のフォルダで完結する操作はできたんだけど
下から上にpushしようとすると失敗する
To c:\gittest\server\proj01
! [remote rejected] master -> master (branch is currently checked out)
error: failed to push some refs to 'c:\gittest\server\proj01'
こういう学習のためのテスト環境ってローカル同士じゃダメなんですか？
539:デフォルトの名無しさん
22/09/27 07:59:31.26 UwDioOcC0.net
bare repositoryになってないとかmaster,developへの直接push不可になってるとか
540:デフォルトの名無しさん
22/09/27 09:48:59.09 +d371Z/C0.net
【Git】bare リポジトリで無いならば、push を受け入れないことを知りました
URLﾘﾝｸ(oki2a24.com)
学習のためだけならreceive.denyCurrentBranchを設定してもいいかもね
541:デフォルトの名無しさん
22/09/27 10:14:08.47 c2KUidKp0.net
不可解な挙動で学習時間や意欲をロスしないためにも普通の構成にしたほうがいいと思う
俺ならserver(bare)とclient1とclient2を作る
542:デフォルトの名無しさん
22/09/27 11:33:58.99 vJTIC1iI0.net
そもそもどこからcloneして
543:きたのか不明だし、こういう質問する奴って情報が不足し過ぎてるような githubとかにあるようなのをcloneしてpushして失敗しましたとかなら草だがｗ
544:デフォルトの名無しさん (ﾜｯﾁｮｲ 7fe4-Nf8B)
[ここ壊れてます] .net
別にどこからcloneしてきたとか関係ないよ
デフォルト設定だとbareでないレポジトリへpushできないことがあるのは仕様
bareにするとかdenyCurrentBranchは危ないよとかググれば日本語の情報もいっぱいある
545:デフォルトの名無しさん
22/09/28 09:04:02.38 +1FeoF9d0.net
Git v2.38.0-rc2
546:デフォルトの名無しさん
22/09/28 11:25:13.07 bhRVKQK10.net
server側をベアで作り直したらうまくいきました
ありがとうございます
なぜ入門書はここら辺を説明してくれずに
まずGitHubのアカウントを作ります。とか言い出してしまうのか
547:デフォルトの名無しさん
22/09/28 11:44:27.73 MP/YhhuJ0.net
選び方が悪いね
そういう方向性の入門書ならプロジェクトリーダー濱野氏の入門Gitだ
5章「2か所で使う」でバックアップリポジトリをbareで作って云々を解説してる
githubには一切触れていない(と思う)
git clone /pub/repositories/～ みたいなローカルマシン内でのcloneを解説してる本は他にあるのかな
548:デフォルトの名無しさん
22/10/01 10:02:20.72 DVLayUHe0.net
Gitをインストールした記憶がないのに、なぜかインストール済みでした。
Git Bashを起動すると、プロンプトが変だし、フォントが小さいし、色付けもされません。
プロンプトは「~>」です。
これはどういうことでしょうか？
549:デフォルトの名無しさん
22/10/01 14:10:19.42 J9f91GHl0.net
それウィルスに感染してる
550:デフォルトの名無しさん
22/10/02 17:48:34.37 6kxI91N30.net
コミットメッセージについてです
テキストエディタを使って複数行書く方法と、コマンドライン上で1行書く方法が
あるみたいですが、基本的にはどっちを使うべきなんでしょうか？
551:デフォルトの名無しさん
22/10/02 18:05:40.19 dk1cJbbAM.net
仕事や既存OSSならチームのルールがあるだろうから先輩に聞け
個人ならどっちでも自分が楽な方でいい
ぶっちゃけコミットメッセージなんか誰も見ないから実際どうでもいいし、
そのうちチームに入ってから空気読めばいいだけの話なんで学習中の身のうちから意識して鍛えておかなければならないほど大した話ではない
552:534
22/10/02 18:30:26.77 6kxI91N30.net
>>535
分かりました ありがとうございます
取り敢えずVSCodeを使っておこうと思います
553:デフォルトの名無しさん
22/10/02 18:55:33.63 q9OgIqJtM.net
Vimを使って書くのが正しいやり方です
554:534
22/10/02 19:05:01.56 6kxI91N30.net
>>537
そうなんですね
インプレスの本ではVSCodeを使いなさいと書いてあったのでそうしました
555:デフォルトの名無しさん
22/10/02 19:10:39.82 uPDZdRB50.net
コミットメッセージちゃんと書けるやつが本物のプログラマ。書けないやつはゴミグラマー。
自分で試行錯誤しているローカルリポジトリはコマンドラインで適当に入れても良いけど、他人に見せるやつはエディタで丁寧に時間をかけて書く。
コードを書いている時間よりコミットメッセージ書いている時間の方が長いくらいで普通。
556:デフォルトの名無しさん
22/10/02 19:16:22.79 D5S18uSu0.net
長文したためなくてもバグトラッカーのID書いてあればいいよ
繰り返しになるけどプロジェクト次第
557:デフォルトの名無しさん
22/10/02 19:28:14.51 Sn8H/WH4M.net
>>539
まあチーム次第だから君が間違っていると言うつもりはないが、一般的に言って流石にコーディングより時間をかけるのは時間の無駄
コミットメッセージは見つけづらくて無駄だから、そんな時間があったらドキュメントでも書いてくれ
558:デフォルトの名無しさん
22/10/02 20:42:06.76 t7yq2oGI0.net
URLﾘﾝｸ(git-scm.com)
> The log message that explains your changes is just as important as the changes themselves. Your code may be clearly written with in-code comment to sufficiently explain how it works with the surrounding code, but those who need to fix or enhance your code in the future will need to know why your code does what it does, for a few reasons:
...
559:デフォルトの名無しさん
22/10/02 21:53:11.93 QRo7yeZh0.net
>>539
コマンドラインでもコミットメッセージはvimとかで丁寧に書けますが
560:デフォルトの名無しさん
22/10/02 21:57:22.79 QRo7yeZh0.net
>>541
ReamineのチケットとかGithubのIssueとかにコミットを結びつけた方が読みやすいよね
561:デフォルトの名無しさん
22/10/02 22:11:44.82 uPDZdRB50.net
>>543
vim はエディタでないという主張は初めて聞いた。emacs は環境とういうのは良く聞くけど。
562:デフォルトの名無しさん
22/10/02 22:30:04.49 w76y/xOG0.net
コミットはWindowsでやるならTortoiseGitが楽でいい複数行のコメントも書けるしね
ログもGUIの方が見やすいし、diffもそうだしね
563:デフォルトの名無しさん
22/10/02 23:56:46.78 Yp4OiWZtd.net
今時Tortoiseはないでしょ
GitはSVNなんかと違ってフォルダベースじゃないからファイルエクスプローラ上で操作するのは非合理で、
SourceTreeのようなワーキングツリーの差分をフラットに扱うクライアントのほうが圧倒的に使いやすい
普通に開発を進める分にはVSCodeやVS等のエディタ付属のGit機能で十分だしな
564:デフォルトの名無しさん
22/10/03 01:53:25.03 VqHymwUT0.net
Windows版のSourceTreeがクソダサなのは何かの嫌がらせなの
565:デフォルトの名無しさん
22/10/03 11:24:33.95 KjjssmK/0.net
以前GitHubへSSH認証で接続したことがあったので、
GitBashでssh -T git@github.comと入力してみたのですが、
Permission denied (publickey).と表示され、接続を拒否されてしまいました
どう対処すればよいでしょうか？
566:デフォルトの名無しさん
22/10/03 11:33:15.47 9fynhyqE0.net
gitに関係ないのでこっちで質問してください
ｿｰｽｺｰﾄﾞ ﾎｽﾃｨﾝｸﾞ総合【GitHub,GitLab,Bitbucket等】
ｽﾚﾘﾝｸ(tech板)
567:549
22/10/03 16:52:54.84 KjjssmK/0.net
>>550
分かりました
失礼しました
568:デフォルトの名無しさん (ﾜｯﾁｮｲ ff7c-pIDl)
[ここ壊れてます] .net
>>547
SourceTreeなんてゴミ使うかよｗ
よっぽどTortoiseGitの方が使いやすいわｗ
569:デフォルトの名無しさん (ﾜｯﾁｮｲ d39f-xADz)
[ここ壊れてます] .net
クラーケンでいいっすよ
570:デフォルトの名無しさん
22/10/03 23:39:02.11 HIJT7OgS0.net
>>547
ワーキングツリーの差分をフラットに扱う、について詳しく教えてもらえませんか。
fetchするときだけSourceTree使ってるんですが、いい点があるなら知りたいです
差分の見た目はgitkと同じだと感じてまして。
571:デフォルトの名無しさん (ﾜｯﾁｮｲ 53c8-H9hz)
[ここ壊れてます] .net
あ、わかりました。
TortoiseGitの、エクスプローラのオーバーレイと比較してるんですね。
572:デフォルトの名無しさん
22/10/04 08:23:42.03 uzf3Ju8H0.net
Git v2.38.0
573:デフォルトの名無しさん
22/10/04 11:25:30.61 00cm+2sC0.net
TortoiseGitのオーバーレイって別に全OFFでもいいんだよな
もっさり感とかのマイナスイメージの原因でもある
コンソールを開いてないときに全体がダーティかどうかが見えるか程度のメリット
574:デフォルトの名無しさん
22/10/04 13:18:54.26 8FecEEXR0.net
TortoiseGitはシェルエクステンションの時点でインスコする気失せる
575:デフォルトの名無しさん
22/10/04 15:00:17.58 iRJJVrVe0.net
git
576:使うなら開発者が愛用してるEmacsのmagitを使おうぜ
577:デフォルトの名無しさん
22/10/05 08:43:21.48 sfonbe+Ea.net
GUIクライアントならForkおすすめ
578:デフォルトの名無しさん
22/10/05 22:35:11.78 UUeH3vvk0.net
そうなんだ、fork使ってみようかな
windowsしか知らないけど、sourcetreeだとdiffの横スクロールが使いづらい。
hunkごとに子scrollviewで表示するんだけど、親のscrollviewを下にスクロールしてからじゃないと、子の横スクロールバーが出てこない。
あとダブルクリックでExternal diffできないのも辛い。
さらにコミット画面が、履歴と別の画面なのが個人的にはイヤ。
履歴表示で、コミットをつなぐ線にヒット判定がないのも見ずらい。
579:デフォルトの名無しさん
22/10/06 18:25:19.94 q29RvDaDM.net
fork使ってみましたがなかなかいいですね。
自分にはSourceTreeより合っているようだ。
580:デフォルトの名無しさん
22/10/06 18:28:48.47 N59THtE80.net
女性二人が書いた売れ筋の入門書を読んでいてもGitについて、どういうものなのかハッキリしないのですが、
分かりやすく解説している本またはサイトを教えてください。
581:デフォルトの名無しさん
22/10/06 18:57:50.90 tI414gt60.net
使い方が分からないという話？
それともソース管理がイマイチ分からない話？
582:デフォルトの名無しさん
22/10/06 19:20:02.27 zjAiMCMB0.net
なんでGitが必要なのでしょうか？
シェルスクリプトでcpしてdiffを使って差分を見ればいいのではないでしょうか？
バイナリ形式で保存されていて将来データが取り出せなるので困ります。
583:デフォルトの名無しさん (ﾃﾃﾝﾃﾝﾃﾝ MM7f-d1zO)
[ここ壊れてます] .net
>>565
知らんがな。
Git採用を決定したヤツに言えよ。
584:デフォルトの名無しさん (ﾜｯﾁｮｲ d314-pIDl)
[ここ壊れてます] .net
決定してませんよ
うちの学生にはシェルスクリプトで全部やらしています
流行り物のバージョン管理ツールなんて使わせません
585:デフォルトの名無しさん (ﾜｯﾁｮｲ cfbb-fxWw)
[ここ壊れてます] .net
>>565
お前はいつ、誰が、何のために変更したか全部覚えておけるの？
どの変更とどの変更が一緒の組でどれが独立した修正か、差分見ただけですぐに区別できる？
多数の変更案の中から必要なものだけをすぐに組み合わせられる？
開発人数が多くなっても同じことができる？
1万回修正したとして、その差分を全部コピーで持っておくの？
その無数のコピーの中から必要なコピーを見つけるのはどうやってやるの？
586:デフォルトの名無しさん (ﾃﾃﾝﾃﾝﾃﾝ MM7f-d1zO)
[ここ壊れてます] .net
>>567
この「うちの学生」とは、あなたの想像上の存在に過ぎないのではないでしょうか。
587:デフォルトの名無しさん (ﾜｯﾁｮｲ d314-pIDl)
[ここ壊れてます] .net
>>569
実際に教えていますが何か？
URLﾘﾝｸ(richlab.org)
そんな中，まさにその疑問や悩みに応えるような内容の講義
「シェルスクリプト言語論」を金沢地区の大学向けに、2016年から
開講してきました．ここまで4回（4年）開講し，内容が洗練されてきたところでついに書籍化しました．
588:デフォルトの名無しさん
22/10/06 20:19:02.29 tI414gt60.net
バイナリでも別に過去の履歴は取って来れるような
ただリポジトリは肥大化するしバイナリの管理の為に作られたものでは無いから
相性が良い訳では無いのは分かるのだが
プログラム開発の世界でバイナリと言えば大抵はエクセルなどのオフィス系のファイルだが
正直これらをgitでバージョン管理する必要は無い気はしなくもないｗ
（でも大抵の会社はバイナリだろうがgitで管理しているが）
589:デフォルトの名無しさん
22/10/06 20:45:30.79 zjAiMCMB0.net
>>571
なにか勘違いしているようだな
gitはテキストデータでも保存するときに
バイナリ形式を使っているから将来データが取り出せなくなると言っておるのだ
その�
590:謔､なものは使わん
591:デフォルトの名無しさん
22/10/06 20:46:16.55 tI414gt60.net
ん？将来？別に好きな履歴を取り出せるが？
何の話だ？
592:デフォルトの名無しさん
22/10/06 21:08:34.12 vH9MiC1U0.net
gitの使い方を知らないただの老害だった…
593:デフォルトの名無しさん
22/10/06 21:49:48.89 p6k/LOp80.net
>>565 おじいちゃん去年のスレッド忘れてまた来ちゃったの？
さぁ↓こっちに帰りましょうね。
ｽﾚﾘﾝｸ(tech板)
594:デフォルトの名無しさん
22/10/06 21:50:57.66 J7yBN2sy0.net
いつもの粘着荒しじゃないの
途中で句読点のスタイルが変わってるし半分コピペの創作だろ
あの手この手で相手してほしいんじゃね
595:デフォルトの名無しさん
22/10/06 22:22:36.07 DBe4OZi40.net
バイナリ形式だから将来取り出せないって、何を心配してるんだろう？ 文明崩壊後でコンピューターが使えなくなった時？ 岩に刻んでおく？
596:デフォルトの名無しさん
22/10/06 22:38:26.50 PvD2K1c/r.net
間抜けなPOSIX原理主義者がまた論破されて敗走したのか
597:デフォルトの名無しさん
22/10/06 23:17:53.55 jAkUbGv20.net
>>563
俺もその本読んだけど、何となくGitの存在意義分かったよ
例えば会議の備忘録がこんな感じで複数あるとしたら？
・備忘録_1.txt
・備忘録_2.txt
・備忘録_1改.txt
・備忘録_最新.txt
・備忘録_3.txt
どれが最も新しいかピンとこない、どの順に更新されたのかピンとこない、
誰がどのファイルにどんな更新を加えたの分からない
そんな問題を解決してくれるのがGitのようなバージョン管理ツール(って書いてある)
598:デフォルトの名無しさん
22/10/06 23:50:19.63 orz8mNRt0.net
Gitむずかしいな
みんなよく使えるな
599:デフォルトの名無しさん
22/10/07 04:44:37.69 TBR3DhbF0.net
>>563
YouTube で「git 使い方」「git 入門 」などで検索！
山浦清透・せお丸・くろかわこうへい・しまぶーなど、色々ある
600:デフォルトの名無しさん
22/10/07 09:55:21.21 E++rKArz0.net
>>577
UNIX哲学ではバイナリ形式は禁止されている
愚か者め
601:デフォルトの名無しさん
22/10/07 10:07:54.49 GHAO4XK10.net
>>582
だから、そのバイナリーって何よ？
602:デフォルトの名無しさん
22/10/07 10:12:43.41 E++rKArz0.net
>>583
話のわからんやつだな。この本を買え。全部書いとるわ。
URLﾘﾝｸ(techbookfest.org)
我らが一番問題だと思っているのは、リポジトリーの中身の多くが訳のわからぬバイナリーデータになって
いることだ。そのバージョン管理ソフトウェアが滅んだら復元は絶望的だ。テキストデータ形式ならば眺めれ
ば方策も見えてくるのでまだ何とかなりそうな気がするというのに。「データはテキスト形式で保存せよ」とは
UNIX 哲学でも言われてきたことだ。一体何を考えているのか。
603:デフォルトの名無しさん
22/10/07 10:13:25.77 E++rKArz0.net
移り行くトレンド
古参のプログラマーなら、これまでどんなバージョン管理ソフトウェアが台頭してきたか振り返ってみよ。す
ぐ思いつくものだけでも、RCS、CVS、SVN、そしてGit。これらは同時期に存在して覇権を争っていたのでは
ない。それぞれが時代を担ってきたといっても過言ではない。時代によって使うものが替わり、新しいバージョ
ン管理ソフトウェアが
604:流行り出せば、その使い方を覚え直し、時にはリポジトリーの移行を強いられてきたこと だろう。よくまぁ、懲りもせずにといったところだが、我らはもうたくさんだ。もしかすると、諸君は「Git を 覚えれば安泰だ」などと思っているかも知れんが、あと数年、遅くとも5 年も経てばきっと次のバージョン管理 ソフトウェアが登場し、覚え直しとリポジトリーの移行を余儀なくされることだろう。
605:デフォルトの名無しさん
22/10/07 10:13:49.81 E++rKArz0.net
目的を見失っったバージョン管理ソフト
バージョン管理ソフトウェアのそもそもの目的は何だったのか。開発を続け、バージョンアップしていくソフ
トウェアの維持管理に要するコストの抑制であったはずだ。これは、POSIX 原理主義を崇拝する我らがソフト
ウェアを5 年、10 年と生き長らえさせようとする、その根底に流れる目的そのものである。
ソフトウェアはバージョンアップする。新しいコードを加え、古いコードは切り捨て、時には依存するライブ
ラリーを付け替えもする。その変わる様をすべて見届けることがバージョン管理ソフトウェアの役割であり、そ
れができて初めてまともに維持管理コストの抑制が実現する。ゆえに、
バージョン管理ソフトウェアは、ライブラリーの類よりも遥かに長く生き長らえなければ意味がない。
ところが実際はそうなっていない。「バージョン管理ソフトウェアの維持管理」を強いられる。本末転倒もい
いところ。お前は何を言っているんだ。
606:デフォルトの名無しさん
22/10/07 10:26:43.54 8xhEA9gJ0.net
覚え直しと移行すりゃいいじゃん
その時期がくれば便利な移行ツール（git svnコマンドのような）が出回るし、簡単なことだよ
そんなちっぽけなことを恐れて、完全無欠の理想通りじゃないからと今のベターな現実解を忌避するのはあれだ
こだわりが強すぎて社会生活に支障が出るタイプの典型的症例
607:デフォルトの名無しさん
22/10/07 10:31:38.34 E++rKArz0.net
>>587
何度も何度も覚え直しでお前は成長してると言えるのか
シェルスクリプトだけでなんでもできる
608:デフォルトの名無しさん
22/10/07 10:33:30.22 E++rKArz0.net
>>587
中身がわけのわからんバイナリデータなのだから壊滅的だ
データは取り出せなくなり移行なんかできん
バージョン管理ソフトウェアが滅んだら復元は絶望的だ
609:デフォルトの名無しさん
22/10/07 11:43:19.78 GHAO4XK10.net
中身がわからんのはお前が無能だからだろ。ソースも公開されてるし、中身の形式も公開されてるので読んどけ。プロプラな機密ソフトの基準で語ってんじゃねーよ。
中身が完全にわかっているという意味ではテキストと同等かフォーマットが決まってる分それ以上に効率が良い。
610:デフォルトの名無しさん
22/10/07 12:18:40.03 6in1nvJWM.net
>>582
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている
611:デフォルトの名無しさん
22/10/07 12:20:40.01 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:デフォルトの名無しさん
22/10/07 13:30:31.61 8xhEA9gJ0.net
>>588
成長？
最適なツールを選ぶときに成長とか関係ある？
淡々と使うだけだろ
何度も何度もっていったい何百年生きるつもりなんだ
613:デフォルトの名無しさん
22/10/07 13:58:18.44 +OS+xNc10.net
USP研究所のシェルスクリプトマガジンを購読しているけど、
こんな人がライターなのか？
いささかガッカリした。
614:デフォルトの名無しさん
22/10/07 14:06:48.59 h1ATf2/y0.net
バイナリに見えるのはgzip圧縮されてるだけでgitconfigに
compression=
615:0 loosecompression=0 を書いておくと無圧縮のテキストになったような
616:デフォルトの名無しさん
22/10/07 14:37:14.17 E++rKArz0.net
>>593
せっかく覚えたのにバージョン管理ツールが変わって知識が役に立たなくなると言っておるのだ
シェルスクリプトなら20年後も今の知識が通用する
URLﾘﾝｸ(www.slideshare.net)
617:デフォルトの名無しさん
22/10/07 14:39:12.40 q9dWCqSf0.net
頭おかしい奴が沸いているｗ
618:デフォルトの名無しさん
22/10/07 15:14:19.27 h1ATf2/y0.net
ちなみにgitのリポジトリは、ブランチ、コミット履歴、データ(ファイル)の3種類を
それぞれsha1ハッシュで繋いでいるだけのシンプルな構造
リポジトリをバラしてファイルを取り出すだけのプログラムなら大体の人は1日もあれば作れるよ
619:デフォルトの名無しさん
22/10/07 15:32:28.30 GHAO4XK10.net
>>598
さすがに1日もかからんやろ。スクリプト言語使って15分とかそんな感じでは。
620:デフォルトの名無しさん
22/10/07 16:01:35.71 IRNCV7aTr.net
>>596
そんなに苦痛なんだ。
大変だね。
621:デフォルトの名無しさん
22/10/07 16:13:03.09 h1ATf2/y0.net
む
〇zlib圧縮
×gzip圧縮
622:デフォルトの名無しさん
22/10/07 17:08:55.91 E++rKArz0.net
>>598
ならばそのsha1ハッシュをPOSIXの範囲で作ってみよ
POSIX準拠で仕様が許されてるハッシュ化コマンドはcksumのみだ
我らはbase64コマンドをawkで作ってみせた
623:デフォルトの名無しさん
22/10/07 17:09:18.38 E++rKArz0.net
POSIX準拠で使用が許されてる
624:デフォルトの名無しさん
22/10/07 17:35:13.58 GHAO4XK10.net
>>602
アホはスクリプト言語で書いた。
普通の人は速度出したいのでそういう用途にはCコンパイラ使う。POSIXにC言語の規定がないとでも思ってるんだろうな。
625:デフォルトの名無しさん
22/10/07 18:19:16.51 E++rKArz0.net
>>604
アホはお前だ。POSIXにC言語の規定があることぐらい知っておるわ。
C言語はハードウェア依存する。そのような効率よりも移植性のほうが重要だ。
URLﾘﾝｸ(www.ipsj.or.jp)
POSIXに準拠したプログラムを作成することにすると，開発言語はシェルスクリプト
またはC言語（C99）に限定される．その理由は，POSIXで用意されている
プログラミング言語としてのコマンド（以下，POSIXコマンドと記す）に
PerlやRuby，Javaといった現在よく利用される高級言語は存在せず，
存在するものはBourneシェル（sh コマンド）とCコンパイラ（c99コマンド）だけだからである．
どちらを選択してもPOSIXに準拠したプログラミングができることにはなるが，
基本的にはシェルスクリプトを利用する．C言語はバイトオーダ等のハードウェア構造を
意識しなければならない．一方，シェルスクリプトであれば，そのようなハードウェア依存は
POSIXコマンドが吸収しているため，意識せずにプログラミングできることが理由である．
したがって，POSIX中心主義では，POSIXの仕様に準拠したシェルスクリプトを
中心としたプログラミングをする．シェルスクリプトを選択することには，以下に述べる3つの利点がある．
626:デフォルトの名無しさん
22/10/07 18:20:33.07 E++rKArz0.net
>>604
シェルスクリプトが遅いなどというのも間違いだ。
それはストリーミング型の書き方を知らない愚か者の戯言だ
3.1.1 開発効率と処理効率の両立
シェルスクリプトはC言語と比べて処理の遅さを指摘されるが，それは必ずしも正しい認識ではない．
シェルスクリプトはインタプリタ型言語であるため，ステップ数が多いほど処理効率は悪化する．
また各ステップに外部コマンドを起動する記述があればそれも大きな処理効率悪化につながる．
しかし，手続き型の書き方からストリーミング型の書き方に改めるように工夫すれば，
ステップ数の増加を抑えられ，処理効率は大きく改善する．
627:デフォルトの名無しさん
22/10/07 18:27:03.31 GHAO4XK10.net
>>606
�
628:ｶゃあ、お前がシェルスクリプトで git 書けばいいんじゃね？ 俺はバイトオーダーに依存しないCプログラムの書き方知ってるのでそっち使うけど。
629:デフォルトの名無しさん
22/10/07 18:36:41.70 E++rKArz0.net
>>607
我らはすでにシェルスクリプトでバージョン管理を行うすべを持っておる
gitを書く必要などない
知りたくばこれを買ってPOSIX主義的バージョン管理概論を読め
URLﾘﾝｸ(richlab.org)
630:デフォルトの名無しさん (ﾜｯﾁｮｲ cfbb-fxWw)
[ここ壊れてます] .net
>>608
ゴミを勧めんな。オライリーに訴えられてろ。
631:デフォルトの名無しさん
22/10/07 20:35:52.31 E++rKArz0.net
>>609
ゴミならば大学の教科書になっておらぬわ
632:デフォルトの名無しさん
22/10/07 23:21:13.94 YKezo8WP0.net
forkで2つのコミットの差分どうやって見るの？
履歴から2つ選択しても出ない。コンテキストメニューも。未実装？
633:デフォルトの名無しさん
22/10/08 00:36:23.18 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:デフォルトの名無しさん
22/10/08 05:07:17.54 qNYwj5bN0.net
>>610
大学には頭おかしいのがおらんとでも？
大学全体の何割が使ってるか言ってみ。
635:デフォルトの名無しさん
22/10/08 07:49:17.82 fwLI4Y/XM.net
どうせ安全じゃないだろw
>fatal: detected dubious ownership in repository at
こんなものつけるなよカス
636:デフォルトの名無しさん
22/10/08 09:15:42.49 vxPAcYo70.net
>>613
大学だけじゃないぞ
プログラマならシェルスクリプトマガジンぐらい知っておろう
そこに長期連載されているほど、普及しておる
頭がおかしいなら、こんなに長く連載されるはずがないな
637:デフォルトの名無しさん
22/10/08 13:26:00.09 HbWzH6SVM.net
>>615
シェルスクリプトなぁ……簡単な作業の自動化用途だな。
なんでgitスレでこんな話題が？
NG指定したほうがいい？
638:デフォルトの名無しさん
22/10/08 14:00:29.88 x9F/jCO70.net
>>612set-headサブコマンドが使えるみたい
639:デフォルトの名無しさん
22/10/08 14:11:03.99 vxPAcYo70.net
>>616
愚か者め。シェルスクリプトは何でも出来る。CGIも作れた。
この間はUNIX哲学に基づいてリアルタイムカーネルなしに
シェルスクリプトだけでリアルタイム処理を実現してみせたわ
URLﾘﾝｸ(www.sea.jp)
640:デフォルトの名無しさん
22/10/08 14:23:26.42 vxPAcYo70.net
>>616
gitのような目的を見失ったバージョン管理ソフトを使っているからだ
バージョン管理ソフトはライブラリよりも長く行き続けなければならんものだが
リポジトリでわけのわからんバイナリ形式を使っておるから
バージョン管理ソフトが滅んだら復元は不可能になる。一体何を考えておるのか。
「データはテキスト形式で保存しろ」とはUNIX哲学でも言われている。
641:デフォルトの名無しさん
22/10/08 14:47:58.03 TKlSmRLn0.net
容れ物が古くなったら新しい容れ物に中身を移すだけ。
642:デフォルトの名無しさん
22/10/08 14:51:46.02 vxPAcYo70.net
>>620
よくもまあ懲りもせずにといったところだな
そうやって古くなったソフトを捨て新しいものに入れ替え
せっかく覚えた知識は無駄になり移行作業で苦しむ
POSIX原理主義なら一度覚えた知識は一生使うことが出来る
新しいことを覚える必要はない
643:デフォルトの名無しさん (ﾜｯﾁｮｲ deb0-zauZ)
[ここ壊れてます] .net
啓蒙したいんだろうけど
>新しいことを覚える必要はない
これ読んで「そんなメリットがあるなら俺もPOSIX原理主義に入信しよう」と考えるエンジニアがいるもんかね。
644:デフォルトの名無しさん
22/10/08 15:30:37.98 5sXOif570.net
>>617
git remote set-headだとリモートトラッキングブランチのHEADが変わっただけでベアリポジトリ側のHEADは変わらず、
HEADが指してるブランチ(master)も削除操作が利かないままだったんですが、もうちょっと教えてもらえませんか
645:デフォルトの名無しさん
22/10/08 17:26:15.60 qNYwj5bN0.net
>>621
いいから、お前は黙ってシェルスクリプトでOSカーネルでも書いとけ。完成するまで戻って来るな。
646:デフォルトの名無しさん
22/10/08 17:39:03.44 88/OpuEG0.net
啓蒙したいんじゃなくて単に荒らしたいだけだから
だいたいオープンソースなのにソフトウェアが滅ぶとか意味がわからん
647:デフォルトの名無しさん
22/10/10 11:28:58.21 JuIf0a+H0.net
シェルスクリプトのヤツは釣りだろ？
マジでいってんだったら頭おかしいだろw
(基地外を釣るエサ投下)
648:デフォルトの名無しさん
22/10/10 17:13:47.79 +gDGPUis0.net
URLﾘﾝｸ(megalodon.jp)
私の場合は「POSIX原理主義者」という名の人格者として名を知られるようになってきたが、「原理主義」を名乗るだけあって、
649:デフォルトの名無しさん
22/10/10 17:25:23.67 PTVZRYxu0.net
>>627
いいからお前はシェルスクリプトでカーネル書く作業に戻れ。シェルスクリプトがあれば何でもできるんだろ。
650:デフォルトの名無しさん
22/10/10 17:30:56.62 +gDGPUis0.net
>>628
勘違いしてるぞ。俺は人格者（笑）って書き込んだだけだぞ
651:デフォルトの名無しさん
22/10/16 04:54:37.57 kNlIrq3k0.net
Shelling at Russian power plant leaves Belgorod without electricity
URLﾘﾝｸ(www.youtube.com)
652:デフォルトの名無しさん
22/10/16 04:55:55.59 kNlIrq3k0.net
間違えた、すまん
653:デフォルトの名無しさん
22/10/19 13:19:13.07 1sfAoeRGa.net
Git v2.38.1
654:デフォルトの名無しさん
22/10/27 07:22:57.17 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:デフォルトの名無しさん
22/10/28 00:23:09.45 yz6FOYrM0.net
LooseCompressionの全展開用の領域 2MB*2800=5.6GB
git logは内部でlessにパイプでデータを渡してるから
パイプバッファも含めて約2倍だろうか
Packしなけりゃ少しはマシかもしれない(未確認)
656:デフォルトの名無しさん
22/10/28 07:15:31.79 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:デフォルトの名無しさん
22/10/28 07:18:13.37 RikIMzkC0.net
報告してあげるといい事案だと感じる
658:デフォルトの名無しさん
22/10/29 06:39:27.49 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:デフォルトの名無しさん
22/10/29 08:37:46.51 e5vmfD+T0.net
>>637
HEAD~100 とかじゃ駄目なの？
660:デフォルトの名無しさん
22/10/29 08:44:53.54 +5EirK6r0.net
いやバグレポートすればいいと思う
661:デフォルトの名無しさん
22/10/29 09:15:13.77 J4pkDf7Q0.net
>>638
実はそこは初心者過ぎてよく知らないんだわ。
git log HEAD~100
では制限出来なかったけど、どう書くべきなの？
とりあえず公式マニュアルでは -n が最初に載ってるので、-n が一番お手軽なのだと思う。
これが効かないのは、多分実装忘れじゃないかと。
> URLﾘﾝｸ(www.git-scm.com)
>>639
多分、メモリ大量使用は仕様で、-n が効かないのはバグだね。
662:デフォルトの名無しさん
22/10/29 09:25:26.30 +5EirK6r0.net
合理性のないメモリ使用があるなら実害があるユーザーが改善のリクエストをバグレポートで出せばいい
そういうもん
レアケース扱いされることもあれば皆が困ってるようなら優先的にチューニングされる
仕様なのでは！？と空気読んで黙ってるのは奥ゆかしいニンジャ精神
663:デフォルトの名無しさん
22/10/29 09:38:02.85 J4pkDf7Q0.net
>>641
なるほどその通りだ。
ガイドラインが糞長げえ…orz が、数日のうちにレポートする方向でやります。
> URLﾘﾝｸ(www.chiark.greenend.org.uk)
> URLﾘﾝｸ(www.git-scm.com) 内の this guide が上記
664:デフォルトの名無しさん
22/10/29 11:09:21.06 +W9Ulup+0.net
>>640
手練れのエンジニアとお見受けするが、どのジャンルで仕事されているので？
665:デフォルトの名無しさん
22/10/29 15:16:52.52 e5vmfD+T0.net
>>640
HEAD~100..HEAD みたいなのを最後につけてレンジを制限する話だけど効かない？
666:デフォルトの名無しさん
22/10/29 21:10:22.54 YQqcaKMe0.net
git log -100 じゃなくて？
667:デフォルトの名無しさん
22/10/29 23:05:25.26 e5vmfD+T0.net
>>645
-100 と -n 100 と --max-count=100 は同じ意味で表示するログの数を制限する
A..B はログを検索する対象を制限する。(Bには存在するけどAには存在しないコミットという意味になる）
668:デフォルトの名無しさん
22/10/30 02:06:46.88 IOU525bY0.net
>>644
効いた！ありがとう。
何ぞそれ？と思いきや git log のdocumentの頭に書いてあるのな。
> URLﾘﾝｸ(www.git-scm.com)
gitは機能が多すぎてドキュメントがやたら長いので端折っていたのが敗因だ。
やはり最初は一通り読まないと駄目だな。
これなら回せばいいので、組んでみたら32bit環境で43秒で終了した。
これだと高速化チューニングではなく単にfree忘れっぽいのでレポートしておいた。
再現用のスクリプトも同梱してるから気になる人はどうぞ。
URLﾘﾝｸ(lore.kernel.org)
669:デフォルトの名無しさん
22/10/30 09:36:57.12 b5HYhcbp0.net
>>647
おつかれ。
慣れてくると git log とかは全ログ対象にはしなくて、素でレンジ指定するので、この手のリソース問題は見つけ難いんだよな。
670:デフォルトの名無しさん
22/10/30 12:37:33.31 IOU525bY0.net
>>648
初心者は意味不明な使い方を無自覚でやるから、どうしてもマイナーバグに当たりやすい。
なるほどタグを付けてgit logでは範囲指定がデフォか…
ってそのままtutorialに書いてあったわ。やっぱちゃんと読まなきゃ駄目だったorz
> URLﾘﾝｸ(www.git-scm.com)
つまるところ、今までこんな馬鹿げた使い方をした奴は居なかっただけだな。
671:デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4)
22/10/30 18:58:14.60 IOU525bY0.net
git diff の出力はデフォでpatchになってるのだが、これどうやったら切れるんだ？
> URLﾘﾝｸ(www.git-scm.com)
既にフォーマッタを持っているので、
unixコマンドのdiffのデフォルト出力と同じ物が
672:欲しい。 切るオプションも無いし、下の方のCONFIGURATIONにもそれらしい設定が見つからない。 diff.externalでdiffごと入れ替えないと駄目とかいうクソ仕様？ -s や --no-patchでは出力そのものが出なくなる。ただし > or to cancel the effect of --patch. と書いてあるから、かつては--no-patchではdiffのデフォ出力で、-sで出力無しだった気配はあるが。
673:デフォルトの名無しさん (ﾜｯﾁｮｲ 8bbb-VzUj)
22/10/30 21:37:56.23 b5HYhcbp0.net
>>650
git diff は git diff 形式 (unified diff 形式の変形) で出力される。それ以外の形式が欲しい場合は外部コマンド使うしかない。
674:デフォルトの名無しさん
22/10/30 22:10:12.22 IOU525bY0.net
>>651
マジかー。クソ過ぎ。仕様考えた奴馬鹿すぎ。
スクリプトに食わす為に先頭の+-の文字を変更するオプションとかあるのだけど、
これでいいと思った奴は死ねだな。
675:デフォルトの名無しさん
22/10/30 22:14:38.98 b5HYhcbp0.net
>>652
git はパッチ管理システムなんだから、それ以外が考慮されてると思う方が贅沢。
676:デフォルトの名無しさん
22/10/30 22:34:52.61 IOU525bY0.net
>>653
いやそうじゃねえ。というかこれはソフトウェアの構成を間違ってるよ。
diffだってバグはあるのだから、内製は止めて、普通にdiffのdllをコールすべきなんだよ。
GitはLinusが1日で作ったらしいし、最初はどう考えてもそうなっていたはず。
だから俺は config の中にデフォで diff -u みたいなエイリアスがあるのかと思ってた。
diffを内包する事に、何のメリットもない。
この名残がexternal driverで、それが使えればいいという事なのだろうけど、
ご丁寧にこれを禁止するオプションまである。(-no-ext-diff)
多人数の開発では、同じ画面を見ていた方が何かと楽だから、揃える方向で努力するのはごもっともだが、
禁止するのは違う。どこかでおかしな思想が混入しているよ。
そもそも、それ以外を考慮しない＝外部コマンドで十分出来る事はdllを呼ぶ、であって、
この構成だとGitがdiffも構成してるから、君は認識を間違ってる。
Gitは明らかにおかしい方向で無駄な事をやってしまっている。
そしてそれは君の価値観的にもNGなはずだよ。
677:デフォルトの名無しさん
22/10/30 23:37:53.37 b5HYhcbp0.net
>>654
Linus のこと知ってるのなら長文書く前に調べろ。
git 作る以前から、みんなが勝手なフォーマットでパッチ送って来るのは非常に困るので推奨のパッチ形式を決めてあったんだよ。
で git 作る時に強制的にその形式に統一されるようにした。どうしても他の形式で出したい場合はひと手間かかるのが設計意図どおり。
678:デフォルトの名無しさん
22/10/30 23:53:15.06 LXgcbV870.net
Linusも言ってたような気がするけど、気に食わなければ自分で作れ
以上
679:デフォルトの名無しさん
22/10/30 23:58:47.31 IOU525bY0.net
>>655
Linusはデフォを -u にして、patch送るならオプション無しで送れ、としただけでしょ。
これは間違ってない。
問題は、元のdiffの形式の出力が出来なくなってる事だよ。
オプションで出来るよ、でよかっただけ。
オプションすら禁止なら、今のgit diff に各種出力オプションがあること自体が君的に矛盾するだろ。
何故君がそんな意味不明なポジショントークをするのか分からないが、
Gitが方針を間違ってるのは事実だよ。
オプション禁止なら、git diff にオプションを何一つ付けてはいけない。
(仮にこれであれば、賛同はしないが理解はする）
ただまあ、ドキュメントの雰囲気だと、
おそらく昔は --no-patch で元のdiff形式が出せたのではないかと推測される。
君がどこまで知っているのか知らないけど、多分君の歴史理解も間違ってると思うよ。
680:デフォルトの名無しさん
22/10/31 00:04:41.05 h5Hfu9WR0.net
>>657
お前以外は誰もオプションとか必要ないから作ってないだけだよ。むしろ邪魔。どうしてもやりたければ外部コマンド指定でできるんだからオプションとかでやるよりよっぽど汎用性がある。
オープンソースなんだからオプション必要ならお前が自分でつくればいい。
681:デフォルトの名無しさん
22/10/31 00:08:19.51 h5Hfu9WR0.net
あと －－no-patch には昔からパッチ出さない機能しかないぞ。頭悪い推測とかする暇があったら過去のソース確認してこい。
それこそ git で調べればすぐだぞ
682:デフォルトの名無しさん
22/10/31 00:21:01.40 J+3pjzxx0.net
>>859
そうか？ならマニュアルの
> to cancel the effect of --patch
の部分は明らかに不要だから削除要請出しといてくれ。
というか君の「昔」がどれ位か知らんが、Linusの言ってた？フォーマットが統一されてないってのは、
diffの各種オプションではなく、edやsharに対してだと思うぞ。
683:デフォルトの名無しさん
22/10/31 00:43:54.22 h5Hfu9WR0.net
>>660
不要だと思ってるのはお前だけ。その思い込みが勘違いの原因だろ。
684:デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4)
22/10/31 07:08:10.92 J+3pjzxx0.net
色々確認したが、Gitの現状認識としては651であってるっぽい。
そして外部ツール使うしかないが、これは環境設定無しでコマンドだけで出来る。（動作確認済み)
git difftool --extcmd=/usr/bin/diff <commit> <commit>
> URLﾘﾝｸ(qastack.jp)
ついでにその中、
> Gitについて学ぶほど、それは1人の人、つまり元のプログラマーのために作られたものだと感じます。
これもよく言われてるようだが、俺も今回の件で同意だ。
合理性に欠ける判断をしているのだから色々文句言われるのも当然だ。
ただLinusは自分用に作った物を公開したら勝手に使われてるだけだから、知ったこっちゃ無いってのも分かる。
ただそれならそうと、いつもの調子でドキュメントにも書いててくれないと困るね。
合理的な構成を推定すると迷子になってしまう。
俺は絶対に diff -u 以外のフォーマットを許さない！絶対にだ！
とか書いてあれば、最初から諦めるので無駄に探す必要はなかった。
俺はLinusのこういった感情的な部分はわりと好きなのだが、まあ昨今の code of conduct では書いても消されるんだろうけども。
685:デフォルトの名無しさん
22/10/31 10:11:41.92 J+3pjzxx0.net
てかGitってまさかのモノリシックかよ！
こりゃ文句言われるのも分かるわ。完全に方向を間違ってる。
結果的に肥大化していったのだろうけど、現在の状況でこれは駄目だよ。
つかこれシェル化する方向のプロジェクトはないの？
子コマンド群のバイナリだけ貰いたいんだけどさ。
686:デフォルトの名無しさん
22/10/31 10:39:47.64 sko8U7ef0.net
>>663 好きに fork しなよ。
687:デフォルトの名無しさん
22/10/31 12:23:13.35 h5Hfu9WR0.net
自分でやってみればいいよ。
自分で多数の人が参加する巨大なプロジェクトを管理するようになれば、形式が統一されていることがどれだけ重要かわかる。
仕様を強制されているようでも、これこそが git の使い易さ、戦闘証明済の実力だと気付くよ。空想と現場は違う。
688:デフォルトの名無しさん
22/10/31 13:21:07.66 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とかを絶対に交換させない為？ならマジで死ねでしかないね。