Git 18

[表示 : 全て最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2ch.scのread.cgiへ]
Update time : 08/13 17:55 / Filesize : 365 KB / Number-of Response : 1056
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

Git 18

1 名前：デフォルトの名無しさん [2022/04/23(土) 03:25:45.27 ID:HOOXt/T30.net]: ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。

Git - Fast Version Control System
git-scm.com/

◆関連サイト
Pro Git - Table of Contents
git-scm.com/book/ja
Git入門
www8.atwiki.jp/git_jp/

◆前スレ
Git 16©2ch.net
https://mevius.5ch.net/test/read.cgi/tech/1502726047/
Git 17
https://mevius.5ch.net/test/read.cgi/tech/1599016710/
VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured
342 名前：デフォルトの名無しさん (ﾃﾃﾝﾃﾝﾃﾝ MM0e-+MXm) [2022/07/19(火) 18:48:37 ID:4K8TsTnGM.net]: masterなんて切ったら大変なことになるだろ
ボーナス査定でマイナス評価付きそう
343 名前：デフォルトの名無しさん (ｱｳｱｳｳｰ Sa39-9B/I) mailto:sage [2022/07/19(火) 19:04:02 ID:8mmoqS9Qa.net]: センスが悪い出自の語句だという論点でずっと話してるので間違ってるかどうかはポイントじゃないんだけどな
メシは食えりゃいいプログラムは動きゃいいみたいなおおらかな感覚の�
344 名前：lだったらこういう機微の話は伝わらないかもな ギガが足りないとか俺も使うことあるけど、センスのない出自の語句である点も含めて言葉のおかしみだと思っているよ 草がお気に召さないなら「枝を切るとはいとおかし」でもいい []: [ここ壊れてます]
345 名前：デフォルトの名無しさん [2022/07/19(火) 19:11:16.74 ID:S8bArn500.net]: つまりこういうことか。
https://mathworld.wolfram.com/BranchCut.html
346 名前：デフォルトの名無しさん [2022/07/19(火) 19:15:15.54 ID:S8bArn500.net]: 令和のブランチカッターと異名をとる○○。
みたいな使い方するのか。
347 名前：デフォルトの名無しさん mailto:sage [2022/07/19(火) 19:26:24.48 ID:k+9W9ROz0.net]: >>338
「切るは多義的だから分岐開始にニュアンスが合わないわけじゃない」のなら
「branchを切る」はそういう使い方ということで終わりなんだから
センスが悪いとか草とか言っててもどうしようもないって話だけどな

「カードを切る」をカードを切断する以外の、カードを混ぜ合わせるとか
とっておきの手段を使うといった意味で使うことに対しても
切断以外の意味で使うなんて草とか言うのかな
348 名前：デフォルトの名無しさん mailto:sage [2022/07/19(火) 19:40:05.15 ID:8mmoqS9Qa.net]: うんうんそうだねー
トップスにスーツを着てボトムスにステテコを履いたとしてもそういう着方ということで終わりなんだから
センスが悪いとか草とか言っててもどうしょうもないよね
一理ある
後半は何度も繰り返し伝えてるはずのことか全く伝わってないのでもういいや
349 名前：デフォルトの名無しさん [2022/07/19(火) 19:53:47.01 ID:k+9W9ROz0.net]: >>342
「ブランチを切る」を切断以外の意味で使うなんてマヌケな表現で草という話だったよね>>326
「カードを切る」を切断以外の意味で使うのは
トップスにスーツを着てボトムスにステテコを履くような着方
みたいで草ということかな
350 名前：デフォルトの名無しさん mailto:sage [2022/07/19(火) 20:47:35.43 ID:ecrsdhWa0.net]: すくなくとも俺にはブランチ＝枝のほうが違和感あるが
ブランチを切る　で　枝を切る　を連想するのが一般的か？
351 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 89b0-btS4) mailto:sage [2022/07/19(火) 20:58:54 ID:d6XNtDyg0.net]: うちの地元だと包丁なんかでものを切ることを「生やす」と言う。
352 名前：デフォルトの名無しさん (ｱｳｱｳｳｰ Sa39-9B/I) mailto:sage [2022/07/19(火) 21:06:03 ID:G9MT/l77a.net]: >>343
branch に切るをくっつけ始めたやつはセンスない
なぜなら昔から枝を切るという表現はcutの意味で通っているから
英語に疎くて枝や支流のイメージがなかったのかもな
口火を切るや先陣を切るといった言葉にはそれがないので全く問題ない
もちろん既に慣用表現になっていしまった「ブランチを切る」を、慣用であるからという前提のもとに自分も使うという判断は全く問題ない（何度も言うが）
カードを切るという表現が生まれた当時の良し悪しについては昔すぎて情報不足で判断保留だが、カードを物理的に切るのはクレカ等を破棄するときくらいなので、どうあれ枝を切るほどには問題はなさそうだ
353 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 7d63-1dJg) mailto:sage [2022/07/19(火) 21:21:37 ID:k+9W9ROz0.net]: >>346
その「センスのないマヌケな表現」をずっと疑問もなく使っていたｱｳｱｳｳｰ Sa39-9B/I
>>325がなかったらその後もずっと使ってたんだろ
354 名前：デフォルトの名無しさん mailto:sage [2022/07/20(水) 00:27:05.54 ID:XYP10kdOa.net]: >>347
そういうこと、そんな笑い話よ
ギガが足りないとかも使ってるわけだしな
355 名前：デフォルトの名無しさん mailto:sage [2022/07/20(水) 00:45:04.12 ID:FXg55owT0.net]: >>348
ｱｳｱｳｳｰ Sa39-9B/Iはセンスのないマヌケということだな
違和感がないから疑問も持たずに使い続けてたんだろうし
それは「始めたやつ」も同じこと
356 名前：デフォルトの名無しさん [2022/07/20(水) 03:54:45.45 ID:5dyzzXol0.net]: カットじゃ意味が逆だろ。
って言ってるのでは？
357 名前：デフォルトの名無しさん mailto:sage [2022/07/20(水) 08:27:29.67 ID:VoqOzkUo0.net]: 切り出す
358 名前：デフォルトの名無しさん (ｱｳｱｳｳｰ Sa39-9B/I) mailto:sage [2022/07/20(水) 09:39:34 ID:MFp8tCyNa.net]: >>349
冷静なタイプかと思ってたけど感情的になってるねw
俺はbranchを切るという使い方をしたことないとうそぶいてたけど
こりゃ実はマヌケ呼ばわりされて激昂しちゃったクチみたいだな
359 名前：デフォルトの名無しさん mailto:sage [2022/07/20(水) 10:16:54.25 ID:9hcBX/tz0.net]: >>352
センスのないマヌケはｱｳｱｳｳｰ Sa39-9B/I自身という自虐的な笑い話だったんだろ？
だからたしかにｱｳｱｳｳｰ Sa39-9B/Iはセンスのないマヌケだよねと返しただけ
360 名前：デフォルトの名無しさん [2022/07/20(水) 10:17:11.93 ID:+8MBpHfAa.net]: まあまあ、どっちも熱くなるなよ
361 名前：デフォルトの名無しさん (ｱｳｱｳｳｰ Sa39-qysg) [2022/07/20(水) 15:44:08 ID:qJwz0nM8a.net]: チギリとムスビみたいなもんだな
362 名前：デフォルトの名無しさん mailto:sage [2022/07/20(水) 18:52:04.07 ID:+V617IkI0.net]: では幹に切り込みを入れて接ぎ木をするという視点はどうだろう
いやもうこの話題終わりにしよ
363 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 768f-jzc3) mailto:sage [2022/07/20(水) 22:38:43 ID:NFhlRrn/0.net]: でも他に話題ないじゃん
364 名前：デフォルトの名無しさん mailto:sage [2022/07/21(木) 10:22:39.59 ID:tyA/56lU0.net]: 新たなブランチを作るで良いのではｗ
365 名前：デフォルトの名無しさん [2022/07/21(木) 12:39:20.99 ID:eB2QSMypM.net]: >>348
別に自然だろ
「一千万不渡りの可能性」で通じるだろ
わざわざ一千万円の～なんて言わなくね
366 名前：デフォルトの名無しさん mailto:sage [2022/07/21(木) 14:17:01.81 ID:jIa0ANsba.net]: 一千万円という特定の額が足りないという例では全然ポイントが違うだろ
むしろこういう感じ
あたし食欲ヤバくて最近キロ余ってる
大きなセンチを私にください
週末にキロ出しすぎてオービス光らせた
367 名前：デフォルトの名無しさん (ｱｳｱｳｳｰ Sa39-9B/I) mailto:sage [2022/07/21(木) 14:24:33 ID:jIa0ANsba.net]: 一千万不渡りの可能性に相当するのは最近5キロ増えた
ギガが足りないに相当するのが最近キロ余ってる
368 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ fa6a-oBZo) mailto:sage [2022/07/21(木) 19:48:33 ID:jIDf2i6I0.net]: ギガが足りないの「ギガ」は使用可能量に相当する概念だとわかるが
キロ余ってるは何？体重がどう余ってるの？
369 名前：デフォルトの名無しさん mailto:sage [2022/07/21(木) 20:24:21.46 ID:CWmJBwj+a.net]: やれやれ重箱系の難癖だろそれ
3つの例文をそれぞれ否定できない時点で反論したいだけやろ
まあ余りについてあまり議論したくないから例文変えるけど「あたしキロがオーバーして最近ブスだからダイエットしなきゃ」ならどうよ
何にどうオーバーしてるんだとかこれ以上バカのフリはできまい
キロがオーバーしているというのは
体重がオーバーしていると理解できたんだよな
美容の文脈で体重オーバーといえば話者の理想体重に対して超過があるという意味だ
まだほかに難癖あるか？
370 名前：デフォルトの名無しさん mailto:sage [2022/07/21(木) 20:45:35.05 ID:CytvSZi3M.net]: スレから離れ過ぎるなら、他所で。と言いながら参戦するけど、
ブランチを切るの「切る」はチケットを切るの「切る」とは意味が違うぞ。
チケットを「切る」はチケットに挟みを入れて印をつける意味。
ブランチの「切る」は古くは「幕を切る」とか最近？だと「スタートを切る」のようなニュアンスから派生した「継続する物事を開始する」という意味。派生なので本来の「切る」の意味とは違うが広く受け入れられている表現だ。
誤解しやすいからその表現は良くないとうのも一つの見識だが、センスについては人それぞれなので、ここで議論しても結論は出ないぞ。
371 名前：デフォルトの名無しさん [2022/07/21(木) 21:37:43.28 ID:ppiq2d/La.net]: だからやめればいいのに
372 名前：デフォルトの名無しさん (ｱｳｱｳｳｰ Sa39-FvF9) mailto:sage [2022/07/21(木) 21:48:56 ID:QynlRk37a.net]: でも他に話題ないよね
373 名前：デフォルトの名無しさん mailto:sage [2022/07/22(金) 21:02:13.95 ID:gF+WA3uS0.net]: >>364
↑
会社にいるよな、
こういうめんどくさい奴
陰で、「またはじまった・・・」なんていわれてそうｗ
374 名前：デフォルトの名無しさん mailto:sage [2022/07/23(土) 01:38:51.04 ID:Zyeot+9K0.net]: きしめんやラザニア生地に切れ目入れて半分割いて
それを分枝の始まりとするイメージでいた
375 名前：デフォルトの名無しさん mailto:sage [2022/07/23(土) 12:52:10.26 ID:9p/E8wuyM.net]: Gitして～♪ハックする～♪濃いだから～♪
376 名前：デフォルトの名無しさん mailto:sage [2022/07/24(日) 09:33:41.33 ID:l8s7qzSF0.net]: mergeはリモート追跡ブランチからできるのに、pullとかfe
377 名前：tchはリモートブランチじゃないといけないのなんでですか？ []: [ここ壊れてます]
378 名前：デフォルトの名無しさん [2022/07/24(日) 10:05:38.48 ID:TkuAh24s0.net]: >>370
mergeはローカルから参照すればいいのに対して
pullやfetchはリモートを参照する必要があるからじゃね？
379 名前：デフォルトの名無しさん mailto:sage [2022/07/24(日) 11:58:45.92 ID:3IyHbLDx0.net]: >>370
pullやfetchはリモートブランチからローカルに情報取得するためのコマンドだからでは
380 名前：デフォルトの名無しさん (ﾌﾞｰｲﾓ MMeb-FvD6) mailto:sage [2022/07/24(日) 12:17:35 ID:JbQy+wjhM.net]: あれpullもfetchもいけなかったっけ？
381 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 695f-M5oM) mailto:sage [2022/07/24(日) 17:27:34 ID:4NkR89G20.net]: うるせー馬鹿野郎
382 名前：370 mailto:sage [2022/07/25(月) 04:35:51.61 ID:ZG4AfAc+0.net]: >>371-372
ありがとうございます理解できました
>>373
試してみましたがリモートのブランチを指定しないとだめみたいです

origin/dev と origin devは別物でしょうか？
前者をリモート追跡ブランチとして認識しておりますが
383 名前：375 mailto:sage [2022/07/25(月) 04:44:01.07 ID:ZG4AfAc+0.net]: 訂正です。
引数にorigin/devを指定するとダメで、origin devならOKということがあるので
origin/dev と origin devは別物であるような気はしています。
いくつかコマンドを実行してみて得られた結果から推理したイメージは
①リモートのdevブランチと最も近い位置にあるローカルのブランチがorigin/dev
②リモートのdevブランチを指すのがorigin dev
といった感じです。

git logをした時に確認できるorigin/devは①のorigin/devと同一であり、これがリモート追跡ブランチだ
という理解であっておりますでしょうか。
384 名前：デフォルトの名無しさん mailto:sage [2022/07/25(月) 09:09:50.38 ID:fKLif0xbM.net]: origin dev はローカルの dev ブランチが追跡している「リモート」のブランチ。
origin/dev はそれの「ローカル」コピー。コピーは最新ではない可能性がある。
という言い方をすると良いのかな。
385 名前：デフォルトの名無しさん mailto:sage [2022/07/25(月) 09:32:52.93 ID:fKLif0xbM.net]: 正確に言うと違うのでややこしいな。順番が逆というか。必ずしも origin じゃなくても良いとうか。
386 名前：デフォルトの名無しさん [2022/07/25(月) 10:07:23.18 ID:Jqw6JNcZM.net]: リモートリポジトリは、origin以外を使ってみたり、ファイルシステム経由でベアリポジトリを使ってみたりすると理解が深まるね。
インターネット接続不可能な環境だと結構使う。
387 名前：デフォルトの名無しさん mailto:sage [2022/07/25(月) 23:35:48.37 ID:ahGXQIib0.net]: >>375
別物っちゃ別物だけど。
gitのヘルプを読んだほうがいいよ。
端的に言えば、origin/devは通常、リモート追跡ブランチと言っていいもので、origin devはコマンドに付けた2つの引数。

mergeはローカルレポジトリにあるrefとマージするもの。
fetchやpull(pullはfetch+mergeだから、以下fetchのみ説明する)は、リモートレポジトリにあるrefを、ローカルレポジトリにコピー/ダウンロードしてくるもの。

refは"コミットを指す参照"のこと。
つまり、refはローカルブランチ、リモートブランチ、タグなどのこと。
よく言われるように、ブランチやタグは、コミットへのポインタであるから、refはコミットを指す参照と言った。
refは、各々のレポジトリにルートにある.git/refs/**が実体。(以下.git/を省略)

refはすべてレポジトリごとに保存されている。
git branchコマンドなどでローカルブランチを作ったり、fetchやpushでリモートブランチを作ることができる。
388 名前：デフォルトの名無しさん mailto:sage [2022/07/25(月) 23:37:25.77 ID:ahGXQIib0.net]: >>380
リモートブランチという名前だけど、特定のレポジトリ(例えばorigin)のrefを、ローカルレポジトリにコピーしたもの。
リモートレポジトリoriginからfetchをすると、originにあるrefs/**をダウンロードしてきて、ローカルファイルシステムに、refs/origin/**として保存する。

fetchをしなければ、最後にダウンロードしたときのままで、リモートレポジトリが他人によって更新されてても、refs/origin/**は自動には更新されない。

いつもrefs/を付けるのは面倒だから、これは省略できる。
ローカルブランチの実体.git/refs/heads/branchA
389 名前：は、branchAのみで通常呼ばれる。 リモートブランチの実体.git/refs/remotes/origin/branchBは、origin/branchBのみで通常呼ばれる。 []: [ここ壊れてます]
390 名前：デフォルトの名無しさん mailto:sage [2022/07/25(月) 23:38:28.96 ID:ahGXQIib0.net]: >>381
merge branchAは、merge refs/heads/branchAの省略形で、後者で書いてもマージできる。
refsであればマージできる。
上に書いたように、refsはリモートレポジトリからコピーしてきたもの(origin/...)と、自分で作ったref(ローカルブランチなど)のことだから、
merge branchAでも、merge origin/branchBでも正しい表現。
そのときそれらが指しているコミットとマージする。
391 名前：デフォルトの名無しさん mailto:sage [2022/07/25(月) 23:39:16.54 ID: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 名前：デフォルトの名無しさん mailto:sage [2022/07/25(月) 23:48:16.63 ID:ahGXQIib0.net]: >>383
誤記あったので訂正。
> fetch origin/devと書くことが
→ fetch origin origin/devと書くことが
以上。

ちなみにfetch origin/devは必ず失敗すると思います。
その位置にはrefではなくてリモートレポジトリ名を書くわけだが、origin/devってい名前は作らないと(多分作れない)思うので。試したことないけど。
393 名前：デフォルトの名無しさん mailto:sage [2022/07/25(月) 23:59:56.84 ID:ahGXQIib0.net]: refspec使った例で、自分がたまにやるやつを紹介して補足すると、
pushの例になるけど、
git push origin @~2:developとかは使うかな。
update update ...っていくつかコミットしたあとに、2つ前までのやつならちゃんと作れてるから、それをpushしておこうなんてときに。
fetch方向だとそういう工夫は必要ないと思うから、追跡してるとおりに取ってきちゃうけど。
394 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 13f2-geFY) mailto:sage [2022/07/26(火) 00:11:33 ID:BPsr0FTg0.net]: あと、上にorigin以外を...って話があるから、自分のユースケース紹介しておくと、
自分だけが使うようなコンフィグファイルの設定とかを、backupっていうリモートレポジトリの名前で、別のフォルダに向けておいて、
git push backup myconfig1とかやることあるかな。

この場合は、リモートブランチとしてbackup/myconfig1っていうのが作られるよ。
リモートレポジトリはoriginだけじゃなくてもよくて、
ローカルレポジトリに、backup/myconfig1はorigin/developと共存してる状態だよ。
ごめんね、自分語りが長くて。
395 名前：デフォルトの名無しさん (ﾃﾃﾝﾃﾝﾃﾝ MMeb-HyOX) mailto:sage [2022/07/26(火) 12:40:11 ID:iEhVjhlSM.net]: gitクライアントからボタン一つクリックするだけで完了するような操作を、いちいちターミナル立ち上げてタイプしてる人は何？
しかもタイピングが遅いからまどろっこしくて仕方ないw
396 名前：デフォルトの名無しさん mailto:sage [2022/07/26(火) 15:46:31.59 ID:LlJvHA5t0.net]: >>387
コマンドでgitを使う=タイピングが遅い
決め付けの激しい人だな
397 名前：デフォルトの名無しさん (ﾌﾞｰｲﾓ MM4d-W0Yq) mailto:sage [2022/07/26(火) 16:14:03 ID:FjX46+h7M.net]: そもそも普段からキーボード打つ方が、何十倍も早いだろ。煽るにしてもレベル低すぎ。
それともマウスでプログラム組んでるとか主張するんだろうか？
398 名前：デフォルトの名無しさん mailto:sage [2022/07/26(火) 17:29:56.27 ID:AlqtQl//0.net]: >>377
origin/devはgit logで表示されるorigin/devと同一という理解であっていますか？
であれば、git logをした際にdevブランチの方がorigin/devよりも上（新しい）に表示されることがあるので
必ずしもorigin devのローカルコピー版であるorigin/devは最新ではないという説明には納得がいきます。

>>381
冒頭に書いてあることは、リモートブランチもリモート追跡ブランチと同様に、ローカルリポジトリ上に存在するという理解でよいですか？
399 名前：デフォルトの名無しさん mailto:sage [2022/07/26(火) 17:53:40.65 ID:aK/PU7Z0M.net]: >>388
そうとは言ってないだろ
文書が読めるようになってからレスしろよ
400 名前：デフォルトの名無しさん mailto:sage [2022/07/26(火) 19:18:08.90 ID:cKNkMgD2r.net]: 「タイピングが遅い」っていうのは自分のことを指していってるんじゃないかなぁ
たぶんある種の自虐かと
401 名前：デフォルトの名無しさん mailto:sage [2022/07/26(火) 19:34:51.51 ID:wvY0b08ra.net]: いやよく読もう

> いちいちターミナル立ち上げてタイプしてる人は何？
> しかもタイピングが遅いからまどろっこしくて仕方ないw

タイピングが遅いはどう考えても一般論じゃないんだから、身近にそういう変わった人がいるという質問風の愚痴だろ
「ほーん、で？」「それは大変だったね」「しらんがな」とか答えてあげるかスルーすればいい案件
402 名前：デフォルトの名無しさん mailto:sage [2022/07/26(火) 19:38:48.45 ID:LlJvHA5t0.net]: 特定の誰かがタイピング遅いから全員gitコマンド使うなという主張だよ
403 名前：デフォルトの名無しさん mailto:sage [2022/07/26(火) 19:42:06.64 ID:wvY0b08ra.net]: 被害妄想じゃね
404 名前：デフォルトの名無しさん mailto:sage [2022/07/26(火) 19:43:23.18 ID:ZFH6mJGl0.net]: いちいちターミナルを立ち上げって書いてあるけど、普通ターミナルなんて立ち上げっぱなしだよなあ
405 名前：デフォルトの名無しさん mailto:sage [2022/07/26(火) 19:49:04.16 ID:wvY0b08ra.net]: 開いてあるターミナルでコマンド履歴を呼び出したり git switch - 打ったりはコマンドが早いな
エイリアスがあればさらに早い

そのタイピングが遅い人はgitの練習かタイピングの練習がしたいんじゃね
406 名前：デフォルトの名無しさん mailto:sage [2022/07/26(火) 19:56:26.38 ID: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 名前：デフォルトの名無しさん mailto:sage [2022/07/26(火) 19:59:34.56 ID:StEemcQzM.net]: >>398
話が長くてすまんが、要はorigin/devはなにかの省略形で、それは文脈によって決まるということです。
origin/devっていったら、普通はアレのこと、というのはありますが、一つの言葉に固執している様子を感じたので、原著に当たったほうがいいよというアドバイスになります。
408 名前：デフォルトの名無しさん mailto:sage [2022/07/26(火) 20:52:33.24 ID:AlqtQl//0.net]: >>399
ああ、そういうことですか。腑に落ちました。
仰るとおり、一つの言葉の意味を一つに定めようとしていました。
origin/devといっても脈絡次第でそれが何の略であるか、いくつか解釈パターンがあるんですね。

原著はgit-scm.com/docｓ/であってますか？
tagやcommit等を調べるときはこのページを利用しました。
このスレの皆さん、リモート追跡ブランチが何であるかを理解した時も原著を参照されたのですか？
書籍等でわかりやすく日本語でまとめられた情報等は購入されていないのでしょうか？
参考までに教えて頂けると助かります。本当は自分でわからないことをすべて調べられるのなら理想なのですが
まだその段階には至っていないようです。
409 名前：デフォルトの名無しさん mailto:sage [2022/07/26(火) 21:27:22.81 ID:BPsr0FTg0.net]: >>400
用語はそのurlからgitglossaryで検索すると見れます。
というか、コマンドラインからgit help gitglossaryで、使ってるバージョンのヘルプページが開きます。
この中を、remote-tracking branchをページ内検索す�
410 名前：黷ﾎリモート追跡ブランチの説明があります。 あと、git help gitで、使えるコマンドの大枠が見れます。 本については、10年以上前ですが自分はjunio c hamanoが書いた本で学びました。日本語です。その後3冊買いましたが、最初ので十分でした。 オンラインで無料で読めるやつならpro gitが一番読みやすいと思います。日本語訳があります。 ただしこれはツールとしての使い方が主です。 []: [ここ壊れてます]
411 名前：デフォルトの名無しさん mailto:sage [2022/07/26(火) 21:35:13.51 ID:BPsr0FTg0.net]: >>401
ProGit後半の方には内部実装に踏み込んだ説明もあるので、あなたの知りたいことは、こちら寄りかもしれません。
多くの人は、ツールを一般的なユースケースで使えればいいのであって、origin/devとorigin devはどう違うのか、といった疑問は感じないか、もしあってもすぐに忘れます。

origin/devとorigin devの違いだけを知りたい場合はすでに説明したとおりです。
でも更に疑問が出てくると思います。

あなたの疑問は、定義をしっかり知ったほうが理解につながるものだと思うので、地道にヘルプなどのドキュメントをたくさん読んで、自分の頭で探し方を学んだほうがいいものだと思います。
412 名前：デフォルトの名無しさん mailto:sage [2022/07/26(火) 23:28:02.96 ID:khPn0eWd0.net]: commitはメッセージが改行付きで長めになるのでGUIでやってるｗ
status,checkout,push,pull,mergeみたいなのはコマンドラインでやってるなぁ
413 名前：デフォルトの名無しさん mailto:sage [2022/07/27(水) 00:32:02.65 ID:t+HDDZmX0.net]: commitコマンド実行したときにエディタ立ち上がるようにしてないの？
414 名前：デフォルトの名無しさん mailto:sage [2022/07/27(水) 02:00:04.13 ID:CxAuph4lH.net]: 環境依存な話ですが、Macでターミナルからgit difftoolした時に外部diffビューアを立ち上げ
たいのですが、皆さんどうしてますか?

ググってopendiff (-> FileMerge)を呼ぶ設定にしてみたのですが、複数の変更ファイルが
あるとき、FileMergeが2番目以降のファイルを開いてくれません
415 名前：デフォルトの名無しさん mailto:sage [2022/07/28(木) 16:17:00.66 ID:Lt0nllDPM.net]: 呼び方が混乱してるのかも。通常の使い方だと、以下の通り。
origin dev 「リモートブランチ」、 origin という名前のリポジトリ上にある dev という名前のブランチ。
origin/dev 「リモート追跡ブランチ」、origin/dev という名前のローカルブランチ、上記のリモートブランチを追跡するように設定されている。
dev 「追跡ブランチ」、dev という名前のローカルブランチ、上記のリモート追跡ブランチ(origin/dev)が上流に設定されている。

（注:あくまでデフォルトなので変えることはできる…）
416 名前：デフォルトの名無しさん mailto:sage [2022/07/28(木) 16:29:18.98 ID:11jlioVlM.net]: ターミナルにコマンド入力してのがかっこいいと思ってる人いる？
417 名前：デフォルトの名無しさん mailto:sage [2022/07/28(木) 17:09:52.93 ID:9SWmz8k0d.net]: >>407==>>387
どんだけコマンド敵視してんだよ
418 名前：デフォルトの名無しさん mailto:sage [2022/07/28(木) 17:16:34.57 ID:DCbd1n5j0.net]: >>407は凄くかっこ悪い
419 名前：デフォルトの名無しさん mailto:sage [2022/07/28(木) 18:31:06.84 ID:kDNwoqB9a.net]: 煽り耐性なさすぎだろ…

ところで origin dev というフレーズに意味があると捉えてるのいいのかな
単に<repository>と<refspec>を順に受け取るコマンドが多いだけで、origin dev と oringin/dev を同格の概念だと捉えるのは理解を妨げると思うんだが
420 名前：デフォルトの名無しさん mailto:sage [2022/07/28(木) 19:32:20.12 ID:Lt0nllDPM.net]: >>410
厳密に言えば違うけど、どっちもブランチを指定しているという意味では同格だろ。
ローカルブランチと、リモートブランチを取るコマンドで引数の指定方法が異なると理解しとけば良い。
421 名前：デフォルトの名無しさん mailto:sage [2022/07/28(木) 20:04:25.84 ID:onozgSw3a.net]: 我流で変な理解をするよりも、上で丁寧にわかりやすく説明してくれてくれてる人が言うようにちゃんとヘルプ見たほうがいいと思うけどね
中級者と本当に詳しい人の差はそこで出ると思う
refspecとは何か、tree-ishとは何かを説明できるかどうかはポイントの一つだと思う
422 名前：デフォルトの名無しさん mailto:sage [2022/07/28(木) 21:31:34.95 ID:cm ]: [ここ壊れてます]
423 名前：Nt05vA0.net mailto: 未だにSVNなんか使ってgit使ってないのはやばいなんて言う方がやばいなんて話題になってたんだけどgitに慣れた身からすると
ローカルでコミットできない、ブランチを気軽に切れない、もうそれだけであまりに不便だと思うんだけど、SVNユーザーはこれをデメリットと感じないのだろうか？ []: [ここ壊れてます]
424 名前：デフォルトの名無しさん mailto:sage [2022/07/28(木) 22:20:18.72 ID:+DkG6hq80.net]: gitのことを知らないんだからsvnのデメリットにも気付かないよ
425 名前：デフォルトの名無しさん mailto:sage [2022/07/28(木) 22:40:17.73 ID:pS32MLV5d.net]: ドカタ開発はもっと理不尽なことがいくらでもあるからその程度は大した問題じゃないんだよ
VCS使ってるだけマシ
426 名前：デフォルトの名無しさん mailto:sage [2022/07/29(金) 01:55:35.40 ID:eL4dVDXxM.net]: >>408
なんで敵視？
427 名前：デフォルトの名無しさん mailto:sage [2022/07/29(金) 02:26:57.20 ID:g45EDnWs0.net]: デメリットなんて気付くわけないさね
スマホを使ったことがない人はガラケーの劣る点に悩まないし、自動車がなかった時代に初の自動車を見てもこのヘンテコなカラクリ仕掛けが世界を変えるとは考えられない
保守的な人やいつも忙殺されて余裕のない人は損失回避バイアスによって変化のリスクを過大に見積もり現状維持を選ぶし
いよいよ心が老人になると自分の慣習や価値観を否定されたと感じて怒り出す始末
428 名前：デフォルトの名無しさん [2022/07/29(金) 06:43:18.42 ID:KqiKNtRU0.net]: >>413
その2点に慣れてしまうともう戻れないよな
コーディング方法さえ変えてしまうほど便利
429 名前：デフォルトの名無しさん [2022/07/29(金) 10:26:37.17 ID:nIcw6oQba.net]: >>396
++
tmux最強
430 名前：デフォルトの名無しさん [2022/07/29(金) 10:28:01.90 ID:nIcw6oQba.net]: >>393-394
判りやすい
431 名前：デフォルトの名無しさん mailto:sage [2022/07/29(金) 11:55:40.15 ID:UFMUx9C4M.net]: CVS使ってた現場で、コミット漏れによる先祖返りで障害が起きた対策として、下記の作業手順が定められた
1. 一切コミットすることなくソースの変更とテストとレビューを済ませる
2. 本番からソースをダウンロードし、ワーキングセットとの差分を取る
3. ワーキングセットを本番にデプロイする
4. CVSにコミットする
もはやバージョン管理とは何なのかと思ったね
432 名前：デフォルトの名無しさん mailto:sage [2022/07/29(金) 12:45:43.04 ID:kJOM8zsPM.net]: >>421
ローカルとかチームではgit使って、サーバーだけcvsにした方が良さそうだな。
433 名前：421 (ﾌﾞｰｲﾓ MM9d-vZl0) mailto:sage [2022/07/29(金) 13:13:28 ID:UFMUx9C4M.net]: あーちょっと不正確だった。正しくは、1の前に
0. 本番からソースをダウンロードし、CVSとの差分がないことを確認する
が入る。簡単に言えばVCSを一切当てにしないで本番環境にあるソースをマスターにしましょうってことだ。
こんなのCVSかGitかとかいう以前の問題で、ルール決める人間がVCSを理解してないんだからツールを何使おうが絶対に間違えるんだよ。
仮にGit使ってたとしても同じことになってるだろうね。
434 名前：デフォルトの名無しさん [2022/07/30(土) 04:13:51.24 ID:5b4tKXes0.net]: >>421
cvsがただのソース置き場になってるな
zip管理してるのと変わらん

それで回るのなら、cvsやめてzip管理でええやん
435 名前：デフォルトの名無しさん mailto:sage [2022/07/31(日) 02:06:31.57 ID:usagdBtl0.net]: 例えばgoogle trendで検索すると日本はgitに対するsvnの比率が世界最上位クラスに高いのが分かる
より良い技術を取り入れていこう勉強していこうってタイプの人が全然いないのかな
そんなものより動く製品作るのが大事だろ、知ってる技術使えばいい�
436 名前：ｾろ、勉強する時間が無駄みたいな []: [ここ壊れてます]
437 名前：デフォルトの名無しさん mailto:sage [2022/07/31(日) 02:15:39.82 ID:umZ4cEVU0.net]: >>425
すまん俺が svn 糞とかでググってるせいだわ
438 名前：デフォルトの名無しさん mailto:sage [2022/07/31(日) 02:22:27.63 ID:usagdBtl0.net]: >>421
cvsじゃなくてtfvcだけどまさにそんな感じ
ブランチが開発差分じゃなくて、各モジュールを表すものになってるんだよねうち。メインに共通部品が置いてあるのよ
じゃぁこのブランチで開発してね他の人はいじらないから、みたいなこと最初に言われたとき、お前バージョン管理をなんだと思ってるんだってなったわ
>>424の言う通りだし、そもそも「バージョン管理」って概念自体がよく分かってない人結構いるのかもしれない
439 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ d68f-mUOZ) mailto:sage [2022/07/31(日) 05:29:08 ID:Q1ZzrLT30.net]: >>425
svnを敵視する人はこれだから困る
440 名前：デフォルトの名無しさん mailto:sage [2022/07/31(日) 15:16:33.83 ID:5HP0foYyM.net]: >>427
テンプレートからフォークしていく運用自体はそんなに珍奇ではないと思うよ
TFVCはよく知らないけどGitほど複数リポジトリに跨った管理が得意とは思えないから、
フォークの際にGitでクローンする代わりにブランチを使うのはまあアリなんじゃないか
441 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 4110-YjMm) mailto:sage [2022/08/01(月) 09:23:36 ID:x4rTNfSD0.net]: Hamano氏のインタビューが載ってる　https://git.github.io/rev_news/2022/07/31/edition-89/
442 名前：デフォルトの名無しさん mailto:sage [2022/08/06(土) 16:17:32.37 ID:PoK0MHTD0.net]: おまえらってgitを使ってなにを管理してんの？
どうせ人には見せれない、クソコードをprivateにして遊んでるだけだよなｗ
443 名前：デフォルトの名無しさん mailto:sage [2022/08/06(土) 16:19:29.02 ID:PxmA7nyT0.net]: 確かに見せられないな、機密情報だから
ごめんねー
444 名前：デフォルトの名無しさん mailto:sage [2022/08/06(土) 22:54:01.88 ID:PoK0MHTD0.net]: 恥ずかしくてみせないよな
ｗｗｗｗｗ
445 名前：デフォルトの名無しさん [2022/08/06(土) 22:55:49.69 ID:Kw1pprEh0.net]: そんなにみたいなら見せてやるよ
最新作だ
https://github.com/NCNT/TimingCmds_in_POSIX/tree/main/c_src
446 名前：デフォルトの名無しさん mailto:sage [2022/08/07(日) 06:13:33.06 ID:xRSduvLwr.net]: 相変わらずのダサいコードで笑う
447 名前：デフォルトの名無しさん mailto:sage [2022/08/07(日) 10:36:56.12 ID:JIUI9FIi0.net]: >>434
なにこれ？
この程度ものを管理する必要があるのか？
しかも公開してｗｗｗｗ

やっぱり、偉そうにいうわりにはクソみたいなソフトしか作れないんんだろ
448 名前：デフォルトの名無しさん [2022/08/07(日) 13:36:16.69 ID:Rb+FepPS0.net]: >>436
コミケで販売するから文句はそれ買ってから言え。通販もしてるぞ。

あなたのシェルスクリプトに正確な「時」をデリバリー
トキデリ Rich Mikan 著
https://richlab.org/coterie/tok.html
449 名前：デフォルトの名無しさん mailto:sage [2022/08/08(月) 13:17:15.57 ID:AVRRjrX2r.net]: 資源の無駄
450 名前：デフォルトの名無しさん [2022/08/08(月) 13:28:32.63 ID:CyzYFgqfa.net]: githubの話はgitスレでしないでくたさーい
451 名前：デフォルトの名無しさん mailto:sage [2022/08/09(火) 23:25:41.25 ID:3+5sY31X0.net]: githubとgitは別物だぞ
452 名前：デフォルトの名無しさん mailto:sage [2022/08/10(水) 01:11:45.77 ID:81VFPbKx0.net]: >>440
gitを使ったシステムなんだから別物ではない
453 名前：デフォルトの名無しさん mailto:sage [2022/08/10(水) 01:28:37.91 ID:S6X0Gjf0a.net]: え？
454 名前：デフォルトの名無しさん mailto:sage [2022/08/10(水) 02:07:21.61 ID:ek7aVcHb0.net]: DNAと人間は同じだから
455 名前：デフォルトの名無しさん mailto:sage [2022/08/10(水) 02:47:33.52 ID:RODVWlnt0.net]: repoってgithubとかgitlabみたいなもん？
456 名前：デフォルトの名無しさん [2022/08/10(水) 07:15:46.58 ID:g2r8Vobb0.net]: >>444
ホスティングサービスではなくて、gitを補佐するクライアントソフトらしい
457 名前： 複数のリポジトリを一括で操作できるのが特徴とか ライブラリが多いとか、扱うリポジトリが多いプロジェクトなんかだと重宝するかも 個人的にはいらんなぁ []: [ここ壊れてます]
458 名前：デフォルトの名無しさん (ｱｳｱｳｳｰ Sa55-2+m5) mailto:sage [[ここ壊れてます] .net]: 自分も会社の業務以外でほとんど使用したことはないな
そもそも個人レベルのプロジェクトで複数のリポジトリ扱うことないし

Android SDKのソース落としてくる時に使ったぐらい
459 名前：デフォルトの名無しさん mailto:age [2022/08/13(土) 07:41:00.55 ID:TsW0bL7n0.net]: Git v2.37.2
460 名前：デフォルトの名無しさん mailto:sage [2022/08/13(土) 19:37:20.99 ID:HRISK7Hh0.net]: 個人レベルでgitを使う必要ある？
そもそも自分ひとりで書いてるなら大抵は覚えてるだろｗ
461 名前：デフォルトの名無しさん mailto:sage [2022/08/13(土) 20:04:36.06 ID:WN46//k40.net]: 個人レベルだからこそ簡単に導入出来るgitを使う
別にリモートにpushやらしなくても所々コミットしておけば戻るのも簡単だし
便利だと思うのだけどね
ただバイナリ（excelのファイル)みたいなのには使わないが
462 名前：デフォルトの名無しさん mailto:sage [2022/08/14(日) 02:14:02.08 ID:XCwSZ99k0.net]: 新機能を実装する時は、変更前のソースを参照できるようにしておかないと面倒。

バグが発生したときは差分をすぐに参照できるようにしたいしな。
463 名前：デフォルトの名無しさん mailto:sage [2022/08/14(日) 02:16:52.49 ID:TBJygn0f0.net]: >>448
ローカルリポジトリだけでも完結できるのにgitをわざわざ忌避する理由がない
464 名前：デフォルトの名無しさん [2022/08/14(日) 13:58:00.56 ID:eEFpmmgP0.net]: >>448
数万行のコードなんて覚えてられない
どうせおまえがやってるのは100行以下のサンプルコードだけだろｗ
465 名前：デフォルトの名無しさん mailto:sage [2022/08/14(日) 15:10:31.19 ID:hteYaGpv0.net]: >>452
どうせ公開できないんだろｗ
何とでもいえるわなｗｗｗ
俺なんてカーネル開発してるよ
466 名前：デフォルトの名無しさん [2022/08/14(日) 15:48:56.36 ID:eEFpmmgP0.net]: >>453
たった数万行に驚いてるのか？
467 名前：デフォルトの名無しさん [2022/08/14(日) 16:47:19.54 ID:psUND9lqa.net]: そもそも描いたこと無いからイキれるんだな
468 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 31ab-5Ix7) mailto:sage [[ここ壊れてます] .net]: 一日100行でも一年経てば20000行
469 名前：デフォルトの名無しさん mailto:sage [2022/08/15(月) 20:10:11.85 ID:KNym4Y6d0.net]: svn脳の人はローカルリポジトリの概念がないからvcs使うことを大層に考えてしまうんだよな
470 名前：デフォルトの名無しさん mailto:sage [2022/08/15(月) 20:22:20.12 ID:1icmhpVn0.net]: リモートリポジトリが要らないというのは革命的だと個人的には思うけど、あんまりそういう話は出てこないよね。

リモートリポジトリ無しってgit登場時点で普通の話だったっけ？
471 名前：デフォルトの名無しさん mailto:sage [2022/08/15(月) 21:27:50.09 ID:dRxXQoxWM.net]: リポジトリーのローカルコピーも含めてGitの機能的な部分はBitKeeperから持ち込まれたものだろ
472 名前：デフォルトの名無しさん mailto:sage [2022/08/15(月) 22:34:37.88 ID:vxI8O7UY0.net]: >>458
SCCSとかRCSとか。
473 名前：デフォルトの名無しさん mailto:sage [2022/08/15(月) 23:18:53.39 ID:f21eh4iaM.net]: Gitの開発経緯を考えるとリモートリポジトリの存在はむしろ超大前提で、ローカルだけで使えるのは副産物みたいなもんでしょ
まあリモートと言ってもGithubみたいな中央集権型ではなくて、無数のリモートリポジトリがあってパッチを送り合うような開発スタイルが本来のGitの姿
474 名前：デフォルトの名無しさん mailto:sage [2022/08/16(火) 01:17:15.07 ID:yNxxslbt0.net]: https://ezoeryou.github.io/blog/article/2015-04-08-linus-git-interview.html
gitの10周年を記念したLinus Torvalsへのインタビューの翻訳

＞しかし、BitKeeperがやってきてからというもの、ソース管理に対する見方が変わったね。
＞ BitKeeperは大抵のことを正しく行っていた。
＞レポジトリのローカルコピーがあることと、分散マージはでかかった。
475 名前：デフォルトの名無しさん [2022/08/16(火) 23:52:04.96 ID:zXGOFEoi0.net]: >>448
gitに�
476 名前：ﾀらんけど、VCSって個人レベルでも機能追加とバグ修正並行して進める時は楽だ []: [ここ壊れてます]
477 名前：デフォルトの名無しさん [2022/08/18(木) 11:54:41.84 ID:p/limWqpa.net]: gitとgithubの区別がついてないんだろ
478 名前：デフォルトの名無しさん mailto:sage [2022/08/25(木) 00:47:44.66 ID: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 名前：デフォルトの名無しさん mailto:sage [2022/08/25(木) 02:38:58.44 ID:W0zamWK80.net]: 「git checkout ブランチ」するとき、

checkout前のブランチにおけるワークツリー上でのファイルの編集や削除は、
checkout前のブランチにコミットされているそのファイルとcheckout後のブランチにコミットされているそのファイルが等しい場合、
checkout後のブランチにそのまま引き継がれる

つまりIam.txtが変更されているのは正しいが、whoyou.txtが復活するのは何か操作を勘違いしていると思う

ちなみに、
checkout前のブランチとcheckout後のブランチにコミットされているファイルが等しく無い場合、
checkoutすることでcheckout後のブランチにコミットされているファイルへ置き換わるが、
checkout前のブランチにおいてワークツリー上でそのファイルを編集や削除していると、
checkoutが失敗する
480 名前：デフォルトの名無しさん mailto:sage [2022/08/25(木) 02:40:02.58 ID: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/) mailto:sage [[ここ壊れてます] .net]: >>466-467
whoyou.txtが復活するのは勘違いしていたみたいすまん
「checkout前のブランチにおけるワークツリー上でのファイルの編集や削除は、
checkout前のブランチにコミットされているそのファイルとcheckout後のブランチにコミットされているそのファイルが等しい場合、
checkout後のブランチにそのまま引き継がれる」
こんな仕様があったのか。知らなかった。ありがとう。

ワークツリー上で行った操作をなかったことにしたい場合「git checkout .」で良いと思うんだけど
ワークツリー上で行ったgit操作履歴（というかローカルリポジトリへのコミット内容との差分）を確認する方法ってないのかな
482 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 9fe4-hHkJ) mailto:sage [[ここ壊れてます] .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) mailto:sage [[ここ壊れてます] .net]: git status -v
とかじゃダメなのか？
484 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 9fe4-hHkJ) mailto:sage [[ここ壊れてます] .net]: git status -vは-v無しと同じかな？
毎回git statusやると表示がうっとおしいので、git status -sbの方をシェル関数でgstに定義して良く使ってる
git status -vはmergeやrebaseが失敗したときに見る
485 名前：デフォルトの名無しさん mailto:sage [2022/08/26(金) 18:45:49.38 ID:8mS1vdmvM.net]: たかだかpushするだけなのに、ターミナルからやった方がエモいですか？
486 名前：デフォルトの名無しさん mailto:age [2022/08/26(金) 19:07:22.83 ID:m09WXDX9a.net]: エモいと言う言葉の意味がわからない
487 名前：デフォルトの名無しさん mailto:sage [2022/08/26(金) 19:30:50.57 ID:WwYTVpIB0.net]: >>472=>>407
488 名前：デフォルトの名無しさん [2022/08/27(土) 07:34:04.59 ID:cMY+Cqk70.net]: エモいかどうかは知らんけど、
489 名前：ターミナルの方が便利 []: [ここ壊れてます]
490 名前：デフォルトの名無しさん mailto:sage [2022/08/30(火) 12:28:50.29 ID:CdxrcFTpM.net]: 興味本位でインストールしたけど、そもそも履歴を管理しなきゃいけないようなものが、個人にはないこと気づいてほったらかしwww
491 名前：デフォルトの名無しさん [2022/08/30(火) 23:04:23.35 ID:F66FctjD0.net]: まあ、プログラマーくらいしか使わんかも
事務の人とか使ってるんかな？
492 名前：デフォルトの名無しさん [2022/08/31(水) 08:44:21.38 ID:hYROypry0.net]: ファイル名で管理していて最新版がどれかわからんっていうネタはよく見るけど、最新版を追うためだけにVCSを導入するところは少ないでしょ
493 名前：デフォルトの名無しさん mailto:age [2022/08/31(水) 08:46:09.80 ID:kba1lHfP0.net]: Git v2.37.3
494 名前：デフォルトの名無しさん mailto:sage [2022/08/31(水) 12:34:16.47 ID:nUvaW37BM.net]: >>478

最新はタイムスタンプ見れば一目瞭然だろ
パソコン初心者かよw
495 名前：デフォルトの名無しさん [2022/08/31(水) 15:08:11.70 ID:83s/Qhp/a.net]: タイムスタンプω
パソコン初心者かよωωω=2πf
496 名前：デフォルトの名無しさん mailto:sage [2022/08/31(水) 15:34:18.76 ID:t/W0dlco0.net]: gitがメジャーになったおかげで、ソースコードのタイムスタンプにゴチャゴチャ文句付けるオジサンを駆逐できて良かった
497 名前：デフォルトの名無しさん [2022/08/31(水) 16:40:45.15 ID:hYROypry0.net]: あと、扱うファイル形式的にも難しそう

>>482
どういうこと？昔はタイムスタンプで何か言ってくる人がいたの？
498 名前：デフォルトの名無しさん mailto:sage [2022/09/01(木) 01:20:40.38 ID:v92yFclD0.net]: >>481
涙拭けよ
499 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 5dc2-nKCz) mailto:sage [[ここ壊れてます] .net]: タイムスタンプみたいな信用できないものに依存するなよ
500 名前：デフォルトの名無しさん [2022/09/03(土) 12:08:05.86 ID:gEPymsC80.net]: https://github.com/zhlynn/zsign
これをビルドするのにMSYS2を入れて、git clone git@github.com:witwall/mman-win32とやったら、git@github.com: Permission denied (publickey).になっちゃったんですけど、githubのアカウントがないとダメなんでしょうか？
501 名前：デフォルトの名無しさん [2022/09/03(土) 12:50:36.25 ID:91ZlUxrsa.net]: git clone github.com:witwall/mman-win32
502 名前：デフォルトの名無しさん mailto:sage [2022/09/03(土) 12:56:48.05 ID:ZbfA6K7G0.net]: >>486
SSH接続はアカウント作って鍵を登録する必要がある
git@github.com: → https://github.com/
に読み替えてhttpsでやればいい
503 名前：デフォルトの名無しさん mailto:sage [2022/09/03(土) 15:32:09.11 ID:gEPymsC80.net]: >>488
ありがとう
504 名前：デフォルトの名無しさん mailto:sage [2022/09/04(日) 18:01:40.46 ID:F3wqdiHv0.net]: 情報系卒ではじめて業務でgit触ったんだけど、これbranch newFunc -u みたいな感じで
origin/newFuncみたいなの脳死で追跡するように設定しちゃってもいい？
このコマンド一度打っておけば。そのブランチにpushするときいちいちoriginって入れなくてもよくなる
くらいの認識でしかないんだけども
505 名前：デフォルトの名無しさん mailto:sage [2022/09/04(日) 18:03:08.45 ID:F3wqdiHv0.net]: 日本語下手すぎたから書き直します
情報系卒の1年目で、最近はじめて業務でgit触ったんだけど、これ「git branch newFunc -u」で
origin/newFuncをup-streamに設定しちゃってもいい？
このコマンド一度打っておけば、そのブランチにpushするときいちいちoriginって入れなくてもよくなる（originが省略できる）
くらいの認識でしかないんだけども
506 名前：デフォルトの名無しさん mailto:sage [2022/09/04(日) 18:09:17.04 ID:ZgLwpFsc0.net]: いいよ
間違ったとこにpushすることを防げる
507 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 7fdb-Cgcv) mailto:sage [[ここ壊れてます] .net]: おとなしくGUI使えよ

タイプするのが面倒で、間違ってpushなんてしてるようならｗｗｗ
508 名前：デフォルトの名無しさん mailto:sage [2022/09/05(月) 01:29:30.11 ID:+fm9JKxR0.net]: >>493
push先を間違うのは頭の中の段階なので何UIでも関係ないです
509 名前：デフォルトの名無しさん mailto:sage [2022/09/05(月) 01:33:50.45 ID:CQl5AJDr0.net]: >>494
論破しましたね
510 名前：デフォルトの名無しさん mailto:sage [2022/09/05(月) 12:14:03.67 ID:s3GaDdDqM.net]: 論破ww
久々に聞いた、平成かよw
511 名前：デフォルトの名無しさん mailto:sage [2022/09/05(月) 14:19:44.96 ID:vU9z3P6x0.net]: ﾃﾃﾝﾃﾝﾃﾝがこうも粘着してgitのコマンド入力に憎しみを向けるの�
512 名前：煢ﾟ去に完全論破されたのがよっぽど悔しかったんだろうな []: [ここ壊れてます]
513 名前：デフォルトの名無しさん mailto:sage [2022/09/05(月) 16:50:12.49 ID:dKgf+YLO0.net]: ローカルブランチのソースコード中の
コメントアウトしてある説明とかの修整って
気付いたときに、いちいちコミットしてる？
それともstashとかにまとめといて後で一気にやる？
514 名前：デフォルトの名無しさん mailto:sage [2022/09/05(月) 18:08:18.48 ID:pTpxX+Uo0.net]: 別にこまめに修正してコミットしても良いのでは？
何かルールでもあるの？
515 名前：デフォルトの名無しさん mailto:sage [2022/09/05(月) 19:17:05.40 ID:dKgf+YLO0.net]: >>499
ルールは無いよ
ただどうでもいいとこで無用にログが膨らむけど
皆は普段どうしてんだろ？って思って書いてみた
516 名前：デフォルトの名無しさん mailto:sage [2022/09/05(月) 20:13:32.62 ID:CQl5AJDr0.net]: 気が向いたらコミットしといてpushする前にsquashで複数コミットを1個にまとめる
517 名前：デフォルトの名無しさん mailto:sage [2022/09/05(月) 23:32:13.90 ID:vU9z3P6x0.net]: 気楽に思いつくままコミットして、ゴチャつきが気になったら後で rebase -i で美化運動する
518 名前：デフォルトの名無しさん [2022/09/10(土) 14:36:31.13 ID:4Ftb5IZI0.net]: >>491
originしかないような状況ならまず困らないからOK
2つ以上のリモートリポジトリにpush/pullしたくなったら、ユースケースでデフォルトに設定するかその都度考えて打った方がいいか考えればok
519 名前：デフォルトの名無しさん [2022/09/10(土) 17:37:58.38 ID: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 名前：デフォルトの名無しさん mailto:sage [2022/09/10(土) 17:55:34.66 ID:2MbFO6mH0.net]: >error: failed to encode 'resource.rc' from UTF-8 to UTF-16LE-BOM
これが理由じゃないの？

そもそも、UTF-16LE-BOM を使う事ってある？

普通は、BOM 無しUTF-8 を使う
521 名前：デフォルトの名無しさん mailto:sage [2022/09/10(土) 18:08:59.50 ID:EVlNSVx0M.net]: >>505
Visual Studioを使ってるのでUTF-16LE-BOMかShiftjisの二択なのです
resource.rcはUTF-16LE-BOMで保存してあります
522 名前：デフォルトの名無しさん mailto:sage [2022/09/10(土) 18:17:08.28 ID:kN9l3Zj10.net]: >>505
使う理由があって使ってんのに難癖はやめとけ
523 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ a561-Z99o) mailto:sage [[ここ壊れてます] .net]: >>504
リモートとのやり取り時に指定文字コードとUTF-8を相互変換するんだから.rcファイルpushし直さないとだめじゃね？
524 名前：デフォルトの名無しさん mailto:sage [2022/09/10(土) 20:18:35.22 ID:RL5Ydm0F0.net]: 素直に文字コード変換ソフト使ってからpushしたほうがイイんじゃね？
文字コードの問題は結構根深いとこあるし
525 名前：デフォルトの名無しさん mailto:sage [2022/09/10(土) 20:23:42.76 ID:1BX46xrY0.net]: 情報学部卒IT企業勤務1年目だけどGit難しいよ
よくみんな使いこなせるな
ブランチ切り替えとか発生した瞬間に混乱するわ
526 名前：デフォルトの名無しさん mailto:sage [2022/09/10(土) 20:25:06.14 ID:1BX46xrY0.net]: とあるブランチで開発を進めていて、pushまで完了していつでもブランチ切り替えできる状態ではあるけど
新しくブランチ切ったからそこで作業してと言われた瞬間パニックになる　ブランチ切り替えすると作業フォルダの中身変わるの緊張するわ
527 名前：デフォルトの名無しさん mailto:sage [2022/09/10(土) 20:40:06.16 ID:amn8zzJ5M.net]: 慣れないうちはコミットログやブランチ同士の関係をグラフ表示できるGitクライアントに頼ったほうがいいよ
ミスっても所詮は手元だけだから、適宜リモートにプッシュしてさえいれば操作は大胆にやればいい
ただしプッシュ前のチェックだけは入念に
528 名前：デフォルトの名無しさん mailto:sage [2022/09/10(土) 21:23:42.21 ID:EVlNSVx0M.net]: >>508
リモートの.editorconfigと.gitattributesでUTF-16LE-BOMを指定してるので
.rcファイルもUTF-16LE-BOMで上がっているんじゃないのかな
cloneした.rcファイルはUTF-16LE-BOMになってます

>>510
よくわからないエラーで悩むよ
529 名前：デフォルトの名無しさん mailto:sage [2022/09/11(日) 01:22:10.61 ID:TANQ1xvy0.net]: そもそもutf-16 leを推奨しているMicrosoftがおかしいからな(直す気もないらしい)

>>504
多分もう色々調べてると思うけど、もし見てなかったら参考に

https://developercommunity.visualstudio.com/t/git-failed-to-encode-from-utf-16-le-bom-to-utf-8-w/920369

https://qiita.com/syoyo/items/37a917aa5932f626d5cc
530 名前：デフォルトの名無しさん mailto:sage [2022/09/11(日) 06:37:15.30 ID: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 名前：デフォルトの名無しさん [2022/09/11(日) 08:17:11.62 ID:p8irpA6n0.net]: >>510
頭が良い悪いは関係なくて、単に慣れの問題だと思うよ
心配しなくても、そのうち慣れる
532 名前：デフォルトの名無しさん mailto:sage [2022/09/11(日) 12:15:22.07 ID:EZu34myO0.net]: ある程度の難しさがあるのは確かだと思うので地図を読むことの得手不得手みたいな適性は何かしらあるかもしれない
533 名前：デフォルトの名無しさん mailto:sage [2022/09/11(日) 12:17:08.26 ID:EZu34myO0.net]: けどブランチ切り替えくらいなら慣れだな
分散開発で計画やマージを任せられるとなると人によって難しい
534 名前：デフォルトの名無しさん mailto:sage [2022/09/15(木) 14:34:12.65 ID:cRBlrBBnF.net]: githubの質問ってここで良いのかな？
フォーク基のリポジトリをPublicからPrivateに変更したら、Publicの時にフォークしたユーザーのリポジトリに影響って出る？
535 名前：デフォルトの名無しさん [2022/09/15(木) 23:28:16.29 ID:GwVm0Djk0.net]: >>519
こっちでお願いします

ｿｰｽｺｰﾄﾞﾎｽﾃｨﾝｸﾞ総合【GitHub,GitLab,Bitbucket等】
https://mevius.5ch.net/test/read.cgi/tech/1531824290/
536 名前：デフォルトの名無しさん mailto:age [2022/09/16(金) 13:09:50.05 ID:QQvhz5cq0.net]: Git v2.38.0-rc0
537 名前：デフォルトの名無しさん mailto:age [2022/09/23(金) 16:47:47.90 ID:UblpnXcK0.net]: Git v2.38.0-rc1
538 名前：デフォルトの名無しさん mailto:sage [2022/09/27(火) 03:57:55.82 ID: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 名前：デフォルトの名無しさん mailto:sage [2022/09/27(火) 07:59:31.26 ID:UwDioOcC0.net]: bare repositoryになってないとかmaster,developへの直接push不可になってるとか
540 名前：デフォルトの名無しさん mailto:sage [2022/09/27(火) 09:48:59.09 ID:+d371Z/C0.net]: 【Git】bare リポジトリで無いならば、push を受け入れないことを知りました
https://oki2a24.com/2016/10/11/do-not-recive-push-unless-bare-repository/

学習のためだけならreceive.denyCurrentBranchを設定してもいいかもね
541 名前：デフォルトの名無しさん mailto:sage [2022/09/27(火) 10:14:08.47 ID:c2KUidKp0.net]: 不可解な挙動で学習時間や意欲をロスしないためにも普通の構成にしたほうがいいと思う
俺ならserver(bare)とclient1とclient2を作る
542 名前：デフォルトの名無しさん mailto:sage [2022/09/27(火) 11:33:58.99 ID:vJTIC1iI0.net]: そもそもどこからcloneして
543 名前：きたのか不明だし、こういう質問する奴って情報が不足し過ぎてるような githubとかにあるようなのをcloneしてpushして失敗しましたとかなら草だがｗ []: [ここ壊れてます]
544 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 7fe4-Nf8B) mailto:sage [[ここ壊れてます] .net]: 別にどこからcloneしてきたとか関係ないよ
デフォルト設定だとbareでないレポジトリへpushできないことがあるのは仕様
bareにするとかdenyCurrentBranchは危ないよとかググれば日本語の情報もいっぱいある
545 名前：デフォルトの名無しさん mailto:age [2022/09/28(水) 09:04:02.38 ID:+1FeoF9d0.net]: Git v2.38.0-rc2
546 名前：デフォルトの名無しさん mailto:sage [2022/09/28(水) 11:25:13.07 ID:bhRVKQK10.net]: server側をベアで作り直したらうまくいきました
ありがとうございます

なぜ入門書はここら辺を説明してくれずに
まずGitHubのアカウントを作ります。とか言い出してしまうのか
547 名前：デフォルトの名無しさん mailto:sage [2022/09/28(水) 11:44:27.73 ID:MP/YhhuJ0.net]: 選び方が悪いね
そういう方向性の入門書ならプロジェクトリーダー濱野氏の入門Gitだ
5章「2か所で使う」でバックアップリポジトリをbareで作って云々を解説してる
githubには一切触れていない(と思う)
git clone /pub/repositories/～みたいなローカルマシン内でのcloneを解説してる本は他にあるのかな
548 名前：デフォルトの名無しさん [2022/10/01(土) 10:02:20.72 ID:DVLayUHe0.net]: Gitをインストールした記憶がないのに、なぜかインストール済みでした。
Git Bashを起動すると、プロンプトが変だし、フォントが小さいし、色付けもされません。
プロンプトは「~>」です。

これはどういうことでしょうか？
549 名前：デフォルトの名無しさん mailto:sage [2022/10/01(土) 14:10:19.42 ID:J9f91GHl0.net]: それウィルスに感染してる
550 名前：デフォルトの名無しさん mailto:sage [2022/10/02(日) 17:48:34.37 ID:6kxI91N30.net]: コミットメッセージについてです
テキストエディタを使って複数行書く方法と、コマンドライン上で1行書く方法が
あるみたいですが、基本的にはどっちを使うべきなんでしょうか？
551 名前：デフォルトの名無しさん mailto:sage [2022/10/02(日) 18:05:40.19 ID:dk1cJbbAM.net]: 仕事や既存OSSならチームのルールがあるだろうから先輩に聞け
個人ならどっちでも自分が楽な方でいい
ぶっちゃけコミットメッセージなんか誰も見ないから実際どうでもいいし、
そのうちチームに入ってから空気読めばいいだけの話なんで学習中の身のうちから意識して鍛えておかなければならないほど大した話ではない
552 名前：534 mailto:sage [2022/10/02(日) 18:30:26.77 ID:6kxI91N30.net]: >>535
分かりました　ありがとうございます
取り敢えずVSCodeを使っておこうと思います
553 名前：デフォルトの名無しさん mailto:sage [2022/10/02(日) 18:55:33.63 ID:q9OgIqJtM.net]: Vimを使って書くのが正しいやり方です
554 名前：534 mailto:sage [2022/10/02(日) 19:05:01.56 ID:6kxI91N30.net]: >>537
そうなんですね
インプレスの本ではVSCodeを使いなさいと書いてあったのでそうしました
555 名前：デフォルトの名無しさん mailto:sage [2022/10/02(日) 19:10:39.82 ID:uPDZdRB50.net]: コミットメッセージちゃんと書けるやつが本物のプログラマ。書けないやつはゴミグラマー。
自分で試行錯誤しているローカルリポジトリはコマンドラインで適当に入れても良いけど、他人に見せるやつはエディタで丁寧に時間をかけて書く。
コードを書いている時間よりコミットメッセージ書いている時間の方が長いくらいで普通。
556 名前：デフォルトの名無しさん mailto:sage [2022/10/02(日) 19:16:22.79 ID:D5S18uSu0.net]: 長文したためなくてもバグトラッカーのID書いてあればいいよ
繰り返しになるけどプロジェクト次第
557 名前：デフォルトの名無しさん mailto:sage [2022/10/02(日) 19:28:14.51 ID:Sn8H/WH4M.net]: >>539
まあチーム次第だから君が間違っていると言うつもりはないが、一般的に言って流石にコーディングより時間をかけるのは時間の無駄
コミットメッセージは見つけづらくて無駄だから、そんな時間があったらドキュメントでも書いてくれ
558 名前：デフォルトの名無しさん mailto:sage [2022/10/02(日) 20:42:06.76 ID:t7yq2oGI0.net]: https://git-scm.com/docs/SubmittingPatches#describe-changes
> 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 名前：デフォルトの名無しさん mailto:sage [2022/10/02(日) 21:53:11.93 ID:QRo7yeZh0.net]: >>539
コマンドラインでもコミットメッセージはvimとかで丁寧に書けますが
560 名前：デフォルトの名無しさん mailto:sage [2022/10/02(日) 21:57:22.79 ID:QRo7yeZh0.net]: >>541
ReamineのチケットとかGithubのIssueとかにコミットを結びつけた方が読みやすいよね
561 名前：デフォルトの名無しさん mailto:sage [2022/10/02(日) 22:11:44.82 ID:uPDZdRB50.net]: >>543
vim はエディタでないという主張は初めて聞いた。emacs は環境とういうのは良く聞くけど。
562 名前：デフォルトの名無しさん mailto:sage [2022/10/02(日) 22:30:04.49 ID:w76y/xOG0.net]: コミットはWindowsでやるならTortoiseGitが楽でいい複数行のコメントも書けるしね
ログもGUIの方が見やすいし、diffもそうだしね
563 名前：デフォルトの名無しさん mailto:sage [2022/10/02(日) 23:56:46.78 ID:Yp4OiWZtd.net]: 今時Tortoiseはないでしょ
GitはSVNなんかと違ってフォルダベースじゃないからファイルエクスプローラ上で操作するのは非合理で、
SourceTreeのようなワーキングツリーの差分をフラットに扱うクライアントのほうが圧倒的に使いやすい
普通に開発を進める分にはVSCodeやVS等のエディタ付属のGit機能で十分だしな
564 名前：デフォルトの名無しさん mailto:sage [2022/10/03(月) 01:53:25.03 ID:VqHymwUT0.net]: Windows版のSourceTreeがクソダサなのは何かの嫌がらせなの
565 名前：デフォルトの名無しさん mailto:sage [2022/10/03(月) 11:24:33.95 ID:KjjssmK/0.net]: 以前GitHubへSSH認証で接続したことがあったので、
GitBashでssh -T git@github.comと入力してみたのですが、
Permission denied (publickey).と表示され、接続を拒否されてしまいました
どう対処すればよいでしょうか？
566 名前：デフォルトの名無しさん mailto:sage [2022/10/03(月) 11:33:15.47 ID:9fynhyqE0.net]: gitに関係ないのでこっちで質問してください

ｿｰｽｺｰﾄﾞﾎｽﾃｨﾝｸﾞ総合【GitHub,GitLab,Bitbucket等】
https://mevius.5ch.net/test/read.cgi/tech/1531824290/
567 名前：549 mailto:sage [2022/10/03(月) 16:52:54.84 ID:KjjssmK/0.net]: >>550
分かりました
失礼しました
568 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ ff7c-pIDl) mailto:sage [[ここ壊れてます] .net]: >>547
SourceTreeなんてゴミ使うかよｗ
よっぽどTortoiseGitの方が使いやすいわｗ
569 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ d39f-xADz) mailto:sage [[ここ壊れてます] .net]: クラーケンでいいっすよ
570 名前：デフォルトの名無しさん mailto:sage [2022/10/03(月) 23:39:02.11 ID:HIJT7OgS0.net]: >>547
ワーキングツリーの差分をフラットに扱う、について詳しく教えてもらえませんか。
fetchするときだけSourceTree使ってるんですが、いい点があるなら知りたいです
差分の見た目はgitkと同じだと感じてまして。
571 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 53c8-H9hz) mailto:sage [[ここ壊れてます] .net]: あ、わかりました。
TortoiseGitの、エクスプローラのオーバーレイと比較してるんですね。
572 名前：デフォルトの名無しさん mailto:age [2022/10/04(火) 08:23:42.03 ID:uzf3Ju8H0.net]: Git v2.38.0
573 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 11:25:30.61 ID:00cm+2sC0.net]: TortoiseGitのオーバーレイって別に全OFFでもいいんだよな
もっさり感とかのマイナスイメージの原因でもある
コンソールを開いてないときに全体がダーティかどうかが見えるか程度のメリット
574 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 13:18:54.26 ID:8FecEEXR0.net]: TortoiseGitはシェルエクステンションの時点でインスコする気失せる
575 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 15:00:17.58 ID:iRJJVrVe0.net]: git
576 名前：使うなら開発者が愛用してるEmacsのmagitを使おうぜ []: [ここ壊れてます]
577 名前：デフォルトの名無しさん [2022/10/05(水) 08:43:21.48 ID:sfonbe+Ea.net]: GUIクライアントならForkおすすめ
578 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 22:35:11.78 ID:UUeH3vvk0.net]: そうなんだ、fork使ってみようかな
windowsしか知らないけど、sourcetreeだとdiffの横スクロールが使いづらい。
hunkごとに子scrollviewで表示するんだけど、親のscrollviewを下にスクロールしてからじゃないと、子の横スクロールバーが出てこない。
あとダブルクリックでExternal diffできないのも辛い。
さらにコミット画面が、履歴と別の画面なのが個人的にはイヤ。
履歴表示で、コミットをつなぐ線にヒット判定がないのも見ずらい。
579 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 18:25:19.94 ID:q29RvDaDM.net]: fork使ってみましたがなかなかいいですね。
自分にはSourceTreeより合っているようだ。
580 名前：デフォルトの名無しさん [2022/10/06(木) 18:28:48.47 ID:N59THtE80.net]: 女性二人が書いた売れ筋の入門書を読んでいてもGitについて、どういうものなのかハッキリしないのですが、
分かりやすく解説している本またはサイトを教えてください。
581 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 18:57:50.90 ID:tI414gt60.net]: 使い方が分からないという話？
それともソース管理がイマイチ分からない話？
582 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 19:20:02.27 ID:zjAiMCMB0.net]: なんでGitが必要なのでしょうか？
シェルスクリプトでcpしてdiffを使って差分を見ればいいのではないでしょうか？
バイナリ形式で保存されていて将来データが取り出せなるので困ります。
583 名前：デフォルトの名無しさん (ﾃﾃﾝﾃﾝﾃﾝ MM7f-d1zO) mailto:sage [[ここ壊れてます] .net]: >>565
知らんがな。
Git採用を決定したヤツに言えよ。
584 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ d314-pIDl) mailto:sage [[ここ壊れてます] .net]: 決定してませんよ
うちの学生にはシェルスクリプトで全部やらしています
流行り物のバージョン管理ツールなんて使わせません
585 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ cfbb-fxWw) mailto:sage [[ここ壊れてます] .net]: >>565
お前はいつ、誰が、何のために変更したか全部覚えておけるの？
どの変更とどの変更が一緒の組でどれが独立した修正か、差分見ただけですぐに区別できる？
多数の変更案の中から必要なものだけをすぐに組み合わせられる？
開発人数が多くなっても同じことができる？
1万回修正したとして、その差分を全部コピーで持っておくの？
その無数のコピーの中から必要なコピーを見つけるのはどうやってやるの？
586 名前：デフォルトの名無しさん (ﾃﾃﾝﾃﾝﾃﾝ MM7f-d1zO) mailto:sage [[ここ壊れてます] .net]: >>567
この「うちの学生」とは、あなたの想像上の存在に過ぎないのではないでしょうか。
587 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ d314-pIDl) mailto:sage [[ここ壊れてます] .net]: >>569
実際に教えていますが何か？
https://richlab.org/coterie/lpf.html

そんな中，まさにその疑問や悩みに応えるような内容の講義
「シェルスクリプト言語論」を金沢地区の大学向けに、2016年から
開講してきました．ここまで4回（4年）開講し，内容が洗練されてきたところでついに書籍化しました．
588 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 20:19:02.29 ID:tI414gt60.net]: バイナリでも別に過去の履歴は取って来れるような
ただリポジトリは肥大化するしバイナリの管理の為に作られたものでは無いから
相性が良い訳では無いのは分かるのだが

プログラム開発の世界でバイナリと言えば大抵はエクセルなどのオフィス系のファイルだが
正直これらをgitでバージョン管理する必要は無い気はしなくもないｗ
（でも大抵の会社はバイナリだろうがgitで管理しているが）
589 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 20:45:30.79 ID:zjAiMCMB0.net]: >>571
なにか勘違いしているようだな
gitはテキストデータでも保存するときに
バイナリ形式を使っているから将来データが取り出せなくなると言っておるのだ
その�
590 名前：謔､なものは使わん []: [ここ壊れてます]
591 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 20:46:16.55 ID:tI414gt60.net]: ん？将来？別に好きな履歴を取り出せるが？
何の話だ？
592 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 21:08:34.12 ID:vH9MiC1U0.net]: gitの使い方を知らないただの老害だった…
593 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 21:49:48.89 ID:p6k/LOp80.net]: >>565 おじいちゃん去年のスレッド忘れてまた来ちゃったの？
さぁ↓こっちに帰りましょうね。
https://mevius.5ch.net/test/read.cgi/tech/1631002816/
594 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 21:50:57.66 ID:J7yBN2sy0.net]: いつもの粘着荒しじゃないの
途中で句読点のスタイルが変わってるし半分コピペの創作だろ
あの手この手で相手してほしいんじゃね
595 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 22:22:36.07 ID:DBe4OZi40.net]: バイナリ形式だから将来取り出せないって、何を心配してるんだろう？文明崩壊後でコンピューターが使えなくなった時？岩に刻んでおく？
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]: 頭おかしい奴が沸いているｗ
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]: >>612set-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の書式の多様性を求めるなら、自分が使ってるコマンドの方を多様性を受け入れるようにすれば良いんじゃね
697 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 16:37:40.55 ID:GzQExg5g0.net]: gitにとってファイルの差分を抽出する機能は、単にユーザへ表示したりパッチをつくるだけじゃなくて、gitの特徴的なマージやリベースを実現するための核心的機能なんだよ
なので専用のものを内製する意味はある
698 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 18:09:11.73 ID:J+3pjzxx0.net]: >>671
OSSが世界中のプログラマからの元気玉なのは事実だろ
元気をマニュアルに消費されてなければ、もっと大きな元気玉になってただろうよ
699 名前：デフォルトの名無しさん [2022/10/31(月) 18:20:34.93 ID:5K9TC9u30.net]: 初歩的な質問ですが教えてください。
コミットの履歴が汚くなった場合、皆さんはどのように管理されてますでしょうか？

具体的には、
gitでdevelopからブランチを切ったAで作業しました。

ブランチAのコミット履歴が汚くなったので
新たに作成するブランチBにブランチAで変更したファイルを
一回のコミットで整理したいです。

git cherry-pick -n fromID..toID
などで整理しているのでしょうか？
700 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 18:28:03.00 ID:oV1LtMOH0.net]: >>675
タラレバ
701 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 18:33:43.29 ID:J+3pjzxx0.net]: >>672
> のべ何万人も十年以上使い続けた結果
それは言いすぎ。カーネルコミュニティって400人規模と聞いた覚えがある。
毎年全員入れ替わっても1万人規模だよ。
まあこれは本質ではないのでいいが。、

> 「馬鹿でも使えるものは馬鹿しか使わない」
これって誰の言葉だ？Linusが
> マジで、Cを選択する理由が「何もなかった」としてもだ、C++プログラマー避けになるというだけで、Cを使う大義名分になる。
> https://cpplover.blogspot.com/2013/05/linus-torvalsc.html
と言ってるのは知ってるが。（しかもこれはGitの話らしい）
ちなみに俺はLinusの意見にも賛同する。プロジェクトに馬鹿が混入しないことは本当に重要なことだ。

ただ君と根本的に違うのは、「簡単は正義」と思ってることだ。
簡単に出来るのなら、簡単な方がいい。
馬鹿をふるい落とす為に敢えて難しい構造やコードにすることはない。
俺が見る限りLinusもそうしているわけではないが、君がそうしたいのは理解した。

まあ機会があれば実装して広めることになるかもしれない。
ただ俺は別のことをやろうとしてるから、Gitなんて動けば何でもいい程度でしかないので、優先順位は極めて低い。
あとたぶん、君は
> 文句言ってる暇があったらコード書いて変更した方が速い
の意味を誤解している。が、これは今言っても通じないと思う。
702 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 18:41:18.26 ID:oV1LtMOH0.net]: 小１「掛け算よりも足し算のほうが簡単だ！」
703 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 18:42:37.79 ID:oV1LtMOH0.net]: しょう１「かけざんよりもたしざんのほうがかんたんだ！かんじよりもひらがなのほうがかんたんだ！」
704 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 18:50:02.57 ID:sko8U7ef0.net]: >>678
> ただ俺は別のことをやろうとしてるから、Gitなんて動けば何でもいい程度でしかないので、優先順位は極めて低い。
これまでの開発者を含めて他の人もそうだっただけという可能性に思い至れば何の不思議もないことなのに。
705 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 18:50:46.86 ID:J+3pjzxx0.net]: >>674
不可欠な機能ではあるが、核心的機能ではない。
事実として、Git内のdiffをGNUdiffに差し替えても、マージやリベースが出来なくなるわけではないだろ。

Gitは方針を間違ってる。
もし仮にGNUdiffのアルゴリズムが糞過ぎて出力が糞でマージが出来ないとしても、
アルゴリズム部分はGNUdiffにcontributeし、Gitがそのソースコードを使えばいいだけ。
Git内のdiffもGNUdiffからforkしたのだろうし、普通はこうすると思うけど。

別に実装すべきなのはフォーマッタで、--word-diffとかの部分だよ。
勿論GNUdiffに入れるのがベストだが、この辺
706 名前：は断られてもおかしくないし。 ただこれも人間用であって、マージする為に必要な機能部分ではないから、 君らから見てもGitではなくdiffに入れておけ、となるはずだが。 まあdiffに手を入れたくなるのは分かるが、それはソフトウェア開発ではやってはいけない方向で、 我慢してGNUdiffにcontributeしておく方が全体の長期的利益になるんだよ。 Gitがこの辺、アルゴリズムとViewをごちゃ混ぜに扱ってるのも気になる。 MVCとかまるで言われない世界ではあるけど、それでも基本として理解しておくべきだよ。 ビューを分離しておくことはものすごく重要だから。 []: [ここ壊れてます]
707 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 19:41:41.79 ID:oV1LtMOH0.net]: え？まさかgit diffを差分を見るだけのツールだと思ってるの？
708 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 19:42:41.80 ID:oV1LtMOH0.net]: GNU diffに依存したら、GNU diffが使われないところで
動かないってわからんかなぁ
diffは移植性低いんだよ？
709 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 19:49:40.38 ID:J+3pjzxx0.net]: ちなみに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的に言えば、常識的なプログラマー除けにはなってしまってるだろうよ。
710 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 19:51:14.64 ID:oV1LtMOH0.net]: git diffはパッチファイルを作るために利用されるし、
diffは環境依存するコマンドなんだから、
そんなのに依存したら、gitの移植性が低くなる

別の環境で実行したら、diffコマンドの出力がおかしくて
正しくパッチ当てられませんとかなったら困るやろ
常識で考えろや
711 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 19:53:03.45 ID:oV1LtMOH0.net]: >>685
> とすれば出来ることなので、gnuにこれを提案しても当然「そんなんイラネーよ」で終わってしまう。
あのさぁ、提案するのはGNUだけじゃだめだって理解してないの？
712 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 19:53:31.39 ID:J+3pjzxx0.net]: >>684
どういう意味？
少なくともどのプラットフォームにもdiffはあるだろ。
713 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 19:56:13.88 ID:GzQExg5g0.net]: >>682
diff.externalやdifftoolによる置き換えは差分表示に使うdiffを置き換えるだけで、git内部でマージやリベースを行うための差分抽出には使わないだろ
714 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 20:00:09.03 ID:9mfNegYM0.net]: ん?
これはもしかして以前来てたPOSIX原理主義者氏か?
715 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 20:00:09.25 ID:oV1LtMOH0.net]: >>688
全部同じ実装じゃねーよ
それぞれ全部細かい違いがある

すべてのプラットフォームのdiffにまで対応するなんて
大変な作業なんて誰もやろうとは思わん
716 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 20:01:01.17 ID:oV1LtMOH0.net]: 例えば2004年版のdiffには-uがないからな
The Open Group Base Specifications Issue 6
https://pubs.opengroup.org/onlinepubs/009604499/utilities/diff.html
717 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 20:02:19.83 ID:J+3pjzxx0.net]: >>686
> diffは環境依存するコマンド
は？
まあ仮にそうだったとして、Git内のdiffがあらゆる環境で同じdiffを生成するように小細工してるとでも？

ただまあこの場合、ぶっちゃけ、小細工出来る＝原因が分かってる≒多分Intサイズとかの違い、だから、
リモートリポジトリのマージで（俺は実際何を送ってくるのか知らんが）diffを送ってくるのなら、
それはマージ時点で鯖に問い合わせてdiffで済むかファイル本体を送らせてローカルでdiff取るかすればいいだけでしょ。
正直、原因究明して小細工するより後者の方が断然楽なので、合理的判断ならそうしてると思うけど。

>>691
前後したが上記。

>>689
その内部でマージやリベースを行う為のdiffをGNUdiffのdllコールと置き換えて、
マージやリベースが動かなくなるかって話だよ。普通に動くと思うけど。
718 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 20:03:29.56 ID:oV1LtMOH0.net]: > まあ仮にそうだったとして、Git内のdiffがあらゆる環境で同じdiffを生成するように小細工してるとでも？

同じdiffを生成するために、gitで実装してるんだろ
頭悪いのか？

依存ライブラリ（この場合はコマンドだが）を減らすのは
移植性を高めるための常識だ
719 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 20:04:11.62 ID:oV1LtMOH0.net]: OSの標準コマンドに依存したら
移植性は低くなるんだよ
常識やろ
720 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 20:08:10.94 ID:J+3pjzxx0.net]: >>692
> ユニファイド形式diffを最初に開発したのはウェイン・デイヴィソンで、
> 1990年8月のことであった（comp.sources.miscのVolume 14にunidiffとして投稿）。
> リチャード・ストールマンがGNUプロジェクトのdiffコマンドにこの機能を1ヶ月後に加え、
> 1991年1月リリースのGNU diff 1.15から使えるようになった。
> https://ja.wikipedia.org/wiki/Diff
ただそれ以前に、-uがある/ないはGitでマージ出来る/出来ないにはならないだろ。
それは完全に人間用であってさ。
721 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 20:10:05.98 ID:J+3pjzxx0.net]: >>694,695
だからファイル本体をダウンロードして、mergeするマシン上でdiff取ればいいだけだろ。
これでマシン依存をなくせるし、普通の実装だよ。

通じないのか？どうもお前の書き込みは頭が悪そうだし。ならここら辺で切り上げるが。
722 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 20:15:24.67 ID:oV1LtMOH0.net]: >>696
-u がないとハンクの精度が下がるだろ
ほんとしらんならだまっとけよ
723 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 20:15:53.77 ID:oV1LtMOH0.net]: >>697
パッチファイルを受け取って
他の人がマージすることもあるだろ
ほーんと、しらんならだまっとけ
724 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 20:16:36.27 ID:oV1LtMOH0.net]: >>696
他のOSで使えるとは限らんだろうが
GNUしか頭にないんか
725 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 20:38:58.71 ID:J+3pjzxx0.net]: >>690
違うし、565からの議論は俺にとっては一部意味不明だが、正直相当不毛なのは分かる。
それはGitの構造が糞だからだ。

結局のところGitはファイルシステム上のblobツリーを管理するツールでしかない。
そしてblobが気に入らないのなら、テキストにしてしまえばいいだけで、それもまたGitでしかない。
これを理解出来ない馬鹿同士で議論してて空回りしてるだけのように見える。

具体的には、git cat-fileがblob読み出しで、対になる書き込みツールもあるはずだが知らないが、
それらを個別に交換出来れば何とでもなるだけ。PHPで一般的に使われてるPDO方式だが、
要は最終段のI/Oだけは各種取りそろえて、切り替えれば何でも出来る構造にする。つまり、

Git謹製の cat-file バイナリ：Git純正blob形式
オレオレバイナリかシェルスクリプト： Git謹製blobファイルの名前でディレクトリを作り、
その中に自分の好きな形式で突っ込んでおけばいいだけ。
XMLでもJSONでも、ただのテキストでもいい。
それらがssh用ならリモートリポジトリを読むし、DB用ならDBに格納されることになる。
最終段のI/Oを読み書きセットで交換してしまえば、その上のコードは全く同一でいけるんだよ。
繰り返すが、PHPやWebの連中は常識的にこれをやってる。(理由は複数のDBに対応する為)

それをsshは別に実装してるようだし、方針自体がかなり狂ってるよ。
LinusもDBに入れてるのを糞に言ってるが、保存先は本質ではないし、
適切なアーキテクチャであれば簡単に交換可能なものだ。
だから本来、こんな議論が発生する余地もないのだけど。
726 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 20:39:57.17 ID:oV1LtMOH0.net]: >>701
> それはGitの構造が糞だからだ。
結論ありきで理由を探すな
お前はクソな理由を一つも言っていない
727 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 20:40:47.45 ID:oV1LtMOH0.net]: 以前来てたPOSIX原理主義者氏ではなく
また別のPOSIX原理主義者氏のようだなｗ
728 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 20:41:49.56 ID:oV1LtMOH0.net]: 自分が認めているもの以外「全部方針が狂ってるよ」
その理由は、自分が認めていないからだよ

世界が認めていても
「俺が認めていないから世界の方が狂ってるんだよ！」
729 名前：デフォルトの名無しさん [2022/10/31(月) 20:45:31.00 ID:GrGctmUAM.net]: POSIX原理主義はWindowsでの開発がめんどくさくなるんで本当に嫌いだわ
あと今更awkやsedの読みづらい文法覚えるより他のスクリプト言語で書いた方が楽だし、POSIX原理主義はPOSIXに慣れている奴のポジショントークにすぎないと思うね
730 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 20:46:22.02 ID:GzQExg5g0.net]: >>693
gitのバージョン管理されているファイルツリーはdiffコマンドがそのまま解釈できるような形式でファイルシステム上に存在しないからファイル単位で変換して外部関数呼び出すとか馬鹿だな
さらにgit内部で保持されるファイルの差分情報をdiffの出力みたいな字句解析が必要なバイト配列で取り扱うのも馬鹿げてる
このファイル差分抽出は間違いなくgitの核心的機能これが無ければVCSとして機能しない
731 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 20:49:18.25 ID:oV1LtMOH0.net]: >>705
POSIX原理主義者はPOSIXを理解してないよ。
732 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 20:55:34.73 ID:GzQExg5g0.net]: >>698
-uをサポートする前は、patch作るなら-cのコンテクスト形式だろ
-cなら-uとハンクの精度は変わらん
733 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 21:08:17.57 ID:J+3pjzxx0.net]: >>706
そこら辺の機能はGit以前から完全に機能してるんだよ。
> diffが作られてしばらくは、ソフトウェアコードや技術文書のマークアップのソース部分の変更箇所を比較する、
> プログラムのデバッグ出力の検証、ファイルシステム中のファイル一覧の比較といった使い方が一般的であった。
> ed用の出力により、ファイルへの一連の変更をひとまとめにしてファイル容量を節約するというアイデアが出てきた。
> Source Code Control System（SCCS）はそのようなアイデアを実装したものとして1970年代後半に実装がなされた。
> https://ja.wikipedia.org/wiki/Diff
だからそれはGitのアイデアでも全然無く、Git以前からdiffとedを組み合わせれば誰でも出来る物だった。
勿論diffの出力がキモだから出来るだけ--minimumなのは目指すとしても、
それはdiffを改善すべき話で、Git本体が対応する話ではない。

てかこの辺のソフトウェア階層の話が通じないところを見ると、割と階層無しの文化＝本当にCしか知らない感じだな。
例えばJSとかでは、扱うデータの先がDBなのか、ローカルファイルなのか、メモリ上のStringなのかを
上位のコードは区別しないで済むようにコーディングすることが普通で、
と言うか実際はそうしか出来なくて、強制的にそうさせられるわけだが、
形式的には、ネットワークでもローカルファイルでもメモリ上のStringでも、
プログラミングモデル側からは全部読み書き出来る状態になってから制御が渡される。
(メモリ上に展開し終えてから渡されるイメージ、なおこれをRubyでは上手いこと遅延読み出しにしてたりするが)
CでI/Oを分離するにしても普通はそうするし、実際、Gitでもそうなってる。
でないと git log -L で全展開の倍ほどメモリ食うとかあり
734 名前：得ないし。 最終段のI/Oは普通はそうやって上位のコードと分離するもので、Gitもcat-fileでそうなってる。 ただ、それを交換出来ないので、テキストやDBに保存したい奴に対応出来てないだけ。 これはGitの構造の問題だよ。 それでsshを別に実装しますとか、かなり馬鹿げた方針だ。 少なくともJS知ってればそうはならない。 []: [ここ壊れてます]
735 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 21:09:37.44 ID:J+3pjzxx0.net]: Webの連中は馬鹿なのも事実だけど、馬鹿でも上手く行くように色々上手く出来てるのも事実なんだよ。
Ｃの連中は一度Webをやってみると凄く勉強になると思うよ。俺もそうだったし。
ただしWebはかなり糞なのも事実だが。
736 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 21:15:30.28 ID:GzQExg5g0.net]: >>709
マージやリベースでやってる差分抽出は最終段のI/Oじゃないし
C言語でシンプルに実装されてるgitをMSが作る馬鹿みたいに重いツールにしないでくれよ
737 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 21:34:40.89 ID:GzQExg5g0.net]: BitKeeperを元にGitを実装したリーナスはBitKeeper以前のVCSを糞みたいに言ってるんだよね
https://ezoeryou.github.io/blog/article/2015-04-08-linus-git-interview.html
edとdiffを使ったようなVCSは眼中になかった
738 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 21:39:28.36 ID:J+3pjzxx0.net]: >>711
だから普通は、内部的に圧縮されたファイルへのアクセスは、
1. 単純にメモリ展開する
2. 何らかのプロキシオブジェクトでエミュレートする
のどちらかで、大概前者だしGitでもそうなってる。
だからここで速度低下とかは関係ない話だ。
(なお後者は/dev/zeroとか/dev/randomとかと言えば分かるだろう)
そこを他の言語、PHP/JS/Go/Rustのどれかを知ってれば、
そこでオブジェクトにしてI/O分離してマルチターゲットにしてしまうのも常識。
これを思いつけない/知らないのだから多分本当にCしか知らない連中だけでやってるよ。
君からもそれを感じる。

ちなみに重くなる/ならないなら、SQLiteは大量の小さいファイルならファイルよりも速いぜ！とか言ってるし、
他DBと違ってローカルだから試してみると面白いかもよ。
https://www.sqlite.org/fasterthanfs.html
739 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 21:52:54.41 ID:GzQExg5g0.net]: >>713
内部的に圧縮されたファイル？
「ファイルツリーはdiffコマンドがそのまま解釈できるような形式でファイルシステム上に存在しない」
これを勘違いしたのかな？
ファイルじゃなくてファイルツリーね
gitのディレクトリーのツリー構造を保持する方法独特だからその各ファイルをdiff取ってもらうためにツリーをtraverseするインターフェースを提供する必要が有る
ファイル単位の差分抽出なんて複雑な処理でもないんだからそれをやってもらうためにそれよりはるかに複雑なインターフェースを設計するとか無駄以外の何物でもないな
740 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 21:54:31.60 ID:J+3pjzxx0.net]: >>712
ただそれはedとdiffが問題だったわけではないだろうし、
仮にそうだったとしても、正しくソフトウェアを構成していればすぐに交換可能で、全く問題にならないんだよ。
その辺がソフトウェア階層の意識がないなあと思うところだよ。
Cはそういう世界でもあるけどさ。

edとdiffで展開するのが駄目なら、他方式の cat-file 階層に交換してしまえば何とでもなるんだよ。
Gitの方式が優れていれば、他VCSがGitの末端階層のI/Oコードを取り込めば済むだけ。
だからそこを問題にする時点でズレてる。
例えばgzipの様なストリーミング方式の cat-file にしてもう動作するし、7zipでも何でもいいんだよ。
(バージョン管理システムの場合は個別ファイルではなくファイルセットでの圧縮なので実際はこれらは適切ではないが)

それでLinusが言ってるように、キモは
> 問題はコード量ではなくて、どのようにデータを扱うかだった。
> 初期の実際のコード量は、かなり少ない。基本的な考え方が正しいかどうかにかかっている。開発を始める前からそのアイディアについて考察していたわけだ。
であって、要はツリーコントロールであって、I/Oではないだろ。
741 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 22:11:44.63 ID:J+3pjzxx0.net]: >>714
ああ、ファイルと
742 名前：勘違いしていたのは事実だが、それでも意味は同じだよ。 > gitのディレクトリーのツリー構造を保持する方法独特だからその各ファイルをdiff取ってもらうためにツリーをtraverseするインターフェースを提供する必要が有る 勿論その通りだが、つまりこれはファイルシステムであって、その先に隠蔽出来るんだよ。 NTFSかext4かbitlockerを使ってるか圧縮DISKかをアプリは気にしないだろ。 それはOSがファイルシステムの違いを隠蔽してくれるから。これと同じ。 同様に、 cat-file で末端のファイルの形式の違いは隠蔽出来て、 ファイルシステムドライバ（とでも言うべきか？)で、ツリー詳細構造の違いは隠蔽出来るんだよ。 そしてそれは当然Gitにも入ってる。 だからその上位からはGit形式のファイルツリー/オブジェクトツリーを 普通のファイルシステム/オブジェクトと同じように見せることは可能なんだよ。 そして実際にそうしてるはずだよ。 だからな、自分が管轄してる階層以外の所は、はっきり言って関係ないしコードからも見えないんだよ。 Cの場合はその辺の階層意識が希薄で、実際君との空回りもこれだが、Gitもこの辺は正しく実装されてるはず。 []: [ここ壊れてます]
743 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 22:17:17.34 ID:GzQExg5g0.net]: >>716
cat-fileは単にblobの中身を表示するコマンドってだけで、逆をやるblobを作るコマンドが用意されてるわけじゃない
つまりここでソフトウェア的に階層がきれいに分かれてるわけじゃない
ここを置き換えて自由な圧縮アルゴリズムを使えるようになっていたとしたら
Libgit2 みたいな別実装のライブラリが出現する余地もなかっただろう
ここは変にインターフェース階層なんて用意しなくて正解
gitはツールであるとともにフォーマットでもあるんだよ
フォーマットに自由なオプションが用意されているとか別の実装を作る側としては悪夢でしかない
744 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 22:33:44.64 ID:DiR+92tnM.net]: そう、このクレーマーはGitのデータモデルやデータフォーマットとしての側面を見落としてる
確固とした優れたデータモデルを持つってのは立派なUNIX哲学の一つなんだけどねえ
745 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 22:39:17.91 ID:h5Hfu9WR0.net]: >>715
いいから、お前に git は向いてないから消えろ。git は万人向けじゃない。
自分で納得がいくものを作ってそれを使え。
どうせ多人数がかかわるようなプロジェクトとかには縁がないだろから、一人で寂しく使ってろ。
746 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 22:41:57.65 ID:J+3pjzxx0.net]: >>717
> 逆をやるblobを作るコマンドが用意されてるわけじゃない
ではなくて、用意するんだよ。
そうすれば何でも簡単に出来るようになるだけ。
実際は内部的には持っててコマンドとして公開してないだけだから、実装は簡単だし。
まあ本当にソフトウェア階層の話が通じないので困るが、もう一度懲りずに繰り返してみる。

Cで言うと、printfの先はcrt.oに繋がってるだろ。
アプリはprintfまで管轄してて、crt.oの階層は知らずに済む。
そしてcrt.oをそれぞれのマシンに用意すれば、同じソースコードが動くわけだ。(勿論コンパイル必要だが)
で、そのcrt.oをネットワーク用のにしたらssh先の端末に結果が表示され、
DB用にしたらDBにデータが格納され、
普通のcrt.oを使えば画面に文字が表示される、というだけ。

階層を導入しても苦労する事はないし、
逆にC以外の言語ではI/O階層を導入する以外の方法がない程に一般的だよ。
（と言うかC以外の言語ではI/Oを直接叩くことは一般的に出来ない）
Cは上から下まで全管轄出来るんだけど、無駄にやりすぎてるコードになりがちなのも事実。
なまじ出来るものだからやっちゃうのだけど、それは正しい構成ではないんだよ。
747 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 22:45:45.36 ID:h5Hfu9WR0.net]: >>720
糞理論いいから、まずは作って見せろ。
748 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 22:50:56.79 ID:GzQExg5g0.net]: >>720
そんな入れ替え可能な階層分けが必要なら最初から全部C言語以外で作ればよかったんだよ
でもリーナスはC言語を選んでほぼunixシステムコールを直接叩く方式で実装した

hqなんかの方がお前の好みに近いだろうけど、hqは廃れてgit全盛となった
むかしはこのスレにもhq信者が盛んにチョッカイかけに来たもんだけど、いまは何してるんだろうな
749 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 22:55:40.76 ID:h5Hfu9WR0.net]: もはや
750 名前：名前すらちゃんと覚えてもらえてない hg さん。 []: [ここ壊れてます]
751 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 22:59:10.92 ID:J+3pjzxx0.net]: >>717
あーだからな、フレームワークを一度使ってみれば勉強になると思うよ。

フレームワークは型に嵌められるのだけど、
その型はそれなりの奴が一生懸命考えた型だから、それなりなんだよ。
なるほどこうすればファイルもネットワークもDBも全部同じコードでいけるのか、とか分かるよ。

ファイルシステム構造も、末端のファイル自体も、
上位には関係ないように隠蔽出来るし、難しいことではない。
実際、Git cat-file はGitファイルシステムを隠蔽してる、とも言えるだろ。

>>722
つかなんか勘違いしてると思うが、階層を分けたら遅くなるとかではないんだよ。
(厳密に言えば関数コールが1つ入るからその分は遅くなるが)
752 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 23:00:32.54 ID:h5Hfu9WR0.net]: >>724
いいからお前は自分で作れ git 使う必要はないぞ
753 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 23:25:07.54 ID:GzQExg5g0.net]: >>724
結局gitがどういう方式で実装されているかなんてことよりファイルフォーマットの方が重要ってことだ
だからgitの実装とファイルフォーマットを切り離すようなインターフェース階層は必要無いしだれも実装しない
必要無いものを実装すれば余計なメンテの手間もかかる
754 名前：デフォルトの名無しさん mailto:sage [2022/10/31(月) 23:25:57.99 ID:Sz6pT8cp0.net]: すごい勢いでスレ消費してるな…

>>676
1回のコミットで整理っていうのは、1つのコミットにまとめるってことかな？
それとも1回のコマンドで済ませたいってことかな(何度もcherry-pickしたくない)？

merge squashじゃあかんかね。
連続してない部分的なコミットをまとめるならrebase squashでもいいよ。
連続してないコミットなら、rebase -i使えばいいよ。いらないコミットはdropできるよ。
rebaseするときは、元のブランチ消えるから、必要なら復帰用にブランチ作っておくといいよ。
755 名前：デフォルトの名無しさん mailto:sage [2022/11/01(火) 00:01:33.71 ID:Jzc3CN/20.net]: >>726
ファイルフォーマットというか、
Gitのキモはオブジェクトをハッシュでツリーにして管理すれば全て行けたって事だろ。

そして末端のファイルはblobだけど(既に言ったが)ディレクトリやJSONでもいいし、
中間のファイルフォーマットも実はどうでも良くて、
結局はメモリ上のオブジェクトツリーをどうやってファイルシステムにマッピングするかでしかないんだよ。
traverseさえ出来れば何も問題ないわけでさ。

例えば今のGitはハッシュ上2文字でディレクトリを作って分けてるが、
実は3文字の方が速い場合とかもあるはずだが、そこで階層を正しく切ってないと対応出来ないだろ。

まあこれについてはGitはおそらく対応出来てて、traverseエンジンは多分一つしかないから、それを交換すればいいだけ。
多分DBだとフラットの方が速い。(DB内に高性能のハッシュが実装されてる、というかDBってそれがキモなので)
或いは昔のNTFS(2000かXPの頃)だと、ディレクトリ内にハッシュがなかったので、
同一ディレクトリに20,000個とかファイルを置くととんでもなく遅くなったから、上8文字とか多めにしないと死ぬ。
この辺、つまり上何文字でディレクトリ切った方が速いかは、その下の階層のハッシュの実装によるでしょ。
こういうとき、ちゃんと階層を切ってれば、簡単に切り替えられる、ということ。
そんなの変数で～#defineで～ってのがC流かもしれんが、そういう事じゃないんだよ。
そこでぶった切ることによって、その先が、ファイルシステムであっても、ネットワークであっても、DBであっても、圧縮されてても、
要はtraverseさえ出来れば何でもいい、同じコードで走行出来るし、設定も自由に変えられるし、という自由度が得られる。
代償は関数コールが一段増えることだが、今はこれは問題にされないわけでね。

まあとにかく、後日にしようぜ。
ソフトウェアの階層の切り方についてはゆっくり考えてみてくれ。
基本的には、上記の通り、関数コールが一段増えるだけで無限の自由度が得られるだけ。
Cの場合は#defineマクロで実体を呼ぶかラッパを呼ぶか簡単に切換可能なので、
実際どうするかはともかく、
756 名前：ソースコードはメンテしておくべきだよ。 []: [ここ壊れてます]
757 名前：デフォルトの名無しさん mailto:sage [2022/11/01(火) 00:33:10.99 ID:kz7RaJ2H0.net]: >>728
現状の.git/* の形式が十分にシンプル明解でこれが共通I/Fになっている
すでにこの共通I/Fに沿っていろいろな実装が存在している
結果これを変更するための内部的なI/F階層が必要とされていない
内部的な構造としてはそんなことよりSHA-1をSHA-256に変更することの方が重要で実験的実装が進んでいる
切り口が違うからお前の言うような階層をつくってもハッシュの形式の変更には対応できない
そんなくだらないことに割く労力は無い
758 名前：デフォルトの名無しさん mailto:sage [2022/11/01(火) 00:33:26.41 ID:1wY/uhrP0.net]: 長いからまとめたよ。
「俺は実装しないけど、俺以外の誰かが俺の推測に沿うように実装しておくべきなんだ。俺は実装しないけど。」
759 名前：デフォルトの名無しさん mailto:sage [2022/11/01(火) 01:23:19.93 ID:ju8ytuSJ0.net]: なんでgitの話でフレームワークの話が出て来んのかな
760 名前：デフォルトの名無しさん [2022/11/01(火) 01:46:22.68 ID:Mxyz6tUC0.net]: 無限の自由度の代わりに組み合わせ爆発が生じてエッジケースでバグが出まくり、というのは嫌だという設計思想なんじゃないかな
確かにWeb系でDIするのは当たり前だけど、RDBMSやビジネスロジック以外はトラブってもいいWeb系と違ってgitでトラブル続発したら困るし。
ファイルシステムみたいなものでは。
761 名前：デフォルトの名無しさん [2022/11/01(火) 01:52:53.48 ID:Mxyz6tUC0.net]: あと大体git自体が膨大なLinuxカーネルのVCSとしてかなり高速に、確実に動作する必要があったという大前提があるだろう。
そこを無視して汎用的にはこっちの方がいいってのは違うんじゃないかな。
汎用的な用途としてのVCSが欲しいならばpost-gitを作るしかないと思うよ。
762 名前：デフォルトの名無しさん mailto:sage [2022/11/01(火) 02:08:49.56 ID:QdibabTL0.net]: そもそも汎用性がある方が良いというのから幻想
道具は利用目的にあっているかどうかが全て十徳ナイフありがたがるやつは素人
763 名前：デフォルトの名無しさん mailto:sage [2022/11/01(火) 03:17:45.94 ID:Jzc3CN/20.net]: >>729
それも根本的に間違ってる。
ハッシュはハッシュでレイヤーを切るから、正しく構成されてるソフトウェアなら、
ハッシュを変更するのはハッシュ生成関数内だけで済むんだよ。

具体的には、全体は get_hash() を呼んでハッシュを受け取るようにしておいて、
その get_hash() 内でSHA-1かSHA-256かmd5かを変更するだけにするんだよ。
というかこんなの当たり前すぎてお前らが理解出来てないのにびびる。
オブジェクト指向では基本中の基本とされてることだぞ。
お前らプログラマじゃねえだろマジで。プログラマなら、ちょっと勉強し直さないとヤバいぜ。

ただこれは、本質的に「返ってくるオブジェクトのサイズは予想出来ない」事になり、
C的な「返ってくるオブジェクトのサイズは呼ぶ前に完全に予期出来ている（だいたい固定）」の世界にはフィットしない。
C++とかはデストラクタで、その他言語はGCで対応するのが常策だが、
これに関してはバイナリにハードコードで問題ないから#defineでいい。

ただC++だと#defineは悪とされてるから、絶対にデストラクタでやるんだ！いやスマポだ！みたいな奴も居て、
それを勧めてくるからLinusはブチ切れてるわけだが。
だけどハッシュサイズなんて動的に変化すること無いのだから、#defineで全く問題ない。
そしてそれに手こずってる時点で、#defineでの切換すら出来ない、
全体がそれぞれで勝手にSHA-1を生成してたコードになってるって事だよ。
それはマジで糞だよ。(まあ、でも直せば済む話ではあるんだけどさ)
764 名前：デフォルトの名無しさん mailto:sage [2022/11/01(火) 03:19:13.38 ID:Jzc3CN/20.net]: >>732,733
これをDIと呼ぶのか？はさておき、DIでバグが増えるなんて事はないよ。
そして、get_hash()でのオーバーヘッドは関数呼び出し一回でしかなく、
それで致命的に遅くなるなんて事もないよ。
というか、
765 名前：GitのマージってI/Oバウンドだと思ってるが違うのか？ []: [ここ壊れてます]
766 名前：デフォルトの名無しさん mailto:sage [2022/11/01(火) 03:55:08.59 ID:kz7RaJ2H0.net]: >>735
ただ単純にハッシュアルゴリズムをSHA-1からSHA-256に変更するわけじゃないぞ
既存のSHA-1リポジトリも全部(リベース状態にすることなしに)SHA-256で運用できるようにしたりするんだよ
gitの開発はリポジトリのフォーマットの継続性をとても重視してる
767 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4) mailto:sage [2022/11/01(火) 08:06:29.98 ID:Jzc3CN/20.net]: >>737
同じだよ。
正しく構成されてる場合は何種類混在しても全く問題ないし、簡単に変更可能だ。
つかマジでそれオブジェクト指向(OOP)の基本中の基本だから。

ただ、混在なら、Cで一般的に使われてるSIZEOFの#defineでは対応出来ないが、
Linusのコードなら、Cでは一般的に禁止されてる小文字マクロで
普通にそこら辺の関数もマクロだらけの可能性があり、(linuxカーネルコードがそう）
この場合は、#define内のマクロ定義を一箇所変更するだけで対応可能ではある。

が、まあ、マクロ云々の話は本来はNGとされてて他言語では厳禁だから、いわゆる正しい方策を示すと、
全体の関数はハッシュの中身が何か知らない状態で記述するんだよ。
get_hash()でハッシュのポインタを貰いました、中身は知りませんので具体的な操作はできません、
なので一々投げ返して操作して貰いますがよろしいですね？とする。
768 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4) mailto:sage [2022/11/01(火) 08:06:50.06 ID:Jzc3CN/20.net]: と書くと意味不明だが、この場合は要は貰ったポインタを一々投げ返して操作してもらう。
具体的には、

Hash* hp = get_hash(myObject); // myObjectからHashを生成して貰う、Hashの実体は何か知らない
Stream* sp = traverse(hp); // hashをtraverseに投げてstraem的な何かを示している末端のポインタを貰う、traverseはtraverse出来る何か、ファイルかDBかssh先のストレージか知らんが、とにかくtraverse出来る何かをtraverseして、末端のポインタを返す
GitObject* go = cat_file(sp); // cat_fileに末端のポインタを渡して、GitObjectを貰う

とする。これをOOP文法(Cにはないが）で一般的にはメソッドにして、

Hash* hp = get_hash(myObject); // 管理するのはhashのポインタのみ、中身は知らない
GitObject* go = hp.traverse().cat_file(); // hashを手がかりに翻訳させ、GitObjectを得る

とするんだよ。結果、全体のコードは実際のHashの中身がSHA-1かSHA-256かなんて知る必要もないし、
とにかくtraverseに投げてさらにcat_fileに投げれば、欲しかったGitObjectのポインタが得られる、という構造にする。
こうすれば、本体のコードはハッシュの種類(SHA-1かSHA-2576か)とは依存しなくなる（＝どちらでも全く同じバイナリで動かせるようになる）
そして travserseする実体がDBであったり、末端ファイルの中身がJSONであったりしても、
本体のコードはそれに依存しないから、何でも自由に選べるようになる。
本体のコードは、自身が使う GitObject　の中身は知っているが、
それ以外はhashを手がかりに、treeはtraverseに翻訳させ、末端の何かはcat_fileに翻訳させ、その具体的な実体は何か知らない状態で記述するんだよ。

これは拡張性ではなく保守性を上げる為の方策だが、マジで、あおり抜きで、OOPでは基本中の基本だ。
だからフレームワークとかはこうとしか書けないように構成されてるから、一回使ってみれば上手く矯正されると思うぞ。
とにかく、このレベルが理解出来ないのはヤバイってもんじゃない。
多分OOPの授業では1日目とかのレベル。
もっとも、1日目で意味を理解出来る奴は居ないが。
だからOOPって何？みたいな質問が掲示板上でもやたらでてくるわけでさ。
769 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4) mailto:sage [2022/11/01(火) 08:51:54.94 ID:Jzc3CN/20.net]: 補足。

分からなければ「OOP 抽象化」でググって色々読んでみてくれ。
死ぬほどでてくるはず。マジで基本中の基本だから。
ハッシュを交換することに手こずるようなら、その『コード』は間違いなく糞だ。(Git自体が糞と言っているわけではない）
ただ、修正すればいいだけ、要は漏れなく上記のようにしてしまえばいいだけではあるが。

正しく構成すれば、Hash変更なんて簡単に出来るし、
そもそもそうなってないコードなんてOOPでは存在を許されてない。
（そうとは書けないように構成されてる。
それを
770 名前：強制的にやらせるシステムの一つがprivateだが、これはこれで間違った使われ方も多いが） []: [ここ壊れてます]
771 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ d9e4-Xmag) mailto:sage [2022/11/01(火) 09:16:06.92 ID:kz7RaJ2H0.net]: 長々とご苦労さんだがお前SHA-256対応の意味が理解できてないよ
772 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4) mailto:sage [2022/11/01(火) 09:26:52.60 ID:Jzc3CN/20.net]: >>741
俺は以下記事の理解書いてる。
俺が書いた事の意味が分からないのは君の問題。
https://www.infoq.com/jp/news/2020/11/git-2-29-sha-256/#:~:text=%E3%81%A4%E3%81%BE%E3%82%8A%E3%80%81Git%E3%81%AF%E3%80%81%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E5%90%8D%E3%81%A8%E3%82%B3%E3%83%B3%E3%83%86%E3%83%B3%E3%83%84%E3%81%AE%E4%B8%A1%E6%96%B9%E3%81%ABSHA-256%E3%82%92%E4%BD%BF%E7%94%A8%E3%81%99%E3%82%8B%E6%96%B0%E3%81%97%E3%81%84%E3%83%AA%E3%83%9D%E3%82%B8%E3%83%88%E3%83%AA%E5%BD%A2%E5%BC%8F%E3%82%92%E5%B0%8E%E5%85%A5%E3%81%97%E3%81%9F%E3%80%82,%E3%81%93%E3%81%AE%E6%96%B0%E3%81%97%E3%81%84%E5%BD%A2%E5%BC%8F%E3%81%AF%E3%80%81%E3%83%AD%E3%83%BC%E3%82%AB%E3%83%AB%E3%81%A7%E7%94%9F%E6%88%90%E3%81%95%E3%82%8C%E3%81%9FSHA-256%E5%90%8D%E3%81%A8SHA-1%E5%90%8D%E3%81%AE%E9%96%93%E3%81%AE%E5%8F%8C%E6%96%B9%E5%90%91%E3%83%9E%E3%83%83%E3%83%94%E3%83%B3%E3%82%B0%E3%82%82%E3%83%97%E3%83%AD%E3%83%93%E3%82%B8%E3%83%A7%E3%83%8B%E3%83%B3%E3%82%B0%E3%81%99%E3%82%8B%E3%80%82
ただ、初めてOOPを示されていきなり意義を理解出来る奴はほぼ居ないのも事実。
でも、君は確実に老害扱いされてると思うよ。
773 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ f15f-iYvO) mailto:sage [2022/11/01(火) 09:32:09.77 ID:WFTKMpG40.net]: なんだか知らんけど5chでうだうだ言ってて何になるの
774 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ d9e4-Xmag) mailto:sage [2022/11/01(火) 09:36:58.90 ID:kz7RaJ2H0.net]: >>742
君はその記事の意味することを理解できてないね
コミットオブジェクトの構造とか役目を理解出来てないと難しいかもしれない
775 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 497b-vCJ4) mailto:sage [2022/11/01(火) 09:57:34.79 ID:Jzc3CN/20.net]: >>744
そう思いたいんだろうけど、残念ながらそうじゃない。

少なくとも君はソフトウェア階層やOOPの基本事項について全く理解出来てない。
だから今、老害と言われ続けるか、再び学び直して熟練者と言われるかの分水嶺にいるだけ。
俺は君に何も強制することは出来ないが。

確かに俺はGit初心者なので、記事の理解は間違ってるかもしれない。
でも、ハッシュの中身や長さが変わったり混在したところで、
正しく構成されてるソフトウェアなら数行の変更で対応可能なのは事実だよ。
そして君と同様の人達によってGitが作られているのであれば、
そりゃそうなってなくて苦労するんだろうさ。

まあいいけどね。もう水掛け論だから終わりにしようぜ。これ以上やってもお互い得る物もないし。
776 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 8b8f-5UCg) mailto:sage [2022/11/01(火) 10:12:34.67 ID:ju8ytuSJ0.net]: > GITは、すべてのファイルオブジェクトとコミットの識別と整合性チェックをSHA-1に強く依存しています
こう書いてあるのになんで無視するんだろう
777 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ d9e4-Xmag) mailto:sage [2022/11/01(火) 10:29:09.24 ID:kz7RaJ2H0.net]: >>745
数行で対応ｗ
それが出来ないgithubは無能集団なんですねｗ
糞MSに買われちゃうぐらいだから仕方ないか
778 名前：デフォルトの名無しさん mailto:sage [2022/11/01(火) 12:34:56.06 ID:lDKItQe4r.net]: Git初心者に語らせると頓珍漢な文章が生まれるという好例
779 名前：デフォルトの名無しさん mailto:sage [2022/11/01(火) 12:39:40.93 ID:QdibabTL0.net]: >>745
お前日本語読めなさそうだな
ましてやリンク先にある英語とかかけらも理解できてないだろ
混在とかじゃないぞ。二つを同時につけて「安全」に相互変換するということだぞ
安全にすることが目的でSHA-256を使えば解決みたいな話じゃない
�
780 名前：ｨ前みたいなのが目的と手段を取り違えるタイプの典型 OOPとかアホなプログラマでも理解できる単純なことなわけないだろ そんなんで済むならとっくに終わってる まずは常識で考えろ できないなら黙って勉強しろ []: [ここ壊れてます]
781 名前：デフォルトの名無しさん mailto:sage [2022/11/01(火) 18:29:25.93 ID:/+vO/8+o0.net]: 長文すげー
782 名前：デフォルトの名無しさん mailto:sage [2022/11/02(水) 05:40:42.57 ID:n+gr/3CY0.net]: >>749
どうであれ同じだよ。

複数付けようが、何をどう組み合わせようが、
抽象化の向こうの実体については知らないし、取り扱うコードも存在してないから、
同じバイナリで動作するんだよ。それが抽象化と隠蔽で、これはOOPの基本中の基本。
783 名前：デフォルトの名無しさん mailto:sage [2022/11/02(水) 05:41:43.29 ID:n+gr/3CY0.net]: んー、お前ら完全に化石だわ。若い奴からは確実に馬鹿にされてるよ。
というか、現在において有名OSSにこんな化石居住区が存在してたことにびっくりだわ。

>>747
数行ってのは誇張ではなく、実際にそんなもんなんだよ。
例えばMMDは3DVision対応に20-30行と言ってるが、
> そのため、樋口氏がMMDの3D Vision対応に要したのは、20～30行程度の簡単なコーディングのみだった。
> https://pc.watch.impress.co.jp/docs/topic/feature/415525.html
この樋口氏はVer5->7でDirectX対応してて、その時もインタビュー受けてて(ググッても出てこないが)
確か「よくよく確認して、実際に変更する必要があるのは2-3行だったのでほっとしました」
とか言ってたはず。

これは特殊ケースではなく、こうなるように設計するんだよ。
これに対してGitはマニュアル見てもそういう思想が全く見あたらず、「頑張ればいいよね」で終わってる。
だから糞なソースも「頑張って」修正して何とかするんだ、のノリだ。

ソフトウェア工学はそんなのは20年前にクリアしてて、今は、
A. どうすれば変更に対して強くなるか（仕様変更があってもソースコードを変更せずに済むか）
B. どうすればそもそもソースコードを記述する必要すらなく出来るのか(全ての状況に対し同じバイナリで対応する)
C. どうすれば出来るだけ早い段階でバグを検出出来るか
とか移ってて、大体馬鹿がCに対して悪ノリしてるからLinusがこき下ろす事態になるのだが、
ABはちゃんとやらないと話にならないよ。

だからまあ、次のGitは「勉強をがんばらなくてすむGit」で、
実装で一番簡単な方法は、Gitをバックエンドに使ってシェルスクリプトでラップすることだよ。これらは既に言ったが。
でも君らは「頑張らなくちゃいけない」「頑張るべきものだ」と思っちゃってるみたいだから、
今のGitプロジェクトからはこれは出てこないだろう。
となると、上記のようにして簡単に実装したNext-Gitに成果をかっさらわれ続ける事態になると思うよ。
ちょうどGNU/Linuxの形に似てるが。
あれはLinusが悪いわけではないし、ストールマンも別になんとも思ってないようだけど。
784 名前：デフォルトの名無しさん mailto:sage [2022/11/02(水) 06:01:09.34 ID:z+vraLDY0.net]: > これは特殊ケースではなく、こうなるように設計するんだよ。
> これに対してGitはマニュアル見てもそういう思想が全く見あたらず、「頑張ればいいよね」で終わってる。

それあなたの感想ですよね？
gitはソースコード1行程度で変更終わりですよ
785 名前：デフォルトの名無しさん mailto:sage [2022/11/02(水) 06:03:01.35 ID:z+vraLDY0.net]: > 実装で一番簡単な方法は、Gitをバックエンドに使ってシェルスクリプトでラップすることだよ。これらは既に言ったが。

シェルスクリプトは移植性低いって分かってる？
シェルスクリプトでラップしようものなら
Linuxでは動くがFreeBSDでは動かないってことが
しょっちゅう発生する

シェルスクリプトで頑張るものじゃない
786 名前：デフォルトの名無しさん mailto:sage [2022/11/02(水) 07:01:05.57 ID:S2ENS6Jw0.net]: git の一部機能は git コマンドを使ったスクリプトで実装されていたんだけど、多くのユーザーの要望に応える形でそれらのC言語化進めてる
787 名前：デフォルトの名無しさん mailto:sage [2022/11/02(水) 09:34:00.28 ID:33j+wJW8H.net]: シェルでラップw
USPから悪い影響でも受けたか？
788 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 8bbb-VzUj) mailto:sage [2022/11/02(水) 10:35:32.50 ID:sFE/M4aa0.net]: OOPなんて初心者プログラマ訓練ギブスってことを理解できなくてアホ理論展開しているやつがいてｗ
789 名前：デフォルトの名無しさん mailto:sage [2022/11/02(水) 14:42:23.54 ID:LlnSL/r70.net]: OOPなんか、そん辺のサンデープログラマでもかなり深い所までメリットデメリット含め浸透してるがな。
関数指向やクロージャがある言語も同様で
もはや当たり前のようにハイブリッドになってて一部の原理主義者以外いい塩梅で使ってるから話題にはならん。
790 名前：デフォルトの名無しさん mailto:sage [2022/11/02(水) 15:33:51.58 ID:4T0OIw/dr.net]: OOPそれほど語るなら、お前の大好きなシェルスクリプトはみんなOOP意識して作られてるのかって感じだな
791 名前：デフォルトの名無しさん mailto:sage [2022/11/02(水) 18:08:31.10 ID:mw55lzgRM.net]: リーナスを中心としたOSSコミュニティの起源にタネンバウムとのモノリシックカーネル・マイクロカーネル論争があることを知らないのかな？
結果として無駄な抽象階層を積み重ねることの無意味さをLinuxカーネルの成功が証明してしまった
もちろんLinuxカーネルもファイルシステムとか必要なとこは抽象化されてるけどね
792 名前：デフォルトの名無しさん [2022/11/02(水) 18:41:51.51 ID:1AIcQZnX6.net]: 今どきの若い奴(というか最新の風潮)ってなんでもかんでもオブジェクト指向を徹底するって感じじゃないと思うけどなあ
それこそオブジェクト指向主義みたいなのが滅茶苦茶強かったのって20年前ぐらいじゃない？
WindowsもNTでマイクロカーネルにしたけどオーバーヘッドデカすぎて一部はカーネル空間に戻したりしたでしょ。
SIerの階層が深い開発なんかだとオブジェクト指向を徹底しないと事故が起こりそうだけど、そういうとこしか知らない人間なのか？
793 名前：デフォルトの名無しさん mailto:sage [2022/11/02(水) 22:26:03.48 ID:KtYxSAYnr.net]: 何でもかんでもシェルでやろうとするやつは病気
名前を呼んではいけないあの開発手法とか推してそう
794 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 05:47:24.09 ID:AHw2USmo0.net]: >>755
それはどのプラットフォームで問題になったの？
賢い選択とは思えないけどね。
具体的なデメリットは既に666で挙げたとおり。

俺はシェルの互換性問題なんて有ったとは思えないけど、
(昔からsh《bsh》は互換性は高かったし、今はその後継のbashで統一されてる。
ああ確かにcsh/tcsh/ksh/zshはゴミだったし死滅したよ)
それが問題なら、GitのC化ではなく、直接シェルの互換性を上げるのが常策だよ。
互換性がC化で達成出来るのなら、
既にあるbash(多分C)ソースをコンパイルしただけのものを同梱し、
gsh(=gitsh)だ！これを使え！と強弁すれば済んだろ。

なんかやっぱり無能の働き者を地で行ってる気はする。
仕事を減らす努力をしてないよね。
795 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 05:49:10.00 ID:AHw2USmo0.net]: >>758
その通りだ。だからアマチュアの樋口Pも正しく対応出来てた。
だからこそ、このスレのこれまでのやりとりに驚いている。
今時初心者でも、他言語スレでもあり得ない流れだ。

で、パッチ出てきたけど、あれでは駄目だね。
彼等はC流のメモリ管理の方法を知らず、Gitは完全に糞コードで出来てる。
あれでは他にもメモリリークだらけだよ。
(ただこれも想定内っぽいし、
リークしたところでアプリとしては大した問題でもないのも事実だが)

彼等は、バグを直す努力はしているが、
バグが出にくいコードにする努力は全くしてない。
OOPもやりすぎると問題だが、何故彼等はそうするのかを学んで、
美味しいところだけ貰えばいい�
796 名前：ﾌにとは思うよ。 OOP原理主義者も、Gitプロジェクトやこのスレ民みたいなOOP排除原理主義者も、同様に問題だよ。 []: [ここ壊れてます]
797 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 06:07:03.27 ID:AHw2USmo0.net]: ただ見る限りGit界隈は密結合主義のようだ。
つまり、Gitと知識的に密結合した、Gitに詳しい奴だけがGitを使うべきであり、
tutorial1が基本コマンドなら普通はtutorial2は応用コマンドのところ、
なんと内部データ構造の紹介になってるし、
(ただこれは俺には極めて有効に作用したが、普通はブーイングの嵐だろう)
798 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 06:07:22.90 ID:AHw2USmo0.net]: ソースコードも密結合、これは馬鹿除けだ！と言い放つ。
糞コードでもパッチの手数で勝負だ！カリスマLinusならモグラ叩き志願者は無限に募れる！
とまあ、他の誰も出来ないアプローチだね。
ただまあ、ソースコードを清潔に保つ目的は長期的メンテの為であり、
それは実際出来てるしいいだろ、と言われれば、はーそうですねー(棒)だが。
799 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 06:07:59.96 ID:AHw2USmo0.net]: これ見てたら、buggyな糞コードでもとりあえず動けば受け入れてどんどん改訂し、バグもパッチの手数で勝負するのと、
普通のプロジェクトがやってる、レビューして駄目なコードは最初からrejectするのと、
(つまり手間をかけてもrejectされる可能性があるからコードを投げるのを躊躇される)
どっちが良いのだろう？とは考えさせられるよ。
リソースが無限にあるOSSでは、前者の方がいいのだろうか？
LinusはBillJoyに対して「オープンソースを理解してない」と思ったらしいが、こういう事なのだろうか？
(この発言はLinus著作本にあるらしいが、俺は読めてない)

しかしこのアプローチでは、絶対に浄化はしない。
自分の糞を片づけるのは仕方ないとして、
他人の糞を片づけたがる奴はいないし、そもそもその界隈が掃除に価値を置いてない。
しかし糞コードならどんどん投げてもらえるし、それらを受け入れる限り、進化が止まることもない。
はーなんだかねー。なるほど研究者と色々衝突するのも分かる気はする。
そういや大昔「伽藍とバザール」読んだなーと思って今読み返してみたが、これがバザールなのか？

（NGにかかったので分割した）
800 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 10:41:57.59 ID:NhDXzDSd0.net]: それだけ文句あるなら本家MLで言うか自分で作り直してみろよ軍師様
これだけ大口叩いておいて英語のMLでコミュニケーションとれないとかだったら笑うが
Git は世界中のプログラマが使ってる最重要プロジェクトで、これが改良されるとなれば世界中から絶賛される
801 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 10:46:51.87 ID:odT0DHDr0.net]: まだやってのか
暇そうだな
802 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 13:22:38.17 ID:AHw2USmo0.net]: >>768
それは無理だね。
仮に時間が十分にあったとしても、俺が改善出来るのはソースコードであって、アプリではない。
アプリの改善には良い仕様にする事が最も重要で、実装は実は大した問題ではない。
(使う分には十分に動けばなんでも良くて、それが糞コードで出来てたから何？でしかない)

GitはLinus本人が当時のVCSの問題点を全て把握してたからいい仕様になった。
俺はそうじゃない。今の俺がやったら俺にとって都合がいいだけで、他にとっては糞な物にしかならない。
ただ実際はLinusもこれで、みんな乗り換えて来たから同じ問題を抱えていたんだろ、
という解釈らしいが、いずれにしても使い込んでる奴じゃないといい仕様には出来ないんだよ。
そして例のブランコ問題
> 顧客が本当に必要だったもの
> https://dic.nicovideo.jp/a/%E9%A1%A7%E5%AE%A2%E3%81%8C%E6%9C%AC%E5%BD%93%E3%81%AB%E5%BF%85%E8%A6%81%E3%81%A
803 名前：0%E3%81%A3%E3%81%9F%E3%82%82%E3%81%AE もあり、顧客自身が実装してるんだから、そりゃ商用VCSでは絶望的に仕様的に太刀打ち出来ない。 そしてソースコード戦略も違う。Gitはコードレビューとか無い世界なんじゃないかな？ それで回るってのがスゲエが、多分これは「伽藍とバザール」の衝撃を追体験しただけなのだろう。 ソースコードを綺麗にしたら、新機能の追加が断然早くはなるけど、それは同じ人数での話で、 ここも手数で勝負だ！と来られたら、為す術もない。 ソースコードなんて糞でいいんだ、人数さえ有れば！では、研究者とは対立するよ。 なるほどエンジニアリングの天才だというのも納得ではある。 だからまあ、Gitを根本的に覆すにはGitよりも良い仕様が必要で、これは本当に難しいんだろうさ。 ところで、やはり俺のワークフローではIndexが邪魔なので削除しようと思うんだけど、 そもそもあれはどう使う為に設計されたものなのだ？ 多分Indexの存在が一番直感的でなく、『説明されてないと』間違える所だと思うんだが。 今のところadd直後にcommitしてて、邪魔でしかない状態で使ってる。 []: [ここ壊れてます]
804 名前：デフォルトの名無しさん [2022/11/03(木) 13:30:44.47 ID:9oLRzF140.net]: index stageなかったら複数ファイルの変更を一度にcommitできないじゃん。コミット粒度の問題から、全部の変更をcommitしたいわけでもないし。
どのcommitを取ってきてもちゃんと動く状態にするのが普通だからどう考えてもいるでしょ。
805 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 13:52:50.16 ID:/4IN/B1bM.net]: indexの意味がわかってない馬鹿が全然関係無いファイルをコミットしてリポジトリをブチ壊す
806 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 14:35:27.11 ID:AHw2USmo0.net]: >>771
> index stageなかったら複数ファイルの変更を一度にcommitできないじゃん。
いや普通に出来るよ。曖昧だったが、俺は git add -u; git commit -m "message"; で使ってる。

以降はワークフローの話だからどちらが正しいとかいう事ではないが、
> コミット粒度の問題から、全部の変更をcommitしたいわけでもないし。
これは若干邪道というか基本的に全部commitするものだろうし、commitしてから前に進めばいいだけで、

> どのcommitを取ってきてもちゃんと動く状態にするのが普通だから
これは俺の場合はちょっと違ってて、動かないのもcommitしてるしそれでいいと思ってるんだよ。
master/developブランチでは全部動くべきだけど、
featureでは途中のは動く必要ないし、動くようになったらdevelopにマージして消滅するんだろ？
なら特に問題ない気がする。
途中経過を記録してないことの方が問題で、記録しすぎてたら出力から間引けばいいだろ、というノリ。
だからdiffが画面１枚に収まらないようならcommitする感じ。

実際はbanchを使うのはこれからで、git flow を真似して上記のようにするつもりだが、何かまずいかな？
807 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 14:40:47.35 ID:5PP47Osh0.net]: git分からない思想も理解できないならSVN使えば？
808 名前：デフォルトの名無しさん [2022/11/03(木) 14:46:46.91 ID:9oLRzF140.net]: >>773
そりゃgitの設計思想で想定されたコミットの仕方をしていないからindex stageがいらないと感じるだけでしょ。
大多数は設計思想通りに使っているので、index stageが必要だと理解していると思うよ。
だから、「どう使うために設計された」かと聞かれれば、gitの思想通りにコミット粒度を適度に保つためだとしか言いようがない。
「俺は違うから俺はいらない」はそれはそうだろうが、だから何？って話になる。
809 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 15:04:33.12 ID:jVDh6EB5M.net]: 適当なタイミングで時系列に修正を記録していくものだと思ってる阿保には理解できないVCS
810 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 15:05:56.85 ID:AHw2USmo0.net]: >>775
git add -u を複数回して粒度を上げて動くものだけcommitしてもいいのだけど、
俺の場合は10回に1回程度は2-3回前の変更とdiff取った方が見やすいことがあって、
その場合にhash控えておくのが面倒だし、gcされてたらさらに面倒だし、gc切るのもまた邪道だろうしで、
動かないのもcommitしてfeatureの途中は動きませんと割り切るのが一番ましかと思ってる。

まあでもありがとう。
粒度調整の為ならこちらの予想の範囲内ではあった。
811 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 15:26:33.67 ID:O+O1uzzM0.net]: >>777
> その場合にhash控えておくのが面倒だし、gcされてたらさらに面倒だし、gc切るのもまた邪道だろうしで、
N個前との diff は git diff HEAD~N でハッシュを控える必要もないし gc のくだりは何のこと言ってるのかわからない。

> 動かないのもcommitしてfeatureの途中は動きませんと割り切るのが一番ましかと思ってる。
ローカルブランチなら別に構わないけど、そのノリで作られたブランチをそのままレビューするのは効率悪い。
なのでマージ前のブランチをレビュー対象とする開発では push の際に整理することになるから、
都度整理の際にインデックスはとても有用。
他にも、作業中に全然関係ない typo 直したりするのにも使える。
812 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 15:53:58.77 ID:HnXRQ5rf0.net]: index の重要性が分からないやつが git 語ってて草。
素人向けに説明すると git の役目は他人に読んでもらうやすい分かり易いパッチを仕上げること。
個人で作る分にはそれほど関係ないが共同作業するには他人への分かり易さ、見た目は最重要といっていい。
料理に例えるならフライパンやまな板のまま出すんじゃなくて、皿に盛って食べ易くしてから出すのが基本。
ワークツリーがフライパンで、インデックスが皿。フライパンからでも直接食えるけど、綺麗に皿に盛って、そこで丁寧にチェックしてから提供すれば他人の作業効率が上がる。
813 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 16:18:44.28 ID:AHw2USmo0.net]: >>778
> N個前との diff は git diff HEAD~N でハッシュを控える必要もないし gc のくだりは何のこと言ってるのかわからない。
(tutorial2を読んだだけの理解だから間違ってるかもしれんが、)
669で言ったように、Gitが分かりにくいのは業務プロセス名がコマンドに付いてるからだよ。
実際には、git add でスナップショットを取ってて、(←これが直感的に認識出来ない）
git commit でツリーの頭にそれを付け加えてるだけ。
だからaddしてないと付け加えるべきスナップショットがないからコケる。
それで、>>103-107、stashしてたら何処かに存在してるし、
実はaddした時点で保存されてるから、こちらもgcが行われる以前ならhashさえ分かれば引っ張ってくることが可能。
ただし次のaddでindex先が切り替えられてダングリングになり、gc対象になるから、
存在してるかどうかはgcの動作具合による。
(だから初心者向けには、git add でスナップショットが取れてるなんて死んでも言えないし、余計に分かりにくくなってる）

俺が粒度を上げるのなら、commitせずに複数回addする事になり、
2回以上前のはツリーから外されてるのでHEADからでは辿れない。(git fsckなら探せるはずだが)
だから動かない物もcommitしてHEADから辿れるようにしようとしている。
まあちょっと書き方が悪かったかもしれんが。

なので、実際の動作は git add 改め ss (take SnapShot)、git commit 改め relinkなのだけど、
ついでに relink もリストラして ss (git add -u; git commit) と ss -m "message" (git add -u; git commit -m "message")でいい。
これなら alias ss='git add -u; git commit' で済むし、
直感的になってアホでも使える。コミットメッセージが空なら動かない。
これが俺流の「勉強しなくていいGit」だよ。Indexよさらば。アホ向けGitこんにちは。

> マージ前のブランチをレビュー対象とする開発では push の際に整理することになるから
本体リポジトリとルールが違うと収まりが悪いのは了解した。

> 他にも、作業中に全然関係ない typo 直したりするのにも使える。
なるほどこれは微妙に便利かも。
(しかし俺流アホ向けgitでもこれは問題なく出来る。何せgitコマンドはスルーだからな)
814 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 16:20:05.12 ID:AHw2USmo0.net]: >>779
いやレビュー対象はcommit済みで、index上ではないだろ。
815 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 16:22:38.83 ID:5PP47Osh0.net]: うんうんわかった
大人しくSVN使え
その方が君には向いている
816 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 17:18:17.27 ID:NhDXzDSd0.net]: >>781
779はindex上でレビューするんじゃなくて、indexにいれた状態にしてからdiff --cachedでcommit前の確認をするってことじゃない？自分もそれやるよ
817 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 17:50:52.37 ID:e1pojM/n0.net]: >>763
> (昔からsh《bsh》は互換性は高かったし、今はその後継のbashで統一されてる。
> ああ確かにcsh/tcsh/ksh/zshはゴミだったし死滅したよ)

FreeBSDにはbash入っとらんぞ
818 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 17:52:28.68 ID:e1pojM/n0.net]: >>763
> 既にあるbash(多分C)ソースをコンパイルしただけのものを同梱し、
> gsh(=gitsh)だ！これを使え！と強弁すれば済んだろ。
bashだけじゃ足らんだろ
GNUコマンドも全部入れなきゃな！
819 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 17:53:10.48 ID:e1pojM/n0.net]: >>770
> 仮に時間が十分にあったとしても、俺が改善出来るのはソースコードであって、アプリではない。
だからソースコードを改善しろってｗ
820 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 18:10:35.38 ID:3fLLADP3M.net]: >>784
macもbsahやめたんだよね
GPLから逃げるために
821 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 19:01:05.13 ID:AHw2USmo0.net]: あと実は、masterの意義も分からないのだが。俺の場合は、

master: 今現在Web上で公開しているもの
develop: 今現在ローカル上でテストしているもの
feature: 今現在変更中のソースコード

と3つポインタが必要なのは分かる。
しかし、masterは常にdevelopとfast-forwardマージするなら、developにタグ打てば済む。
途中からのbranchも可能だし、hotfixするにしても問題ない。
branchケチる意味もないのも分かるが、それにしても無駄に多い気もする。

と思ってたら、俺にはサル先生方式位が適切な気がしてきた。
> ここでは統合ブランチとトピックブランチという二種類のブランチを使った運用方法について紹介します。
> https://backlog.com/ja/git-tutorial/stepup/02/

サル先生方式の統合ブランチにタグ打つだけと比べて、
masterとdevelopとして別に持っておいたら何が嬉しいの？
822 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 19:03:24.24 ID:AHw2USmo0.net]: >>784
>>787
政治的案件をOSS側がフォローする必要ないと思うが…
823 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 20:29:42.55 ID:e1pojM/n0.net]: >>789
なに政治的案件の話にすり替えようとしてるんだよ
gitは環境依存が激しいシェルスクリプトに依存しないように
C言語で書いてるって話をしていただろ
824 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 20:33:17.75 ID:e1pojM/n0.net]: >>788
1系、2系の同時開発とかあるやろ
825 名前：デフォルトの名無しさん [2022/11/03(木) 20:41:00.73 ID:vXMSDhes0.net]: .gitignoreの書き方で質問
app.log, app.log.1, app.log.2みたいな感じで増えていくログファイルを無視したいのですがどう書けばいいですか？
826 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 20:41:54.93 ID:5PP47Osh0.net]: >>788
なんだやっぱりブランチのことすら分かってなかったのか
827 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 20:48:29.66 ID:5fumPTTR6.net]: >>792
*.log* でなにか被ったりする？
828 名前：792 [2022/11/03(木) 20:58:19.76 ID:vXMSDhes0.net]: logフォルダ作ってそれを無視することにしました

>>794
ごめんなさい！
829 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 21:00:04.22 ID:AHw2USmo0.net]: >>791
あ、なるほど了解。
逆に言えば、同時開発する気がなければ要らないわけだな。
830 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 21:04:46.26 ID:e1pojM/n0.net]: >>796
今自分で「必要だ」って言ったってこと理解してるかい？
831 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 21:15:11.85 ID:AHw2USmo0.net]: >>790
C化しただけで環境依存が無くなるのなら、既にC化されてるbashでいいだろ。
Cコード上で何か小細工が必要なら、それは「互換性を上げる」名分でbashにcontributeすべきで、
Git側で吸収する案件ではない。

GPLから逃れたいってのも意味が分からん。
bashのコードを改変して新機能追加してmac_bachにしたら、そのコードを公開しないといけないが、
普通にbashを使って作業するだけなら関係ないから使えばいいだけ。
何か思惑有るんだろうけど、Gitがソースを汚してまでフォローする案件じゃないだろ。

> また、これ以外にも zsh や bash などのシェルが FreeBSD Ports Collection から利用可能です。
> https://
832 名前：docs.freebsd.org/ja/books/handbook/basics/ 自分でインストールしろよ。 []: [ここ壊れてます]
833 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 21:16:20.05 ID:e1pojM/n0.net]: だからなんでgit使うだけで
bash＋たくさんコマンド入れなきゃならんのだよ
834 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 21:22:26.35 ID:AHw2USmo0.net]: >>797
必要なのはポインタであってブランチではないんだ。
というか、俺にとってはその時のスナップショットが復元出来れば何だっていいんだよ。

fast-forwardでは履歴が辿れないからrebaseで、みたいな話もあるからもうちょっと確認必要だが、
git flow は手動ではなくインストールして使え、そうすれば全部やってくれる、としてるところばかりで、
どうもmergeの時に色々判断して小細工してるようだが、何やってるのか書いてないから分からないんだ。

まあでも色々他の簡単なのもあるみたいだし、初心者だから出来るだけ単純なのにするよ。
835 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 21:25:51.42 ID:AHw2USmo0.net]: >>799
逆に一体どんな環境でやってるのさ？
普通のunixコマンド一式すら入ってないのか？

そもそもGitなんてPCかそれに近い環境で動けば良くて、それ以外は考慮する必要ない気がするが。
836 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 21:29:12.32 ID:e1pojM/n0.net]: >>800
今話をしているのはお前が言ったこと

> 逆に言えば、同時開発する気がなければ要らないわけだな。

if (同時に開発する気がある) {
　　いる
} else {
　　いらない
}

自分で同時に開発する気があればいるって言っただろ自分で
837 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 21:39:01.44 ID:AHw2USmo0.net]: >>802
ん？どこを誤解されてるのかは分からんが、
俺は複数バージョンを同時開発する気はない。
ただ、リリース後にバグが発覚するする事はあるので、hotfixはする。
838 名前：デフォルトの名無しさん [2022/11/03(木) 23:10:44.38 ID:9oLRzF140.net]: >>801
普通にSourceTreeとかでコマンド一杯を前提としているとは思えないが。
839 名前：デフォルトの名無しさん [2022/11/03(木) 23:14:43.83 ID:9oLRzF140.net]: >>788
少なくともCIで回すときは楽だろ。
Git初心者で視野狭すぎなのに、その視野の狭さを無視して「合理的に考えてこれが不要」ってのがあんたのスタイルのようだけど、
そうやってわざわざ視野の狭さから来る「不要」の主張をして反感を買ったレスで学びたいのか？
勉強したいなら、炎上スタイルは目障りなんでよしてほしいな。二言ぐらい余計なんだよ。
840 名前：デフォルトの名無しさん mailto:sage [2022/11/03(木) 23:20:07.30 ID:NhDXzDSd0.net]: >>798
以下は簡単に調べただけで、時系列の検証もしてないので、何か間違いあるかもしれない

macOSはbash,gcc,sambaをベースシステムにいれるのをやめた
これらはGPLv2からGPLv3にライセンスが変更されて、GPLv3に追加されたバイナリの取り扱いに関する条項がmacOSのセキュリティポリシーに合わなくなったのがその理由

linusはこのGPLv3の条項に批判的で、gitはGPLv2のままでいく可能性が高い
GPLv3のbashに依存するようgitを作り変えると、インストール方法をちょっと特殊にしないとgitもこのGPLv3の条項の制限をうけることになってしまうので、まあやらないだろうね

他のOSSに依存するとこういうのもあるから気を付けないといけない
841 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 00:15:00.44 ID:SQ9pznPg0.net]: > Cコード上で何か小細工が必要なら、それは「互換性を上げる」名分でbashにcontributeすべきで、
Git側で吸収する案件ではない。
頭おかしい
842 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 00:54:15.51 ID:NvjwOVKTd.net]: まあdevelopはいらないかな
mainブランチで開発すりゃいいよ
リリースブランチが必要なら別途releaseブランチを作ればよいのであって、デフォルトブランチは開発系の先端を指してる方が分かりやすい
843 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 01:05:42.22 ID:EF7BixRC0.net]: >>798
> Cコード上で何か小細工が必要なら、それは「互換性を上げる」名分でbashにcontributeすべきで、
gitの都合でbashに迷惑をかけるな
お前のやりそうなことだな
自分の都合で関係ないやつに迷惑をかける
844 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 01:06:39.03 ID:EF7BixRC0.net]: >>808
初心者のお前の感想なんかどうでもいいよ
845 名前：デフォルトの名無しさん [2022/11/04(金) 02:09:07.55 ID:v1xRwBrw0.net]: GPLに賛同せずにGNU製
846 名前：品を使ってたってことだろね。 結局Linusもタダ乗り爺ってことでしょ。 []: [ここ壊れてます]
847 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 02:50:33.29 ID:BbpXyzD40.net]: ブランチの名前の付け方や使い方なんてほんとどうでも良い。チーム内で話し合え
git のブランチは全部等価
デフォルトで main / master 作られるけど
これも使いたくなけりゃ使わなくて良いし名前変えても良い
848 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 18:16:16.05 ID:XH5wI1Z90.net]: >>805
そんなガキみたいなことはしないが、
どう取るのも自由だし、気に入らないのなら無視してくれて構わんよ。

ただgitがポンコツだと言ったとしても、それ本来お前ら関係ないよね？
自身の分身と思えるほどcontributeしまくってるのなら別だけどさ。

> 少なくともCIで回すときは楽だろ。
必要になったときに作ればいいだけなのと、
多分仕様か実装を間違えてて、今のGitの動作では技術的に実用性がない。
これは次の投稿で詳しく述べる。
849 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 18:17:59.81 ID:XH5wI1Z90.net]: A. 消したbranchの情報が確認出来るのって、reflogsだけ？
B. あと、branchは線だ！ってマニュアルは言ってるけど、点だよなこれ？
（ドキュメントか実装のどちらかが間違ってると思うが)

以下git-flowを真似てるとして、gitkと同様に下から上にcommitして、

impl5@feature5, merged to develop and master, add tag of "Version1".
impl4@feathre4
impl3@feature3
impl2@feature2, merged to develop, add tag of "Version0".
impl1@feathre1
impl0@feature0
initial@master, develop

としたとする。
このとき、featureXを一々作っては消させてるのだから、
何か簡単に一覧に出来るコマンドがあるべきだが、無さそう。(git log --walk-reflogsで探すことは出来るが)
正直あとから参照することはほぼ無いが、何かあってもいいと思うが？---(A)
850 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 18:19:31.52 ID:XH5wI1Z90.net]: そして、どうやらGitはブランチローカルという感覚がないらしく？
どのブランチにいても同じ結果が出るのはどうなのよ？---(B)

具体的には、この場合、
masterブランチでは、HEAD~1はinitialを指し、(master上での一つ前)
developブランチでは、HEAD~1はimpl2を指すべき(develop上での一つ前)
だと思うのだが、どこにいてもHEAD~1はimpl4を指してしまう。
つまり、HEAD~Nの探索先はグローバルであり、それは.git/objects下のツリーそのものらしい。

つかね、masterブランチにいた場合、
git diff HEAD~1 HEAD で前回のリリースと今回のリリースの違い
git diff HEAD~2 HEAD で前々回のリリースと今回のリリースの違い
git log ではmasterブランチ上のリリースした物のcommitログだけに絞られて表示
じゃないと実用的な意味がないと思うんだけどさ。
masterにはmergeしかしない運用なら通常は漏れなくタグが打たれ、「点」のアクセスはタグで出来る。
よって残るは「線」のアクセスだが、ブランチは「線」になってない。
実装はよく知らんが、ブランチを切って増えるのは以下の2つで、
.git/refs/heads は先頭「点」、
.git/logs/refs/heads はlogだから、「線」の為の物が無さそう。

本来ブランチはDBで言うINDEXで、CREATE INDEX develop ON git_tree WHERE branch='develop';
みたいなもので、これが「線」だと思うんだけどさ。
実際は「点」なのでHEADしか見えておらず、HEAD~1をブランチによって切り替えられない。
と思うのだが、理解間違ってる？

ここは多分仕様変更した方がいい。(直感的でないし、意味が分からない)
けど今更出来ないだろうから、Gitの仕様の綻びの一つで、next-gitで修正されるべき案件だろうね。
851 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 18:20:37.25 ID:XH5wI1Z90.net]: >>806
MacOSがFreeBSD系なのとLinusがGPLv3をボロクソ言ってたのは知ってたが、両方とも理由は知らなかった。

> GPLv3に追加されたバイナリの取り扱いに関する条項がmacOSのセキュリティポリシーに合わなくなった
よく分からんが
852 名前：結局は両方ともここかな？ > プロプライエタリなドライバソフトをLinuxカーネルに読み込む際にDRMの技術を応用している件についてだと思います。 > http://japan.cnet.com/news/ent/story/0,2000047623,20095317,00.htm > GPLv3ではDRMを実装する場合はそのDRMのアルゴリズムに加えて秘密鍵も公開することを義務付けているので、 > そのようなことをしたらプロプライエタリなドライバを提供してもらえなくなるため、賛成はできない、と。 > https://srad.jp/story/06/01/29/1119224/ ただこれって、 GPLv3のコードを使ったバイナリを配布する際、そのバイナリと同じ物を作れるソースコードも配布しろ、だから、 GPLv3のBashをGit配布zipに同梱してもBashのバイナリだから何ら問題ないはずなんだけどね。 GPLv3だからだめだ、ならGPLv2(～2007)のBashでも十分だろうしさ。 やっぱりかなり政治的だよ。勿論譲れないのだろうけどさ。 []: [ここ壊れてます]
853 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 18:22:05.12 ID:XH5wI1Z90.net]: >>807
>>809
お前ら狭量すぎ。OSS全体で盛り上がるんだ！という考えが無さ過ぎ。
diffもそうだが、bashの互換性が本当に問題なら、bashを修正すれば全員助かるだろ。
Gitコマンドをシェルで実装すると、unixコマンドの中にgitコマンドが混ぜ込まれてる形になる。
そのgitコマンドをcpに差し替え、unixコマンドだけの状態で環境依存で使い物にならないのなら、
それは立派なバグだから、bashの連中に投げれば直してもらえるよ。
自分で抱え込みすぎ。それでは回らなくなる。(のが一般的だが、バザールだからなあ…)

ただGNUとは根本的にウマが合わないだろうよ。
仕様はグダグダ、ソースコードはゴミ、でも回り続けてるのだから、GNU(伽藍)から見たら何じゃあこれは！！！ってなる。
Git側にはGNUの開発速度はどうにも認められないだろうしね。
854 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 8b14-Tk+f) mailto:sage [2022/11/04(金) 19:16:09.99 ID:EF7BixRC0.net]: > お前ら狭量すぎ。OSS全体で盛り上がるんだ！という考えが無さ過ぎ。
だからgitの話はgitの中で盛り上がればいいだろ
勝手に他人の家で盛り上がるな
ば～か
855 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 8b14-Tk+f) mailto:sage [2022/11/04(金) 19:18:48.53 ID:EF7BixRC0.net]: >>817
あとgitをbashに依存させるな
856 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 8b14-Tk+f) mailto:sage [2022/11/04(金) 19:19:54.54 ID:EF7BixRC0.net]: bashがなんでも修正を入れるわけがない
それは俺の仕事じゃないと言って断られるが落ち
bashをぶくぶく太らせるな
一つ事だけやらせろ
857 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 19:54:32.33 ID:fRhzbJ/d0.net]: >>816
GPLv3ではバイナリを配布する際にそのバイナリをユーザがソースからコンパイルしなおして入れ替え可能でなければいけないという条項になっているらしい
MacOSやiOSのアプリやストアから配布するAndroidのアプリなんかの今どきのバイナリ配布は、署名済みバイナリしか実行できないから、ここにGPLv3の物を入れるとライセンス違反になる
858 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 19:57:10.42 ID:fRhzbJ/d0.net]: >>817
GNUは別に開発組織ではないから統一的な開発ポリシーなんてものはないが、
GPLv3に移行するようなFSF管理下のGNUプロダクトは、歴史も古いし、比較的少数のおっさん達が気ままに管理してることが多いので、OSSと呼ばれるようになる前からの伝統的なUNIXフリーソフトのべたなソースツリー構成なものばかり
たとえばbashのソースコード構成なんてgitみたいにトップディレクトリ下に組み込みコマンドの実装コードがだらだら並んでてgitと変わらん
859 名前：デフォルトの名無しさん [2022/11/04(金) 20:10:08.60 ID:jUM5cpqM0.net]: どのOSでメインに作業してるのかわからん感じだな。
LinuxはCでモノリシックだとDISり、GNUコマンド群でないmacOSも�
860 名前：桝RDISり、 Windowsなんか論外って感じだろ。 3OSぐらい使ってたらとてもシェルなんか信用できないけどな。 []: [ここ壊れてます]
861 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 21:06:47.76 ID:XH5wI1Z90.net]: >>822
いやそこまでは全然見てない。
今回の仕様とパッチの顛末見て、他もそうだと勝手に推定してる。
読む価値のないコードのはずだから。(物によって全然違うかもしれんが)
ただこれで回ってるのは事実だからな～。ちょっと観戦モードだ。

まず既に言ってるが仕様がグダグダ。
仕様は追加は簡単だが、削除することは基本的に無理なので、厳選しないといけないのに、まるで出来てない。
つまりこの辺の常識的な長期保守戦略をまるで知らない奴がやってて、止める奴もいないということ。
そして今回のメモリリークだが、確保したらそこで寿命も確定する、実装が一番簡単なタイプで、
これをリークさせるようなら話にならない。
ただそれでもミスることはあるが、出てきたパッチがこれまたグダグダで、Cのメモリ管理の基本を完全に無視してる。
レビューがあったら見た瞬間落とされるソースだ。そりゃリークするよな、としか思わない。
(ただし第２弾、第３弾も出てきて、ましになりつつあるが、それでも方向性を根本的に間違ってる。
とはいえ、展開が異常に早いのも確か)

だから、通常の開発をやっているであろうGNUでは、仕様のレビューでも、コードのレビューでも落とされる。
だけどGit側にその理由を理解出来る奴がいないからこうなわけで、当然ブチ切れる。
そして喧嘩別れ、だったら俺らで作るからいいよ、でforkして突っ走ってるだけのように見える。
若すぎる。
ただそれでも実装能力だけはあるので、diffはGNUより装飾周りが断然進歩してる。
これはやっぱりGNUdiffと一緒にやってた方がみんな幸せだったと思うよ。
上手く導ける奴がいれば、
というより普通に長期保守したことがある奴が上層部に一人でもいれば、この辺は簡単に修正出来ると思うのだけど、
それは伽藍タイプの話で、バザールだとどうにもならないのかもしれんし、
突っ走らせないとプロジェクト自体が死ぬのかもしれんし、(サメみたいにね)
よく分からん。
862 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 21:10:52.33 ID:EF7BixRC0.net]: 口だけ達者で何もできない無能
863 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 21:14:59.38 ID:PwG12fTHM.net]: >>824
GNUが何なのか全く理解できていない
864 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 21:27:19.25 ID:PwG12fTHM.net]: >>823
自分が理解できないものは全部糞
理解力が致命的に弱い
この2つが合わさると全方面Disることになる
865 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 21:35:53.62 ID:SQ9pznPg0.net]: >>817
何で自分の関心の向かないOSSにわざわざ貢献しないといけないんですか？
金も貰えないのにそんなの苦行でしょう、アホらしい

それとも君はLinusに向かってそれを要求できるほどGNUに対して貢献してるんですか？
866 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 21:39:58.51 ID:EF7BixRC0.net]: bashの方を直せって言うなら
GNU bashのプロジェクトに殴り込みをかければいいじゃん
お前が
867 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 21:54:21.97 ID:XH5wI1Z90.net]: >>828
逆だよ。他人に投げられることは他人に投げろと言ってる。
bashのバグだってことになれば、勝手に直してもらえるだろ。
自分で対応するのは、直してもらえないのが確定してからでいい。

>>829
そもそも俺はbashの互換性で苦労した試しがない。
ただそもそもOS跨いでシェルスクリプトを持っていった試しも無いけどな。てかそんなこと普通せんし。
あーだから、最悪Linux/Windows/Mac用と3種類用意すればよかったんじゃね？C化よりは楽だろうよ。
868 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 21:55:50.76 ID:EF7BixRC0.net]: > 逆だよ。他人に投げられることは他人に投げろと言ってる。
なんのために？
869 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 21:56:20.74 ID:EF7BixRC0.net]: > bashのバグだってことになれば、勝手に直してもらえるだろ。
だからお前がbashに通報しろって

お前という他人に投げたぞｗ
さっさとやれ
870 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 7997-uk66) [2022/11/04(金) 22:08:26.91 ID:jUM5cpqM0.net]: >>8
871 名前：30 え、Cでプログラム書いたことないの？OS間の違い、標準Cライブラリの方がよっぽど互換性に苦労することないよ… 考慮しなければならないのはファイルシステムと改行コードぐらいだろう。 []: [ここ壊れてます]
872 名前：デフォルトの名無しさん (ﾌﾞｰｲﾓ MM33-ntN1) mailto:sage [2022/11/04(金) 22:17:50.42 ID:qsZ+zSWqM.net]: まあおまえら落ち着け>>815とか見る限りこいつはひとりではGitを理解できない
炎上させて答えを引き出そうとしてるから餌を与えちゃいかん
ほっとけばすぐいなくなるよ
873 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 22:48:48.23 ID:XH5wI1Z90.net]: >>834
ああ、@1か、これは失礼。
ただお世辞にも分かりやすいとは言えないねこれは。
まあでも、ならbranchを残す意味はあり、>>815は取り下げだな。
>>814については引き続き募集中。
874 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 22:50:35.62 ID:XH5wI1Z90.net]: @{1}ね、まあ分かると思うけど
875 名前：デフォルトの名無しさん mailto:sage [2022/11/04(金) 23:04:09.79 ID:7RpVnNq7M.net]: >>836
@{1}に気が付くとはさすが軍師殿ｗｗｗ
876 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 00:48:19.73 ID:yugci9j10.net]: HEAD~1 で一つ前のリリースとか言ってて爆笑
リリースごとに一回だけコミットするつもりなのか？
永久に git 理解できそうにないな
877 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 01:35:03.83 ID:CLSrxuim0.net]: ネットのクソ記事で独学するより、まともな本買って学習すればいいのにな
つうかあれか、gitの仕様の粗探しがしたいから使い方とかどうでもいいのか
878 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 01:42:19.97 ID:zPyCNtrD0.net]: そもそも一つ前ｗみたいな考え方するようなものじゃないよなｗ
879 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 03:02:36.62 ID:0q4aURph0.net]: 自分が理解できないから、知ってるシェルスクリプトにすがってるだけだな
POSIX原理主義者と一緒。POSIXの名前を勝手に使って
シェルスクリプトしかできないのをごまかしてる
gitを利用してシェルスクリプトしかできないのをごまかしてる
880 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) mailto:sage [2022/11/05(土) 09:15:20.90 ID:646uiMLL0.net]: >>717
ちなみに書く側のコマンドは hash-objectのようだ。
多分初期はPlumbing Commandsをシェルスクリプトでラップして各上位コマンドを提供してたのだろう。
そして俺にはこの程度のシェルスクリプトが環境依存するとはとても思えないんだけどさ。

>>821
って、ふと気づいたが、俺が使ってるのはGitBashだったわ。
現在の公式版にもGitBashバイナリは同梱されてるし、ライセンスがどうこうという問題は無いか、解決されてるよ。
Macは政治的だとして、Linusはその辺実務的に見えるから、
GPLv3をボロカス言って自分はGPLv3には参加しないが、(これは正当な権利で全く問題ない)
GPLv3を殺す為にGPLv3のプロダクトの同梱すらしない、みたいなことはしないのだろうよ。
881 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) mailto:sage [2022/11/05(土) 10:38:45.29 ID:646uiMLL0.net]: >>814
公式のcontribに置いてあるユーザー製作の勝手ツールにあるのは発見した。
つまり熟知してる公式からみても面倒な作業だと認めているわけだ。
解決というよりは諦めと納得だが、これも質問を閉じる。
> https://zenn.dev/yoichi/articles/git-restore-branch

ちなみに、branchを『後から追加』は出来るか？
いやそんな使い方はおかしい！禁止だ！かもしれんが、
やはり俺にはbranchはただの(DBにおける)INDEXで、
随時落としたり作ったり復活させられないと使いづらい。(のではないかと予想している)
ただ、要はreflogを偽造すればいいだけのようだが、
再実装は時間の無駄で
882 名前：しかないので、既にあればそれを使いたい。 []: [ここ壊れてます]
883 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 11:40:31.33 ID:zDjINlW+0.net]: >>842
index-stageを理解してないおまえにはわからないかもしれないけど、
DBへ登録されるのはwork tree上のファイル丸ごとでない場合もあるし、
逆にDBからwork treeへ展開されるのもファイルの中の一部分の場合があるから、
そんな単純にはいかない
884 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 11:40:56.02 ID:zDjINlW+0.net]: >>842
Windowsはアプリを実行する上でコード署名が必須でないから問題にならないだけ
885 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 11:41:36.89 ID:zDjINlW+0.net]: >>843
gitのマージを全然理解できてないからブランチを復活させたいとか思ってしまうんだな
普段の運用でスクリプトを使ってブランチを復活させたいとか思う羽目になることはあまりない

ブランチがDBにおけるindexみたいなものとか、後から追加できる？みたいな疑問が生じるあたり、ブランチが何なのか全然わかってない
reflogの偽造が必要という発想もかなりズレてるし、>>814 をみるとコミットの履歴がどういうものなのか理解できていないのだろう
886 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 12:57:19.46 ID:646uiMLL0.net]: >>844
さすがにその程度は知ってるぞ。
ただ、一般的には git add -A で問題ないディレクトリ構成で使う方が多いんじゃないか？

まあそれはさておき、
要は、正しくソフトウェアが構成されてれば、cat-file/hash-object を組みで交換すれば、
末端のファイル形式は自由に選べるって事だよ。sshにすればネットワーク先にも余裕だ。
つってももうこの話は通じないのでいいが。
887 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 13:13:08.87 ID:646uiMLL0.net]: >>845
つまり現行2.38.1のMac版にはBashバイナリが入ってないのか？
それでMacに元々入っているbash以外のshを使ってれば、そりゃ問題は発生するだろうさ。
> https://qiita.com/ko1nksm/items/59c2e8a7afa969af8212#:~:text=Mac%20%E3%81%AE%E3%82%B7%E3%82%A7%E3%83%AB%E3%81%AF%20macOS%2010.15%20Catalina%20%E3%81%A7%20bash%20%E3%81%8B%E3%82%89,%E3%81%AB%E5%A4%89%E3%82%8F%E3%81%A3%E3%81%9F%E3%81%A8%E4%B8%80%E8%88%AC%E3%81%AB%E8%A8%80%E3%82%8F%E3%82%8C%E3%81%A6%E3%81%84%E3%81%BE%E3%81%99%E3%81%8C%E3%80%81%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB%E3%81%95%E3%82%8C%E3%81%A6%E3%81%84%E3%82%8B%E3%82%B7%E3%82%A7%E3%83%AB%E3%81%AF%E3%83%90%E3%83%BC%E3%82%B8%E3%83%A7%E3%83%B3%E7%95%AA%E5%8F%B7%E3%81%AE%E9%81%95%E3%81%84%E3%82%92%E9%99%A4%E3%81%84%E3%81%A6%E4%BB%A5%E5%89%8D%E3%81%A8%E3%81%BB%E3%81%A8%E3%82%93%E3%81%A9%E5%A4%89%E3%82%8F%E3%81%A3%E3%81%A6%E3%81%84%E3%81%BE%E3%81%9B%E3%82%93%E3%80%82%20%2Fbin%2Fsh%20%E3%81%AF%20POSIX%20%E3%83%A2%E3%83%BC%E3%83%89%E3%81%A7%20bash%20%28%2Fbin%2Fbash%29%20%E3%82%92%E8%B5%B7%E5%8B%95%E3%81%97%E3%81%BE%E3%81%99

Macとしては署名済みじゃないとウイルスかもしれないので認められず、
GPLとしては署名付けるならその署名を作るソースも公開しろと言ってるわけ？
どっちも拗らせすぎだが、
一般論としては、Mac側に「開発者オプション」で「署名がないバイナリの動作を許可する」があれば済む話では？
実際自分でコンパイルしたバイナリを動かせないと困るし。
ただ、Macってスマホと同一化したからこれって脱獄になるんだっけ？
ならまあ、Gitの為に脱獄はないし、こじれるのは分かるが。

まあ、正直つき合いきれないが、俺なら、C化ではなく、
bashの機能を諦めてshの機能だけで書き直す方を選択するけどね。
888 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 13:19:32.87 ID:zDjINlW+0.net]: >>847
実際仕事すればわかるが add -Aで綺麗なコミットを作れるように整備されてるリポジトリはあまり無い
デバッグしながらコミットしていくときは add -p を使うことがとても多い
889 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 13:20:48.95 ID:zDjINlW+0.net]: >>848
https://www.infoq.com/jp/news/
890 名前：2019/07/macos-ditches-bash-for-zsh/ []: [ここ壊れてます]
891 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 13:57:20.56 ID:0q4aURph0.net]: git add -Aで十分とかさぁ、開発経験なさすぎだろ
それはgitをバックアップとか途中セーブ機能とでも思ってんのか？
1 commit = 一機能の追加とか、一日の最後にやるものとか思ってるんだろ

通常なにかのバグの修正とか
複数の個別の問題の複合なのに
それ全部まとめんな
892 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 13:58:29.56 ID:646uiMLL0.net]: >>846
そもそも俺含めて大半のプログラマはGitを理解したいとは思ってなくて、
単に便利だから使ってるだけだと思うがな。
理解せずに使えるのならそれに越したことはない。
(この価値観が相容れないのは理解したからもういいが）

君はGitを履歴追跡ツールとしてしか見てないようだが、
俺はもっと一般的に、Git形式のDBとして見てる。(INSERT履歴が保持されるDB)
そして、俺は>>808と同意見で、
開発が今現在行われていないブランチは閉じられてた方が見やすいと思ってる。
常時存在するのはgit-flowでいうdevelopだけで、masterやreleaseはタグでよく、
hotfixを作るならまずmasterブランチを復活させ、そこからhotfixを発生させたほうがいい。
(なおreleaseブランチは最後にバージョンを打つ奴にはいいが、
俺は先にバージョンを打ってから更新部分を実装するので、俺のワークフローには合わない）

それ以外にも、featureX付加時の変更漏れ/不適切な変更によるバグ挿入が後で発覚することはあるから、
git-flow的にfeatureを作っては消しで行くなら、ブランチの復活はプログラマには疑問のないことだ。
featureX_patch0と新たな変更扱いしてもgitオブジェクトツリー自体は同じだが、
名前が似てるだけの別物扱いになるので、
featureXの開発『線』をメンテナンスする気なら、branchの復活が必要になる。

実は、とりあえず同じ名前で作り直せば自動的にくっつく馬鹿向け仕様か？と試してみたが、
まあGitの文化でこれはなかった。
が、まあ、俺的にはこれであって欲しかったね。
「同じ名前が昔ありましたが、そこにくっつけますか？(Y/N)」「Y」
「いい加減にしてくださいよ、何回目ですか？」「うるせーよ」みたいな。

ただこれ、branch側は --list オプションで表示を簡単に絞れるから、
Gitの思想としてはbranchは「消さずに全部残しておけ」で、
git-flowがGitの思想と合ってないだけだね。ならツール用意しとけと。
893 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 14:02:51.18 ID:0q4aURph0.net]: >>852
世の中に理解しないで使えるものなんてない
894 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 14:04:13.47 ID:0q4aURph0.net]: 大体gitの使い方を理解したいと思ってるやつはアホ
理解するのはバージョン管理の仕方だ

こうやってツールの使い方を学ぶことが理解だと思ってるから
gitがなくなったらどうしよう
また新しいことを学ばなきゃいけないってなるんやろ
895 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 14:19:41.99 ID:W/77BOuWM.net]: >>854
git そのものを理解すること諦めたか
でもお前使い方の方も盛大に勘違いしてるよ
896 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 14:24:19.56 ID:646uiMLL0.net]: >>851
> それはgitをバックアップとか途中セーブ機能とでも思ってんのか？
> 1 commit = 一機能の追加とか、一日の最後にやるものとか思ってるんだろ
そうだぞ。
ブッ込んでおけば後で何とでもなるただのバケツでしかない。
バケツの使い方を学べとか、知るかボケだ。
後でバケツから探し出すハメになった時、取り出し方をググって取り出せれば十分だ。
大方、プログラマの大半はこの程度の認識のはずだぞ。

そしてお前が望む、綺麗な管理記録は、これのサブセットでしかないんだよ。
だから例えば俺が780で言ったように、「コミットメッセージが空」を除外すれば簡単に得られる。
今のGitにこの機能がないだけ。（まあ近い機能はあるが）
DBならWHEREに条件を付加すればいいだけの楽勝案件で、Web系ならみんな出来るよ。
sedのワンライナーで済むことすらCで実装するGit界隈だと誰も出来ないのだろうけどさ。

まあGitにSQLインタフェースを付け加えればWeb系の奴等は文句言わなくなるんじゃないかな？
連中にとっては直感的になるから。
897 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 14:34:25.48 ID:0q4aURph0.net]: > 大方、プログラマの大半はこの程度の認識のはずだぞ。

お前の周りの無能集団だけだろ
898 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 14:35:58.29 ID:0q4aURph0.net]: 一体どこのプロジェクトに「2022年11月4日の仕事終了時のセーブ」なんてコミットがあるんですかねぇ
899 名前：デフォルトの名無しさん mailto:age [2022/11/05(土) 14:42:21.04 ID:oTMzuhJSa.net]: >>858
それなんて、俺の前の職場
900 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 14:46:20.49 ID:0q4aURph0.net]: データの取り出し方なんか知っていても
過去のコミットのミスを簡単に直せないなら
バージョン管理は苦痛になるし
やっぱりツールの使い方だけ知ってバージョン管理をしたことがないんだろうな
バージョン管理が不便だからgitが作られたんだぞ
901 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 14:58:06.66 ID:646uiMLL0.net]: >>859
俺はそれでいいと思うけど。
記録してない方が問題で、記録さえしてあれば、ゴミとマジを簡単に分離出来れば十分だ。

>>860
今のGitの修正は十分苦痛だよ。
修正させたくないから面倒にする、は間違いで、
簡単に修正出来るが、修正したことも履歴に残るようにする、が正しい。
902 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 15:03:35.62 ID:0q4aURph0.net]: × 俺はそれでいいと思うけど。
○ 無能はそんなことをしている。

まずさぁ、gitというかバージョン管理の基本を理解してないんだからさ
そこから勉強しなよ
903 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 15:04:40.67 ID:0q4aURph0.net]: > 簡単に修正出来るが、修正したことも履歴に残るようにする、が正しい。

お前はテキストエディタで保存するたびに
gitにセーブしろって言ってんのか？ｗ
904 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 16:06:55.57 ID:646uiMLL0.net]: >>863
俺が言ってる「修正」は、Git自体の修正で、
> なのでマージ前のブランチをレビュー対象とする開発では push の際に整理することになる (778)
の場合に、SQL的に、
DELETE FROM my_repo WHERE branch='featureX' AND commit_message='';
あるいは、
CREATE INDEX beautiful_featureX ON my_repo WHERE branch='featureX' AND commit_message='';
で済むのに、何故Gitにつき合ってグダグダやらねばならんのだ？ということ。

それとは別に、ちょこまかcommitしても、俺は構わんと思うけど。
上記のように、それを１コマンドで除去出来れば、実務上何ら問題ない。
粒度が細かすぎてDBが膨れあがるなら、その部分を定期的にバックアップに切り出していけばいいだけ。
bitcoinはこの方式だ。

>>862
多分根本的に違うのは、

俺：俺のワークフローに合うようにツールをカスタマイズする
863： Gitのワークフローに合わせてgitを使え、それ以外認めない！

なんだよ。
Linusが個人的に開発したんだからGit自体はそれでいいんだが、
全世界でLinuxと同じワークフローが適切なわけではない。
905 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 16:10:37.55 ID:5Oe/8sYX0.net]: >>864
アホなの？コミットメッセージは毎回入れるものだ
906 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 16:11:36.07 ID:5Oe/8sYX0.net]: >>864
> 全世界でLinuxと同じワークフローが適切なわけではない。
だからgitはいろんなワークフローに対応してるんだろうが

お前のはバージョン管理のワークフローではない
ただのバックアップのワークフローだ
907 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 16:45:19.71 ID:CLSrxuim0.net]: まあ1人プロジェクトみたいだし好き勝手やらせればいいさ
908 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 16:54:40.83 ID:5Oe/8sYX0.net]: コミットメッセージが空だったら～とかわけわからんなｗ
909 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 16:56:10.72 ID:5Oe/8sYX0.net]: 行単位で独立してるデータベースのデータじゃないんだからさぁ
ソースコードは前後の歴史とつながってる
DELETEなんちゃらみたいに一つだけ取り除くことが出来るのは稀
910 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 17:21:12.99 ID:646uiMLL0.net]: >>869
それは当然UIの話で、当たり前だが�
911 名前：熾狽ﾌリンクは接続し直すんだよ。 そしてそれをユーザーには見せない。 多分ここら辺の階層の話がGitには存在しないんだよ。 だからユーザーがviでリンク書き換えろとかの勢いだろ。 超密結合だし滅茶苦茶だよそれは。 []: [ここ壊れてます]
912 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 17:22:28.46 ID:5Oe/8sYX0.net]: >>870
都合が悪いからって無視するな
前後のソースコード関連してるから
途中のコミットを取り除くことはできないと言ってる
913 名前：デフォルトの名無しさん [2022/11/05(土) 17:28:35.59 ID:B2i8Nuif0.net]: つまり、両親がイブに中出ししてお前が生まれたという歴史において、
イブの中出しだけを無かったことにはできないと言うことだね
その後の歴史でお前が存在するのはおかしいし
914 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 17:30:55.67 ID:646uiMLL0.net]: >>871
何言ってんだ？
中身はただの単方向リンクリストだぞ。
リンク先が複数のこともあるが、それでも問題なく抜ける。

ただそれ以前に、俺は既に言ったとおり「記録されてないほうが問題」とするので、
CREATE INDEXを使うが。これなら理解出来るか？
だったら、このINDEX対象をちょうど全部含むようにリンクリストを新しく作り直せばいいだけ。
それがDELETEしたものと同じ物になる。これで理解出来るか？
915 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 17:40:00.52 ID:5Oe/8sYX0.net]: >>873
じゃあ抜き取ってみ

・commit 1「aaa を追加」
aaa

・commit 2「bbb を追加」
aaa
bbb

・commit 3「bbb を ccc に置き換えた」
aaa
ccc

ここからcommit2を抜き取ったときの
commit3の修正内容をよく読んでみろ
916 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 17:44:37.25 ID:W/77BOuWM.net]: >>873
残念だけどそこから間違ってる
Gitのコミットのリストは単方向リンクリストではない
なのでリストの途中のコミットを削除したり途中に追加できない
917 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 17:58:44.17 ID:646uiMLL0.net]: >>874
ああコミットメッセージについては考えてなかったが、
俺ならそのままぐちゃっと貼り付けるけど。
つまり、

・commit 1「aaa を追加」
aaa

・commit 3「bbb を追加」「bbb を ccc に置き換えた」
aaa
ccc

になる。
918 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:03:19.55 ID:646uiMLL0.net]: >>875
親が複数あるだけの単方向リストだよ。
まあこれを単方向リストと呼ぶかは微妙だから、ツリーと言った方が通じたか？
ツリーが複数重なり合った状態になってるだけだよ。

単線の A<-B<-C なら A<-C になる。これは自明だよな。
マージの場合、(BがADのマージ結果ね）

A<-B<-C
D<-|

を

A<-C
D<-|

にする。
919 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:18:30.70 ID:5Oe/8sYX0.net]: >>876
ようやく理解したか。
だからお前がやってるのはただのバックアップを取ってるだけだっていってんだよ
バージョン管理というのは何をどう変えたかという変化を記録するものだ
スナップショットじゃねーんだよ、あーほ
920 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:19:21.47 ID:5Oe/8sYX0.net]: >>876
bbbの話がないのだから、
書き間違えなのか全く区別がつかない
バグコミットメッセージだな
921 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:21:44.83 ID:5Oe/8sYX0.net]: >>873
> ただそれ以前に、俺は既に言ったとおり「記録されてないほうが問題」とするので、

だからお前のテキストエディタでの変更内容を全部記録するって言ってるんだろ？
ファイルを保存するたびにコミットするんだろお前は？

バージョン管理で記録するのはソースコードの修正履歴であって
お前個人の作業履歴じゃねーんだよ
使い物にならないゴミコミットを作るな
922 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:26:48.37 ID:646uiMLL0.net]: >>878
ああ履歴についての認識が違うんだな。了解した。

履歴は、
俺：スナップショット＝「点」の並び
君：変更した線の並びで、それはcommitメッセージに現れる。

それだと、commitメッセージが間違ってる場合はどうしようもなくなるだろ。
あくまでソースコードが重要で、どこをどう変えたかはdiff取れば済むだけの話、
commitメッセージなんて目安に過ぎないんだよ。

Gitもこちらの立場に近く、VCSとしては珍しく(と聞いているが俺はそこまで詳しくないが）
差分ではなく本体を記録するだろ。
923 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:31:31.07 ID:5Oe/8sYX0.net]: >>881
> 履歴は、
> 俺：スナップショット＝「点」の並び

だから、それはバックアップで言うって最初から言ってるだろ
お前が完全に間違ってるんだよ

> それだと、commitメッセージが間違ってる場合はどうしようもなくなるだろ。
修正しろよ。それが出来るように作られているだろ

> commitメッセージなんて目安に過ぎないんだよ。
はっｗ　バージョン管理の素人が。
コミットメッセージの重要性を知らない時点で終わってるよ
924 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:32:44.57 ID:646uiMLL0.net]: >>880
> ファイルを保存するたびにコミットするんだろお前は？
そこまではしないが、1日10回とか平気ですることもあるし、それが問題だとも思わない。
この辺はポリシーだし、好きなようにすればいいと思うがね。

間違いなく言えるのは、俺は美しいソースコードを目指しているのであって、
美しいコミット履歴を目指しているわけではないんだよ。
そしてコミット履歴が過剰なら、落とせばいいだけだろ、という話。
無い履歴からは生成することは不可能なのだから、大きすぎる粒度より、小さすぎる粒度の方がいいに決まってる。
所詮commitメッセージなんて当てにならないし、diffが取れれば全く問題ない。
925 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:32:45.04 ID:5Oe/8sYX0.net]: > Gitもこちらの立場に近く、VCSとしては珍しく(と聞いているが俺はそこまで詳しくないが）
> 差分ではなく本体を記録するだろ。

だから最初からバージョン管理は差分を記録するものであり
gitの優れた点が、発想の転換で
本体を記録することで差分を表現することにした点なんだろ

実装の話とごっちゃにするな
そういうところが技術的に未熟なんだよ
926 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:33:34.01 ID:5Oe/8sYX0.net]: >>883
> そこまではしないが、1日10回とか平気ですることもあるし、それが問題だとも思わない。
そりゃお前が素人だから問題であることに気づいてないだけ
誰もやってないからね

> この辺はポリシーだし、好きなようにすればいいと思うがね。
お前が未熟だから反論できずにポリシーってことにしようとしてる
927 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:33:50.55 ID:zDjINlW+0.net]: >>877
分散バージョン管理ではですね、リポジトリのコピーがばらばらに複数存在することが前提なので、
あるひとつのリポジトリのコミット履歴が A<-B<-C で、他のリポジトリではこれが A<-C になっているという状況は不味いんですよ
なのでGitではそれができないようにデータ構造が設計されています
928 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:34:49.14 ID:5Oe/8sYX0.net]: > 間違いなく言えるのは、俺は美しいソースコードを目指しているのであって、
> 美しいコミット履歴を目指しているわけではないんだよ。

コミット履歴は「使うもの」だって分かってないようだな
一部のコミットだけ抜き取って
他のブランチに組み込む
使うものだ

お前はただ見れればいいと思ってる
バージョン管理を理解してない
929 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:35:50.16 ID:5Oe/8sYX0.net]: >>883
> 所詮commitメッセージなんて当てにならないし、diffが取れれば全く問題ない。

お前が作るコミットがクソだから、使いものにならなくなっているだけだなｗ
930 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:39:58.47 ID:646uiMLL0.net]: >>882
まあ君と仕事することは無さそうだから別に問題ないけど、

> 修正しろよ。それが出来るように作られているだろ
コミットメッセージをいくら修正したところでそもそも意味無いんだよ。
管理してるのはメッセージじゃなくてソースコードなんだから。
それで、重要なコメントはソースコード上に書いてるから、diff取れれば十分なんだよ。
コミットメッセージは、あくまでGit上から探し出すラベルでしかなくて、何をやったかはdiffで見るし、それ以外にないよ。

> はっｗ　バージョン管理の素人が。
> コミットメッセージの重要性を知らない時点で終わってるよ
まあ俺はGitの達人になりたいわけでもないんで、これで問題ないよ。
931 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:40:40.33 ID:5Oe/8sYX0.net]: > コミットメッセージをいくら修正したところでそもそも意味無いんだよ。
それはお前だけの感想ですねｗ
932 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:41:08.69 ID:5Oe/8sYX0.net]: > まあ俺はGitの達人になりたいわけでもないんで、これで問題ないよ。
バージョン管理の素人だって言ってる
お前、他の人と一緒に仕事ができないよｗ
933 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:41:43.46 ID:5Oe/8sYX0.net]: > コミットメッセージは、あくまでGit上から探し出すラベルでしかなくて、何をやったかはdiffで見るし、それ以外にないよ。

途中を抜いといて、何をやったかなんてわかるわけ無いだろｗｗｗ
934 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:43:50.28 ID:5Oe/8sYX0.net]: >>889
こうやってコミット履歴をちゃんと見れて
なんの変更をしたのかわかるようになるまで頑張れよ
https://github.com/freebsd/freebsd-src/commits

お前のコミットは汚すぎて
使い物にならんのだわ
935 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:44:39.97 ID:646uiMLL0.net]: >>884
> gitの優れた点が、発想の転換で
> 本体を記録することで差分を表現することにした点なんだろ
これは違う。
というかね、どっちを記録したところで、正常に動いていればどのみち任意の履歴を取り出せるから関係ないんだ。
ただ、ファイルシステム等がぶっ壊れて、断片的にしか取り出せなくなったときに、Gitみたいに本体を記録してる方が断然強い。

だから基本は「一番大事なもの」で記録するようにしなければいけない、という観点だったのだけど、
まあこれはフォールトトレラントにしろという話で、ちょっと蛇足ではあったね。
あまり関係ないからこの話は終わりで。
936 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:45:34.09 ID:5Oe/8sYX0.net]: > これは違う。
だーかーら、素人のお前の意見なんか聞いてない
937 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:50:58.69 ID:5Oe/8sYX0.net]: > ただ、ファイルシステム等がぶっ壊れて、断片的にしか取り出せなくなったときに、

gitは速度のためにスナップショットにしてると書いています
https://git-scm.com/book/ja/v2/%E4%BD%BF%E3%81%84%E5%A7%8B%E3%82%81%E3%82%8B-Git%E3%81%AE%E5%9F%BA%E6%9C%AC
938 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:53:08.44 ID:5Oe/8sYX0.net]: https://www.techpit.jp/courses/33/curriculums/34/sections/286/parts/965

なぜスナップショットとして記録するのか
スナップショットとして記録することで、複数人で開発する時のスピードを上げることができます。
詳しくは後ほど解説しますが、複数人での開発の際、並行して開発できるよう、
Gitではブランチというものを切って、バージョンを枝分かれさせて開発していきます。
このブランチでバージョンを枝分かれさせる際や、ブランチを統合(マージ)する際にスナップショットだと非常に作業が速くできます。

Gitがデータを差分というかたちで持っていると、ブランチを切ってマージする時に差分をいちいち計算しなければなりません。
しかしスナップショットで保存しておけば、差分の計算をしなくて済む分、とても速くブランチを切ったりマージできるようになります。

ちなみに、Git以前のバージョン管理ツールの多くは差分としてデータを保存していて、ブランチを切るのに大変時間がかかっていました。
大規模なプロジェクトになると数十秒かかったりすることもありました。
Gitだとこの作業が一瞬でできます。こういった事情があって、Linuxの作者のリーナス・トーバルズは
当時、大規模開発であったLinuxカーネル開発のバージョン管理システムを自作しました。これがGitのスタートです。
939 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 18:56:37.48 ID:646uiMLL0.net]: >>886
ああなるほど、ブロックチェーンよろしく親のhashデータも自分のhashに入ってるのか。
しかしそれは、改竄がばれるだけで、リンクを繋ぎ直すことが出来ないわけではないね。

というかね、それは本体ツリーの話で、
余分なcommitはrepoから消せ！とする君らにとっては問題だが、
俺みたいに、スカスカのINDEXでbranchを再構成するのはその場合にも全く問題ないはず。

ところで、
実は今もbranchの実体がどこにあるのか見えてない。
見る限り .git/logs/refs/heads/各branchにしかなさそうなのだけど、ここかね？
これだと毎回reflogを動的に解釈することになるが。
実装としておかしくはないが、普通はこうはしないので、ちょっと不可解だ。
なおオブジェクトツリーにはbranchのデータは無く、branchは各オブジェクトへのリンクの入った配列だと見てる。
だからシャローコピーでしかなく、後からでもいくらでも作れるだろ、という話。
940 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 19:03:07.94 ID:5Oe/8sYX0.net]: > 後からでもいくらでも作れるだろ、という話。
だから速度重視だって言ってる
941 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 19:03:54.30 ID:5Oe/8sYX0.net]: >>898
君、ほんと知らないなら黙ってたほうがいいよ
恥ずかしいだけだから
942 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 19:05:11.02 ID:5Oe/8sYX0.net]: >>898
> 余分なcommitはrepoから消せ！とする君らにとっては問題だが、
余分なコミットじゃなくて、
コミットとして使えないものにする
バグコミットを消せと言ってるだけ
943 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 19:21:59.71 ID:zDjINlW+0.net]: >>898
まあもう面倒臭くなってきたので全部説明しちゃうが
結果的に親のhashが自分のhashに含まれることになるのだけど、実際には親のhashは自分のコミットオブジェクトに含まれている
その自分のコミットオブジェクトから計算して求めるのが自分のhash
親の祖先に変更があれば自分のコミットオブジェクトの作り直しになってhashも計算し直すことになりそれはもう自分ではない

ブランチの実体はコミットオブジェクトのハッシュひとつだけ
それで事足りる
ず～～～と思っているんだがどう考えてもお前のブランチへの理解はオカシイ
内部的な構造の話ではなくてユーザとして使う上でも問題があるような酷い理解に見える
だから >>815 みたいな謎発言がでてくる
DBのINDEXみたいなもの？とかの謎解釈で突き進まれてもついていけない
944 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 20:06: ]: [ここ壊れてます]
945 名前：13.91 ID:646uiMLL0.net mailto: >>902
前半の内容は知ってるし、そのつもりで898を書いてる。
それはtutorial2に書いてあったから。
そこのhash値も混ぜてるかどうかは関知してなかっただけ。

ちなみにtutorlal2には「ここのhash値とは違うから、各自のhash値をコピペしてね」
と書いてあるが、実際は同じhash値が生成される。
だからどこまで混ぜ込んでるのかよくわからなった。
名前と時間も混ぜ込んでるぜ！と書いてあるが、どう見てもそうじゃない。
ただまあ、親ハッシュは混ぜ込んでるのは理解した。

> ブランチの実体はコミットオブジェクトのハッシュひとつだけ
それは俺の最初の理解、「点」なんだよ。815の通り。エントリポイントだけ、というわけだろ。
ただそれだと、オブジェクトツリーは辿れるが、
master @{1}で「master branch上の」一つ前、という経路情報に変換することが出来ない。
つまり、HEAD~! != @{1} とするには、何らかの情報が何処かに必要なんだよ。
そして今のところ、reflogしかないので、そこを動的に辿ってるのか？みたいなことになってる。
だから「reflogを偽造」(843)なんて話になる。

言い換えると、エントリポイントからだと、親は辿れるが、
親が複数現れたとき(マージ）に、どちらから来たのか分からないのと、
fast-forwardマージでオブジェクトは一本道でもbranch上では飛ばしている場合に、その情報がないんだよ。
これはどこに格納されてるんだ？ []: [ここ壊れてます]
946 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 20:19:07.74 ID:646uiMLL0.net]: すまん、分かると思うが、 HEAD~1 != @{1}
947 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 20:45:45.41 ID:zDjINlW+0.net]: >>903
reflogのhashは、HEADが変わるような操作をしたときに、その操作の結果のHEADのhashを追記していくだけのログだよ
このログがその後のgitの動作に影響を与えることはない
HEAD@{0}が常に最新の操作に対応したhashに更新される
だからたとえばmasterとfirstという二つのブランチを交互にcheckoutすればこんな感じになる

$ git reflog
0956cde (HEAD -> first) HEAD@{0}: checkout: moving from master to first
be7e7d7 (master) HEAD@{1}: checkout: moving from first to master
0956cde (HEAD -> first) HEAD@{2}: checkout: moving from master to first
be7e7d7 (master) HEAD@{3}: checkout: moving from first to master
0956cde (HEAD -> first) HEAD@{4}: checkout: moving from master to first
be7e7d7 (master) HEAD@{5}: checkout: moving from first to master

最後にcheckout firstしたので HEAD -> first になってる
948 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 20:59:53.75 ID:646uiMLL0.net]: >>905
reflogがその形式なのは知ってる。

ただ、頭のポイントだけだと、903で言ったとおり、経路情報にならないだろ。
例えば、815の場合、再記するが、

impl5@feature5, merged to develop and master, add tag of "Version1".
impl4@feathre4
impl3@feature3
impl2@feature2, merged to develop, add tag of "Version0".
impl1@feathre1
impl0@feature0
initial@master, develop

これで、master上で
git diff @{1}　では、initial commit との差分
git diff HEAD~1　では、　impl4との差分が出るんだよ。
これが、master->impl5のエントリポイント情報だけだと出来ないから、
maseterはinitial->impl5に移動しましたよ、という経路情報が何処かに必要なんだ。
それで、git reflog では、
どこにswitchして、commit して、mergeした、という履歴が全部出るから、
（多分だが各HEADのreflogを全てcatして時系列にソートしてる）
解釈すれば可能ではあるけど、そんな面倒なことするか？普通はstaticにシャローコピーだろ、というのと、
reflog は gc されるので、reflogを頼りにする実装は不適切だし、
俺的にbranchを消したり復活させたりする使い方はヤバそうなんだよ。
だからその辺を確認してる。
それで、後で任意のオブジェクト群でbranchを作れるのなら、この辺心配ないのだけど、そうではなさそうだし。
949 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 21:04:51.93 ID:646uiMLL0.net]: ちなみに、843の記事では、Git内のcontrib内のスクリプトが、
branchをreflogを参考に復活させるらしいので、reflog内の情報で足りてはいるらしい
950 名前：。 確かに目で見た限りそうだが、 でもそれだとreflogをgcするのは割と狂気の沙汰だから、おかしいよなーと思ってて。 []: [ここ壊れてます]
951 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 21:06:47.08 ID:646uiMLL0.net]: ごめん、書き方が悪かった。

907は、gc対象となるreflogを本番情報として持つのは狂気の沙汰だなーということ。
復活させるときにそこにしか手がかりがないのは仕方ないとして、
生きてるbranchは普通はツリー情報をstaticに持ってるはずだが、見あたらないんだよ。
952 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 21:15:14.62 ID:zDjINlW+0.net]: >>906
そのリポジトリがどういう構造になっているかわけわからん
git show-branch してみろ
953 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 21:26:43.61 ID:646uiMLL0.net]: >>909
すまぬ、確かに今見てればちょっとおかしい。
もう一度作るから30分ほどお待ちを。
954 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 21:51:56.84 ID:646uiMLL0.net]: >>909
結果
$ git show-branch
! [develop] impl5
* [master] impl5
--
+* [develop] impl5

$ git branch
develop
* master
955 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 21:52:24.93 ID:646uiMLL0.net]: >>909

$ git diff HEAD~1
diff --git a/test.txt b/test.txt
index 3585d98..bbddc42 100644
--- a/test.txt
+++ b/test.txt
@@ -4,3 +4,4 @@ impl1
impl2
impl3
impl4
+impl5

$ git diff @{1}
diff --git a/test.txt b/test.txt
index e79c5e8..bbddc42 100644
--- a/test.txt
+++ b/test.txt
@@ -1 +1,7 @@
initial
+impl0
+impl1
+impl2
+impl3
+impl4
+impl5
956 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 21:53:21.88 ID:646uiMLL0.net]: >>909
再現コード

#!/bin/bash -x
#

git init
echo 'initial' > test.txt
git add test.txt
git commit -m 'initial'
git branch develop

for (( i=0 ; i<6 ; i++ ));
do
git branch feature$i
git switch feature$i
echo "impl"$i >> test.txt
git add test.txt
git commit -m "impl"$i
git switch develop
git merge feature$i
git branch -d feature$i
done

git switch master
git merge develop
957 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 22:01:15.70 ID:646uiMLL0.net]: >>909
ちなreflog

$ git reflog
1a804d9 (HEAD -> master, develop) HEAD@{0}: merge develop: Fast-forward
b0325fc HEAD@{1}: checkout: moving from develop to master
1a804d9 (HEAD -> master, develop) HEAD@{2}: merge feature5: Fast-forward
ba4e962 HEAD@{3}: checkout: moving from feature5 to develop
1a804d9 (HEAD -> master, develop) HEAD@{4}: commit: impl5
ba4e962 HEAD@{5}: checkout: moving from develop to feature5
ba4e962 HEAD@{6}: merge feature4: Fast-forward
a32e11d HEAD@{7}: checkout: moving from feature4 to develop
ba4e962 HEAD@{8}: commit: impl4
a32e11d HEAD@{9}: checkout: moving from develop to feature4
a32e11d HEAD@{10}: merge feature3: Fast-forward
8d9924f HEAD@{11}: checkout: moving from feature3 to develop
a32e11d HEAD@{12}: commit: impl3
8d9924f HEAD@{13}: checkout: moving from develop to feature3
8d9924f HEAD@{14}: merge feature2: Fast-forward
0f78740 HEAD@{15}: checkout: moving from feature2 to develop
8d9924f HEAD@{16}: commit: impl2
0f78740 HEAD@{17}: checkout: moving from develop to feature2
0f78740 HEAD@{18}: merge feature1: Fast-forward
47792a3 HEAD@{19}: checkout: moving from feature1 to develop
0f78740 HEAD@{20}: commit: impl1
47792a3 HEAD@{21}: checkout: moving from develop to feature1
47792a3 HEAD@{22}: merge feature0: Fast-forward
b0325fc HEAD@{23}: checkout: moving from feature0 to develop
47792a3 HEAD@{24}: commit: impl0
b0325fc HEAD@{25}: checkout: moving from master to feature0
b0325fc HEAD@{26}: commit (initial): initial
958 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 22:02:09.13 ID:646uiMLL0.net]: >>909
ついでに一応、終了時のtest.txt

$ cat test.txt
initial
impl0
impl1
impl2
impl3
impl4
impl5
959 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 22:05:21.84 ID:zDjINlW+0.net]: >>911-915
これ全部FFマージやってるから結果的にdevelopブランチとmasterブランチが同じものになるぞ
960 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 22:09:56.21 ID:zDjINlW+0.net]: mergeを全部merge --no-ffにするとマージした構造がわかるようになるし、最後にdevelopとmasterが別のものになる
どっちのマージにするかは現場の運用しだい
961 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 22:10:47.10 ID:zDjINlW+0.net]: git log --graph --branches --oneline とかするとわかりやすい
962 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 22:11:46.51 ID:646uiMLL0.net]: >>916
ああ、それがrebaseしないと履歴が無くなるとかいう話か？
実はそれはまだ確認中だが、とりあえず本件についてはこれでいいし、
俺的には多分こうなる。(基本的にmasterはdevelopの後を追うだけ)
けしか�
963 名前：轤ｩ？ それはさておき、本件、HEAD~1 と @{1} が違うものだという経路情報は、 どこにあるのか分かれば教えてくれ。 []: [ここ壊れてます]
964 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 22:22:33.37 ID:zDjINlW+0.net]: HEAD~1と@{1}は全然関係無いよ？
HEAD~1は今のHEADの一番目の親のhash
親が複数いるときにはHEAD^1とかHEAD^2とかで指定する
@{1}はひとつ前の操作によってHEADになったhashだから、どういう操作したかで変わり、リポジトリの構造とは関係無い
965 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 22:30:34.81 ID:zDjINlW+0.net]: >>914 で説明すると、
@{0}は最後のコミットで、FFマージした結果masterとdevelopがこのhash=1a804d9になった
@{1}はgit commit -m 'initial'の結果できた最初のコミット(最後のマージ操作の前のmaster)で、最後にこれにdevelopをマージするためcheckoutしたらこれになってる
966 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 22:35:17.82 ID:646uiMLL0.net]: >>920
> @{1}はひとつ前の操作によってHEADになったhashだから、どういう操作したかで変わり、リポジトリの構造とは関係無い
だから、それは「そのbranchの」一つ前の操作なんだよ。
結果、diffは、masterブランチでは>>912で、HEAD~1 != @{1} だが、
developブランチでは、以下になって、 HEAD~1 == @{1}　なんだよ。

$ git diff HEAD~1
diff --git a/test.txt b/test.txt
index 3585d98..bbddc42 100644
--- a/test.txt
+++ b/test.txt
@@ -4,3 +4,4 @@ impl1
impl2
impl3
impl4
+impl5

$ git diff @{1}
diff --git a/test.txt b/test.txt
index 3585d98..bbddc42 100644
--- a/test.txt
+++ b/test.txt
@@ -4,3 +4,4 @@ impl1
impl2
impl3
impl4
+impl5

だからmasterブランチをdevelopにmergeしかしない運用をした場合、
masterブランチは @{n} でn回前のリリースが検索出来、存在価値が出てくる、という見立てだが、間違ってるか？
(@はcommit履歴だと思ってるが、まさか操作履歴か？なら確かに意味無いし、先頭情報しか要らないし、reflogしかなくても納得だが)
967 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 22:40:04.85 ID:zDjINlW+0.net]: 最終的にお前のリポジトリは git merge develop でこうなっているはずだ

$ git log --graph --branches --oneline
* 1a804d9 impl5 (HEAD -> master, develop)
* xxxxxxx impl4
* xxxxxxx impl3
* xxxxxxx impl2
* xxxxxxx impl1
* xxxxxxx impl0
* b0325fc initial

最後のひとつ前の git switch master をやったときにはこうなっていたはず
* 1a804d9 impl5 (develop)
* xxxxxxx impl4
* xxxxxxx impl3
* xxxxxxx impl2
* xxxxxxx impl1
* xxxxxxx impl0
* b0325fc initial (HEAD -> master)

だから HEAD@{0} = 1a804d9 で、HEAD@{1} = b0325fc
968 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 22:46:20.49 ID:646uiMLL0.net]: >>921
@はやっぱcommit履歴だよな？

エントリポインタだけだと、commit履歴に出来ないんだよ。
今回はfast-forwardマージしてるから、

init<-0<-1<-2<-3<-4<-5 = master, develop

で、単にエントリポイントだけなら master も develop も同じ 5 で区別がない。
当たり前だが両方とも HEAD~1 は4を指してる。
ただ、@{1}は、commit履歴だから、masterでは init を指し、developでは4を指す。
この、commit履歴情報はどこに記録されてるの？というのが俺の質問。

>>923
そこは理解出来てるはず。上記の通り。
問題はcommit履歴がどこにあるか。
969 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 22:50:12.27 ID:zDjINlW+0.net]: >>922
masterブランチをdevelopブランチにマージする方法が
git switch masterとgit merge developの連続実行だけではないし、
HEAD@{n}は適当なタイミングでGCされるから、
HEAD@{n}をそんな用途に使う奴はいない
970 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 22:52:10.49 ID:zDjINlW+0.net]: >>924
commit履歴がどこにあるか説明するのに使いたいから、git log --graph --branches --oneline してくれ
971 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 22:54:11.54 ID:zDjINlW+0.net]: @はcommit履歴じゃなくて、reflogの履歴
972 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 22:57:39.34 ID:646uiMLL0.net]: >>926
$ git log --graph --branches --oneline
* 1a804d9 (HEAD -> master, develop) impl5
* ba4e962 impl4
* a32e11d impl3
* 8d9924f impl2
* 0f78740 impl1
* 47792a3 impl0
* b0325fc initial
973 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 23:01:41.48 ID:zDjINlW+0.net]: @{n}はカレントブランチのreflog履歴になるはず
reflog履歴はブランチ毎に存在するので
master@{n}とdevelop@{n}は違うハッシュになってるはず
git reflog masterとgit reflog developで比べてみればわかる
974 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 23:04:26.02 ID:646uiMLL0.net]: >>917,926
ちな --no-ff 版、
今出すと余計に混乱するかもだが。

$ git log --graph --branches --oneline
* a5aaf72 (HEAD -> master, develop) Merge branch 'feature5' into develop
|\
| * e03bcd0 impl5
|/
* 324df68 Merge branch 'feature4' into develop
|\
| * c2634c4 impl4
|/
* 68ed20a Merge branch 'feature3' into develop
|\
| * 5e12b99 impl3
|/
* 608e5d7 Merge branch 'feature2' into develop
|\
| * 4660e46 impl2
|/
* 3924eae Merge branch 'feature1' into develop
|\
| * 138d83f impl1
|/
* 7db4424 Merge branch 'feature0' into develop
|\
| * 8877414 impl0
|/
* ec041f9 initial
975 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 23:08:22.79 ID:646uiMLL0.net]: >>929
$ git reflog master
1a804d9 (HEAD -> master, develop) master@{0}: merge develop: Fast-forward
b0325fc master@{1
976 名前：}: commit (initial): initial $ git reflog develop 1a804d9 (HEAD -> master, develop) develop@{0}: merge feature5: Fast-forward ba4e962 develop@{1}: merge feature4: Fast-forward a32e11d develop@{2}: merge feature3: Fast-forward 8d9924f develop@{3}: merge feature2: Fast-forward 0f78740 develop@{4}: merge feature1: Fast-forward 47792a3 develop@{5}: merge feature0: Fast-forward b0325fc develop@{6}: branch: Created from master ってことは、commit履歴はreflogにしか無いって事か？ ならbrahchを消すとreflogも消されてcommit履歴が消えるが、マジ？ これだとbranchの復活は本質的に無理なことになってしまう。 (他branchに断片的には残ってるんだけどさ） []: [ここ壊れてます]
977 名前：デフォルトの名無しさん [2022/11/05(土) 23:09:25.37 ID:zDjINlW+0.net]: >>928
impl5のコミットオブジェクトの hash = 1a804d9
impl5のコミットオブジェクトの中には親のコミットオブジェクトimpl4の hash = ba4e962 が格納されている
impl4のコミットオブジェクトの hash = ba4e962
impl4のコミットオブジェクトの中には親のコミットオブジェクトimpl3の hash = a32e11d が格納されている
impl3のコミットオブジェクトの hash = a32e11d
impl3のコミットオブジェクトの中には親のコミットオブジェクトimpl2の hash = 8d9924f が格納されている
impl2のコミットオブジェクトの hash = 8d9924f
impl2のコミットオブジェクトの中には親のコミットオブジェクトimpl1の hash = 0f78740 が格納されている
impl1のコミットオブジェクトの hash = 0f78740
impl1のコミットオブジェクトの中には親のコミットオブジェクトimpl0の hash = 47792a3 が格納されている
impl0のコミットオブジェクトの hash = 47792a3
impl0のコミットオブジェクトの中には親のコミットオブジェクトinitialの hash = b0325fc が格納されている
initialのコミットオブジェクトの hash = b0325fc
initialのコミットオブジェクトはルートなので親のコミットオブジェクトが存在しない

つまり impl5のコミットオブジェクトの hash = 1a804d9 からたどっていけば、コミット履歴が全部わかる
親が複数存在する場合には複数の親のhashを格納する
978 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 23:11:25.45 ID:zDjINlW+0.net]: >>930
￥で表示されるとちょっと見にくいが、慣れれば見やすい
979 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 23:14:09.84 ID:zDjINlW+0.net]: >>931
逆だ。コミットのつながりはコミットオブジェクトの中にしかない >>932 みたいにね
それを説明してるのが >>902
980 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 23:16:52.31 ID:zDjINlW+0.net]: >>930は最後のdevelopのマージが --no-ff になってないな
最後のも --no-ff にするともっと面白いぞ
981 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 23:18:09.46 ID:646uiMLL0.net]: >>932
ごめん、それは分かってる。
それはグローバル履歴＝gitオブジェクトを辿った履歴、だろ。

問題は、masterのcommitには b0325fc と 1a804d9 しかない、という情報が、
今のところ master の reflogにしか見あたらないんだよ。
だから、各branchを消したら、それ以前の gitオブジェクトは全部辿れるが、commit履歴は消失してしまう。
今のmasterみたいに、fast-forwardマージで中間をすっ飛ばしてきた、
という情報が無くなってしまうんだよ。
だから、branchを消す前の状態に完全には戻せない、という話。

だから、常識的に考えればもうちょっとましな何処かに保持してるはずなんだけど、無いんだ。
982 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 23:21:56.96 ID:646uiMLL0.net]: >>935
ほい
$ git log --graph --branches --oneline
* 2fb59f1 (HEAD -> master) Merge branch 'develop'
|\
| * 25e1b95 (develop) Merge branch 'feature5' into develop
| |\
| | * 4b27393 impl5
| |/
| * 9bfb8cc Merge branch 'feature4' into develop
| |\
| | * c2a5b7d impl4
| |/
| * 02d2308 Merge branch 'feature3' into develop
| |\
| | * f6d1cf7 impl3
| |/
| * 81e18bb Merge branch 'feature2' into develop
| |\
| | * 01c3871 impl2
| |/
| * 5b57f48 Merge branch 'feature1' into develop
| |\
| | * 0fe34d2 impl1
| |/
| * 6272da6 Merge branch 'feature0' into develop
| |\
|/ /
| * fe1b132 impl0
|/
* 832f464 initial
983 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 23:23:27.84 ID:zDjINlW+0.net]: >>936
FFマージしたらその情報は消滅するな
--no-ff で全部マージすれば複数親のハッシュをもってるコミットオブジェクトの1番目だけたどればいける
^1 だけみていくね
git log にはそれをやるオプションがあるはず

>>930をそのオプションで表示すればこんな風に表示されるはず

$ git log --graph --branches --oneline --オプション忘れた探せ
* a5aaf72 (HEAD -> master, develop) Merge branch 'feature5' into develop
* 324df68 Merge branch 'feature4' into develop
* 68ed20a Merge branch 'feature3' into develop
* 608e5d7 Merge branch 'feature2' into develop
* 3924eae Merge branch 'feature1' into develop
* 7db4424 Merge branch 'feature0' into develop
* ec041f9 initial
984 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 23:26:10.78 ID:zDjINlW+0.net]: >>937 だとこう表示されるはず
$ git log --graph --branches --oneline --オプション忘れた探せ
* 2fb59f1 (HEAD -> master) Merge branch 'develop'
* 832f464 initial
985 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 23:35:28.93 ID:646uiMLL0.net]: >>938
$ git log --graph --branches --oneline --first-parent
* a5aaf72 (HEAD -> master, develop) Merge branch 'feature5' into develop
* 324df68 Merge branch 'feature4' into develop
* 68ed20a Merge branch 'feature3' into develop
* 608e5d7 Merge branch 'feature2' into develop
* 3924eae Merge branch 'feature1' into develop
* 7db4424 Merge branch 'feature0' into develop
* ec041f9 initial

>>939
$ git log --graph --branches --oneline --first-parent
* 2fb59f1 (HEAD -> master) Merge branch 'develop'
| * 25e1b95 (develop) Merge branch 'feature5' into develop
| * 9bfb8cc Merge branch 'feature4' into develop
| * 02d2308 Merge branch 'feature3' into develop
| * 81e18bb Merge branch 'feature2' into develop
| * 5b57f48 Merge branch 'feature1' into develop
| * 6272da6 Merge branch 'feature0' into develop
|/
* 832f464 initial
986 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 23:41:19.40 ID:zDjINlW+0.net]: >>939がそう表示されるのは、--no-ff マージの手順が何か普通とちがうからかもしれん
>>939みたいに表示させるマージの手順もあるはずだから工夫してみるんだな
987 名前：デフォルトの名無しさん mailto:sage [2022/11/05(土) 23:41:56.11 ID:646uiMLL0.net]: >>938
なるほど了解した。
データ側に混ぜ込んでて、保持したければ --no-ff で使えってことか。

そもそも同じハッシュなら同じgitオブジェクトにリンクするようになってるのだし、
(つまり見た目が膨らんでるだけで実際の容量は
988 名前：大して食わない） --no-ff がデフォのほうがよかった気がするが。 まあとにかく了解した。長々とありがとう。 []: [ここ壊れてます]
989 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 00:38:34.83 ID:UPUgwCSv0.net]: FFがデフォじゃなと使いにくい気がするのだがｗ
990 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) mailto:sage [2022/11/06(日) 09:32:37.27 ID:OfQ8ymDc0.net]: >>943
ffがデフォのメリットって何だ？特にないと思うが。見た目すっきり、か？
ただまあ、デフォだし、サル先生他も特に何も言ってないので、ffでの運用が多数派なのだろう。

--no-ffはcommitオブジェクトが別に作られるだけで、
スナップショットに比べたらゴミなので全体としては大して増えない。
commit履歴はgitオブジェクトツリー内に混ぜ込まれ、完全に保持される。

ffの場合は、commit履歴情報はreflogにしか無いので、branchを削除したら基本的に失われる。
そしてreflogもgc対象なので、Linusはcommit履歴は基本的に保持する必要がないとの立場なのだろう。
また、branchを削除しろといいつつffなのは、その人達もcommit履歴は要らない、と考えていることになる。

ただこれは奇妙な実装だ。
カーナビを考えれば分かるが、当たり前だが地図情報とルート情報は別なのだ。混ぜ込むのはあり得ない。
commit履歴が要らないってのは、経路(線)は不問で、目的地(点)に着いてるかどうかだけだ、と言っているわけ。
それはバージョン管理の達人()にとっては、違うんだろ。バージョン管理は「線」であると！
ただ、Linusも「点」の立場だね。まあプログラマ的にはこれで正しいんだよ。
コンピューターは今現在のソースコードしか見てなくて、どの経路を辿ったかなんて関係ない。
だからどういう紆余曲折(「線」)があったかではなく、結局は前回の「点」と今回の「点」のdiffだけが価値を持つ。
そしてLinusの個人的ツールであるGitも、この流れなわけだ。

とはいえ俺はルート情報はまた別に重要だと思うから、保持したい。
混ぜ込まれてる場合は後からbranchを追加することが絶対に出来ない。
まあ開発ツールとしては別経路から同じ点に到達しました！なんてのは現実的にあり得ないから、
偽造を防ぐ為にもこれでいいのかもしれんが、一般的に考えればこの実装は奇妙だ。
ちなみに一般文書、例えばEULA(EndUserLicenseAgreement)とかの隙を潰していくタイプの法務文書等は、
別経路だが最終到達時点は同じ、ということが普通にあり得るはず。
だからやっぱりGitはソースコード向けにしか出来てない、ということは認識しておくべきだろう。
991 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) mailto:sage [2022/11/06(日) 09:32:57.06 ID:OfQ8ymDc0.net]: あと、Gitのドキュメントは全般的によく出来ているが、branchは「線だ！」と言ってるのは不適切だ。
Gitのドキュメントは密結合状態、つまりGitをよく知ってる人向けに書かれているので、
同様に内部実装を見せる形で書くのが正しく、
つまり、「branchは『線』のように見せてますが、実は『点』です！」と言わないと誤解される。俺がそうだが。
これは解像度が統一されてないから起こった問題だ。
一般のマニュアルは疎結合状態、
つまりそのツールについて内部実装なんて全く知らないし知る由もない人向けに書かれるから、
『見た目』線であれば「線」とずっと言い張り、内部実装を曝露してはいけない。
この場合、あくまでユーザーから見たら常に「線」であり、内部がどうであれ「線」としてしか見えないから誤解を生む余地はない。
Gitの場合は内部も見せた上でドキュメントとして外面仕様も説明することになってて、
それが外面仕様なのか内部実装なのか、
またbranchのように外面仕様と内部実装が�
992 名前：ﾙなってて隠蔽しきれてない場合とか、(--no-ffの有無で観測可能) それは正しく説明しなければならない。 密結合なら、上記の通り、「『線』として見せてますが実は『点』です！」と書くべきだ。 とはいえ全般的にドキュメントはしっかり書かれている。これ自体は素晴らしい。 ただ、そもそも仕様がグダグダ過ぎるし、 或いはユーザーにどこまで見せ、どこからは見せないのか、仕様を管理する感覚がまるでない。 おそらく上層部の連中に仕様管理の経験者がおらず、グダグダになってしまってる。 とはいえ、再度言うが、ドキュメントはよく書いてる方だよ。 []: [ここ壊れてます]
993 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) mailto:sage [2022/11/06(日) 09:33:22.07 ID:OfQ8ymDc0.net]: ただこれだと、branchを「線」として扱おうとしたら動作が不安定になるわけで、
おそらくfilter-branchが不安定なのはこの辺に起因してる。
そしてドキュメントの何処か(多分showかlog)に、
「これには実はpitfallがあって、マージに遭遇した場合に分岐するから云々」とかいう
(当時の俺にとって)謎の記述が挿入されてたのも納得がいく。
commit履歴を保持してないから確定的動作が出来ないんだよ。
これははっきり言って仕様の欠陥で、commit履歴も完全に保持する仕様だったら自然と回避出来てた。
現仕様では、filter-branchの実装をいくら頑張ったところでどうにもならない。
代わりのfilter-repoも、動作は同様に糞だろうよ。安定して使えるものではないはず。
ここら辺はちょっと惜しいね。Gitが素晴らしいのは、「伽藍とバザール」での
> 9. 賢いデータ構造と間抜けなコードのほうが、その逆よりずっとまし。
を体現してるからであって、つまり根っこがしっかりしてるから上部は雑草でも問題なかったんだが、
この点は根っこが駄目だから、上部(filter-branch)が機能しない。

ここら辺はちゃんと仕様の大切さを理解してる奴が仕切らないと駄目なのだが、
おそらくGitの連中も、仕様を捏ねてる連中は手を動かしてないと見なし、嫌ってるのだろう。
だから仕様を捏ねることすらしてない。
ただ、それは結局は遠回りでしかない。
今のGitだと、filter-branchも、filter-repoも、その次に出てくる何かも、まともに動作するはずがない。
駄目な仕様だと実装をいくら頑張ってもどうにもならない、と知ってる奴が、ちゃんと仕切らないといけないんだけどね。
ただこれは、それを知らない奴にとってはムカつく奴でしかなく、そいつらを排除した結果、Gitは暴走中、というわけだ。
Linusがcommit履歴も大切に考える奴だったら違ってたが、惜しいね。
994 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 10:57:26.83 ID:FBkt/oHG0.net]: 長々と無駄な長文と大量投稿でスレを穢すんじゃねー。
単に既存のバージョン管理ツールと、git の考え方の違いが理解できてないだけじゃねーか。
・git はパッチ管理ツール、作業履歴管理ツールじゃない。
・ソフトウェアはパッチとパッチを当てる順番で構成されている。
1000回唱えろ。この思想が気に要らなければそもそも git 使うな。
995 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 10:59:15.02 ID:OfQ8ymDc0.net]: >>943
と思ったが、ffじゃないとhashが違うからウザいな。別物扱いだから、一々確認いるし。
オブジェクトツリーはffの方がいい。

ただこれだとcommit履歴が無く、俺的にはまずいので、別に保存したい。
ソースと混ざるとウザイので、可能なら分離したい。
ドキュメントによるとマルチルートも出来るらしいが、これはどうやってやるんだ？
> Each project must have at least one root. A project can also have multiple roots, though that isn’t common (or necessarily a good idea).
996 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 1 ]: [ここ壊れてます]
997 名前：1:04:28.51 ID:OfQ8ymDc0.net mailto: >>947
> ・git はパッチ管理ツール、作業履歴管理ツールじゃない。
ああ非常に納得出来る。Gitはmerge特化型だ。
確かにそれを日々の業務(非merge)に使おう、というのがフィットしないんだろうよ。

しかし世の中の一般人のGitの使い方は後者だろ。 []: [ここ壊れてます]
998 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 11:33:11.11 ID:sj15aRfA0.net]: ということにしたいのですね。
999 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 11:46:16.67 ID:FBkt/oHG0.net]: >>949
お前の狭い世間なんて知るか
お前は話題の電動ドリル買ってきて釘打つのに不便ガンガンってやりながら文句言ってるのと同じレベル
そもそもマニュアルもちゃんと読めてないだろ。root と route を間違える英語レベル
背伸びして git 学ぶ前に高校に進学して英語学んだ方が近道だぞ
1000 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 11:51:22.62 ID:OfQ8ymDc0.net]: >>950
いや事実だよ。
Linusは確かにmergeしかしないんだろうけど。

だけどその、mergeするパッチを書く奴は、それを一発で書けたわけがないんだ。
何日もかけて、何回も直して、そこに到達してる。
この過程のサポートがGitにはない。
別branchで作業してもmerge時にhash値が組み込まれるから、
確かに俺がやろうとしてる「日々の進捗」をcommitされると除去出来ずウザイんだろうさ。
しかしパッチのコードは必ずGit-repoをクローンしてから出発するのだから、
Gitにこのサポートが無く、パッチを当てる人はいきなり完成したパッチを書け！勿論でバッグ済みだぞ！みたいな構造なのがおかしい。
すくなくとも、捨てbranch機能があって、そこで日々の作業を終わらせた結果、
mergeするときには本ブランチでその結果がいきなり生えたように見せる機能
(捨てbranchとmergeしても中身の結果だけもらって親にはしない）
みたいな機能が必要なんだよ。
ただまあ、これは今でも手動だと出来た気はするが。

だからまあ、確かにパッチ管理ツールであって、
ソフトウェア開発時のバージョン管理ツールではないんだろうさ。
だけど、今、全世界のGitで、mergeコミットと通常のcommit、どっちが多いか考えれば、自明だろ。
一つのパッチを作るまでにも何回もcommitが必要なのだから。
1001 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 12:07:06.70 ID:FBkt/oHG0.net]: >>952
アホか。共同開発が全く理解できてねーじゃねーか。
お前の試行錯誤の記録を push しようとしてんじゃねーよ。
手元で試行錯誤して実装できたら、それを元に綺麗なパッチに書き直す作業するんだよ。
そして完成した綺麗なパッチ群のみを共有リポジトリに公開するんだよ。
1002 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 12:19:51.48 ID:OfQ8ymDc0.net]: >>948
一応見つけた。 git worktree らしい。
複数のbranchを同時に開く機能で、DBで言うATTACHっぽい。
1003 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 12:20:57.36 ID:JyiC8cnE0.net]: 試行錯誤はすべて記録に残すべき
→じゃあテキストエディタで保存するたびに記録するべきっていうのか？

こういう話なので無視すんなよ？ｗ
1004 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 12:21:44.03 ID:JyiC8cnE0.net]: バージョン管理はソースコードの変更履歴を残すのであって
作業履歴を残すものじゃないっていうのが分かってなさすぎ
1005 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 12:30:26.14 ID:OfQ8ymDc0.net]: >>953
それはいいんだけどさ、その肝心のパッチを書く人へのサポートがまるでないだろ。
出発点がgit clone で、その上で作業して、終われば pull request する前提なのにさ。

そしてOSSではなく一般企業等で使ってる奴は、
当たり前だが日々の作業のバックアップや巻き戻し出来るシステムが必要で、そう使ってる。
だから、Gitが難しすぎるというのは、目的外使用だから意味が分かりにくい、というのはあるね。
Indexもマージの時には�
1006 名前：�った方が便利なんだろうしさ。(ただのcommitには邪魔でしかない） しかし確かに、Linusに言わせれば、全く問題ないんだろうさ。彼はmergeしかしないしね。 そして他のVCSよりまし、という理由でGitを使う奴は、混乱するんだろうさ。VCSと聞いてきたのだからね。 確かにパッチ管理システムだよGitは。ソースコード生成時のサポートシステムではない。 []: [ここ壊れてます]
1007 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 12:32:16.81 ID:OfQ8ymDc0.net]: >>955
> こういう話なので無視すんなよ？ｗ
無視する/しない以前に、何が言いたいのか分からないから反応しようがないんだよ。
1008 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 12:42:58.45 ID:sj15aRfA0.net]: >>957
> それはいいんだけどさ、その肝心のパッチを書く人へのサポートがまるでないだろ。
rebase あるよ。
元のローカルブランチを消さないでおけば記録もぜんぶ残るし。よかったね。
1009 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 12:43:13.14 ID:FBkt/oHG0.net]: >>957
git ほどパッチを書くのに向いてるツールは他にないぞ。
index 無しでどうやってパッチの分割とかするんだよ？
1010 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 12:53:16.71 ID:OfQ8ymDc0.net]: >>960
最初から一つずつ書けば分割の必要ないし、
Index無くてもdiffの出力を絞ってpatchに食わせれば普通に分割出来るだろ。
1011 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 13:02:38.08 ID:JyiC8cnE0.net]: >>958
書いてあるとおりじゃん。
試行錯誤の履歴を全部取れというなら、テキストエディタで保存するごとに
gitでコミットしなければならないはずだ
お前の主張はそういうことなんだから、それをちゃんとやれってこと
1012 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 13:04:02.78 ID:JyiC8cnE0.net]: >>961
コミットがメチャクチャなのに、どうやってdiffとってパッチできると思ってるの？
そのdiffには関係がない修正が大量に入ってるだろ
1013 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 13:37:22.28 ID:FBkt/oHG0.net]: >>961
なんも分かってないことを露呈しているな。
A,B,C,D,Eとコミットした後に Cはc1,c2,c3に分割すべきで、BとEは一つにすべきで、Aは不要だったと気づいたらどうすんの？
こういうのがお手軽にできて綺麗なパッチ群に整理できるのがパッチ管理ツールである git の利点なんだ。
そういうのやったことないだろ？
1014 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 13:39:49.06 ID:az1H5JFk0.net]: >>954
脊髄反射で理解したつもりになって書いてるだろ正解率が著しく低い

git worktreeは一つのリポジトリに追加のワークツリーを用意して、異なるブランチをそれぞれ別のワークツリーにcheckoutできるようにする機能
DBのATTACHとは全然違う

マルチルートは普通に作ったリポジトリをfetchやpushで合成してmerge --allow-unrelated-historiesすればできる
でもこれはかなり特殊な用途に使うもので普段使いするようなものではない
1015 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) mailto:sage [2022/11/06(日) 13:46:46.96 ID:OfQ8ymDc0.net]: >>965
実は今し方ドキュメント読んで、これは違うと書こうとしたところだった。
wor,ktreeはstashの代わりで、同時作業用ではないね。

> マルチルートは普通に作ったリポジトリをfetchやpushで合成して
ああこれは俺の要求とは違うね。

まあ、もう地味に.git/.xxx/に転がそうと思案中。
1016 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 13:57:15.91 ID:OfQ8ymDc0.net]: >>963,964
お前らunixコマンドの使い方知らないだろ。
patch/merge/diff3はgit以前からあるコマンドで、多分初期Gitはそのまま使ってたと思うが。

具体的な使い方は以下。
今、元 fileA に対して、変更後 fileC になってるが、実は中間の fileB が欲しかったとする。このとき、

cp fileA fileB
diff fileA fileC | less -N; // ここで該当行を確認する。例えば10-20行目なら、
diff fileA fileC | sed -n '10,20 p' | patch fileB

これでfileBが得られるんだよ。これ以上色々複雑な時用に diff3 とか merge もある。
だからパッチの分割はすぐ出来るんだよ。
1017 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 14:05:27.55 ID:az1H5JFk0.net]: >>967
そういう作業を必要で
1018 名前：無くすためにgitが生まれた patchの提出をgitの分散リポジトリ上で可能とするためにね 963とか964が行ってるpatchというのは、いわゆるpatchファイルのことではなく、ブランチ上に存在する差分の事 そのpatchを整理するのに index や rebase がある []: [ここ壊れてます]
1019 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 14:19:49.14 ID:FBkt/oHG0.net]: もしかして、もしかすると、git では「パッチ＝コミット」っていうことすら理解できてないのだろうか。
まさかそんな人はいないよね。単に言動が変な人なだけだよね。
1020 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 14:25:32.34 ID:OfQ8ymDc0.net]: >>968
知ってるよ。

ただまあ、確かにパッチ管理ツールだ。
プログラマはこれをソースコード管理ツールとして使おうとするから問題なのだろう。
バックアップが取れて、履歴が戻れれば何でもいいんだが、mergeも出来るから便利だからね。

なお俺は
> ブランチ上に存在する差分の事
も所詮はdiffだ、という立場だよ。だから元のunixコマンドで何とでもなるし、
それをシェルスクリプトで集大成したのが初期Gitだろ。
1021 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 14:31:58.60 ID:FBkt/oHG0.net]: >>970
ちがうぞ。最初からパッチ管理ツールとして設計されるぞ。
そしてパッチ管理ツールなんだから、パッチの出力機能さえあれば良いんだぞ。
それ以外の差分が欲しかったら別の外部ツール使えば良いんだぞ。それこそ基本だろ
1022 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 14:33:28.64 ID:OfQ8ymDc0.net]: >>969
各commmit「点」でdiff取ったときに落ちる情報って何？
ああcommitメッセージか？そんなのは知らんし要らんよ、って立場。

つか、commitメッセージガーなんて言い訳にならないから、
どのみちソースコードを確認するしかないんだよ。
commitメッセージはその手がかりとラベルに過ぎない。これが俺、というか多分普通のプログラマの立場。
お前らはcommitメッセージが間違ってたら、そいつに責任を負わせられるんだろうさ。
ソースコード読めないからね。

ソースコード読める奴ならこんな言い訳効かないんだよ、何でお前が上にいるんだ！監督する為だろ！になる。
さすがに素通しはヤバい。
そしてどう見てもヤバいパッチを素通ししてるから、なんじゃあこりゃあ？ってなってる。
1023 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 14:36:33.55 ID:OfQ8ymDc0.net]: >>971
ああそれが diff のデフォルト出力をさせない理由だな。
651から一周回ったが、なるほど色々状況は理解出来たよ。賛同はしないが。
1024 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 14:45:12.77 ID:FBkt/oHG0.net]: >>972
だからお前の考えてるような作業履歴管理ツールじゃないんだから、あきらめて他所へ行け。
gitはパッチ管理ツール。そしてパッチは何時、誰が、何のために作成したかが重要情報なんだよ。それを管理してるんだよ。
ソースコードの保管するツールじゃねーぞ。
1025 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 14:49:22.34 ID:OfQ8ymDc0.net]: >>974
そこは違うんだな。
みんな結局自分でやるのも作るのも面倒だから、既に動いてるツールを使ってるだけだよ。
Gitの機能のサブセットで十分にカバー出来るのなら、Git使えばいいだけ。
1026 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 14:56:19.71 ID:OfQ8ymDc0.net]: >>974
だからな、前言ったように、ブッ込んでおけば後で取り出せるバケツでしかないんだよ。
そのバケツにゴテゴテ付いてるから難しそうだが、要らない機能は使わなければいいだけ。
ただ、履歴保持の範囲を知らずに使って、実は記録されていませんでは困るから、使う前に調べてる。
1027 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 15:45:34.08 ID:o7v4FvnP0.net]: https://www.praha-inc.com/lab/posts/commit-message

そもそもコミットメッセージは何のためにあるのでしょうか？

コミットログのうちコードの変更履歴には「コードをどのように変更したか」という情報が含まれていますが、「コードを何故変更したのか」という情報はコミットメッセージを読まないと分かりません。機能追加、バグ修正、パフォーマンスのためなど、変更した理由は様々なものが考えられます。

もちろんコードを変更した本人に聞けば変更した意図はわかると思いますが、変更した本人にいつ�
1028 名前：ﾅも聞ける状況であるとは限りません。 「何故コードを変更したのか」という情報が欲しい時のためにコミットメッセージが存在します。 加えて、コミットメッセージは基本的に他人が読むものです。 他人というと同僚やコントリビューターなどが挙げられると思いますが、この「他人」には未来の自分も含んでいます。自分が書いたコミットメッセージを数ヶ月先の自分が読む場合、過去の自分のコミットメッセージを未来の自分が読むことになります。 つまり、コミットメッセージは自分以外の人のために存在するのです。 []: [ここ壊れてます]
1029 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 15:52:02.65 ID:az1H5JFk0.net]: まあこいつは分散バージョン管理の難しさを理解できていない
一人でしかプログラム組んだことがないのだろう
gitのややこしいと感じる仕様のほとんどは分散リポジトリ管理に起因していて、分散リポジトリ管理の問題をできるだけ明示的にシンプルに解決しようという意図で設計されている
1030 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 15:55:03.47 ID:JyiC8cnE0.net]: ほんとなぁ、POSIX原理主義だからユニケージだかUSP研究所だかしらんが
例のあいつも、バージョン管理のツールを、バックアップツールとしてしか考えてねぇ
だからとりあえずファイルを入れておけば差分はdiffで見れるだろとか
訳のわからんことを言い出す

ある時点とある時点の差を見たいんじゃねーんだよ
ある修正にどのような差分があるかを記録＝コミットしたいわけで
その記録なしに差分だけみれても役に立たないっつーの
そこが根本的に違うというか、バージョン管理の役目がわかってない
1031 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 16:10:07.15 ID:az1H5JFk0.net]: 「ブッ込んでおけば後で取り出せるバケツ」など言っているが、
必要とされていたのは内容を同期できる複数のバケツで、
なおかつバケツ同士が常にオンラインで通信しているわけではない
そういう問題に取り組んだ結果だ
1032 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 16:12:28.94 ID:az1H5JFk0.net]: そういう魔法のバケツを生み出すために、ただのバケツならできることがgitでは制限されていたりもする
ユーザから見て不自由のない完全な魔法のバケツを生み出そうとしたプロジェクトは複雑すぎてことごとく失敗してきた
1033 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 16:14:37.71 ID:JyiC8cnE0.net]: バケツの中に入っている袋詰めの塩や砂糖を、一つづつ取り出したいのであって

バケツの中に全部入ってるから、遠心分離機でも使って
取り出せばいいだろうじゃないんだよなｗ
1034 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 16:36:01.68 ID:az1H5JFk0.net]: 前スレは消費に1年半かかってるのに、このスレは半年ぐらいで終わりだな
次スレ立ててみるけど失敗したらゴメン
1035 名前：デフォルトの名無しさん [2022/11/06(日) 16:41:37.94 ID:az1H5JFk0.net]: 次スレ
Git 19
mevius.5ch.net/test/read.cgi/tech/1667720427/
1036 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 19:18:45.16 ID:OfQ8ymDc0.net]: 相変わらずお前ら盛大に勘違いしてるが、とりあえず、

× Gitはパッチ管理ツールである
○ Gitはパッチ適用ツールである
○ Gitはパッチ記録ツールである

としよう。管理は出来てない。何を管理すべきか分かってないから。
commitメッセージなんてただのラベルに過ぎない。
1037 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 19:19:20.86 ID:OfQ8ymDc0.net]: 例えば今回俺が送った再現コード、あれはどこに配置されるのだ？
>>977の通り、「何故この変更を行ったのか」の完全情報がそこにある。
まさか捨てたりしないよな？

バグパッチに於いて、重要な物から順に、

1. そのバグを修正するコード
2. そのバグを再現するコード
：
10000, commitメッセージ

だ。どんなに丁寧にcommitメッセージを書いたところで、「それ、あなたの感想ですよね？」でしかない。
肝心なところを書き間違ってるかもしれないし、信用も出来ない。
この点、再現コードは情報が完全で、全ての情報を過不足無く含んでいて、曖昧さもない。
だからcommitメッセージの情報価値なんて再現コードと比べたらゴミ以下で、
再現コードに対してのリンクで十分なんだよ。つまり、

○年○月○日に○○から送られてきた○○のバグ(メモリリーク
1038 名前：)を修正する。 詳細はXXXX で、XXXXのところ、Git流ならSHA1ハッシュで、 その中に再現コードと詳細、今回なら全員のメールの全文を入れておくのがバグ管理だよ。 これで、「何故この変更を行ったのか」の完全情報が保たれる。 そして、再現コードは今後ずっとregressionテストに使う資産にする。 そうすれば、少なくとも過去と同じバグはリリース前に見つかる。 []: [ここ壊れてます]
1039 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 19:20:02.27 ID:OfQ8ymDc0.net]: こうなってないだろ。一回パッチ当てて動きました！満足です！じゃないんだよ。
繰り返すが、commitメッセジーをいくら丁寧に書いても意味無い。
再現コードに比べたら本当にゴミ以下。
逆に、再現コードに辿り着けるのなら、後はラベルが正しく付いてれば十分なんだ。
それ以上の情報は、commitメッセージのテキストではなく、
再現コードとバグ報告＝完全情報を見た方がいいから。

で、GitHubはまあこれに近いよ。
そもそもバグ報告自体Webだし、少なくともIssueからバグの完全情報に当たれる。
Gitはどうなの？
今回の俺と同様の、過去のバグ報告の再現コードを生かせてるのか？
ならそういうディレクトリがあって、
bug_patches/XXXXXなハッシュが名前になってるディレクトリに再現コードその他がブチ込まれてて、
出荷前(というのもおかしいが)には全部一通り通せ、となってるはずだけど、
どう見てもそうなってないでしょ。
パッチ当てたから満足です、で終わってる。

こんなのでバグが収束するはずがない。
同じ連中が書いてるのだから、放置したら同レベルのバグを繰り返す。
だから本来は何故こんなバグが発生したのか？からコード構造を見直して、
そもそもそうならないようにするのだけど、そういう学びもないし、(だから基本すら出来てない)
regressionテストのネタにもしないのだから、今後ともバグだらけだよ。
ああ、Gitの達人揃いだから、「記録」は出来てるのだろうよ。だけどそれは「管理」ではない。

ただ、これがバザール流だ！と来るなら、はーそうですかー(棒)だよ。
目も手も数が違うし、俺には何が最適か分からんし。
1040 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 19:20:37.38 ID:OfQ8ymDc0.net]: ちなみにchromeの連中は気持ち悪いほどregressionテストしてるぞ。
本来は、ああするべきなんだろうよ。
regressionテスト自体はタダ(スクリプトで自動実行)だからね。

バグ「管理」というのなら、原因を究明して、少なくとも同じバグが出ないようにしないといけない。
それはcommitメッセージをいくら丁寧に詳細に書いても、達成出来るものではない。

分かりやすく言うとな、「体調管理」と言われれば、少なくとも同じ原因で風邪を引かないようにするだろ。
なら、「バグ管理」なら、最低限レビューしてregressionテストしないと駄目だよ。
それはcommitメッセージ云々では出来ない。だからパッチ「適用」「記録」ツール。
1041 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 19:24:47.08 ID:VM2X6i580.net]: >>985
> commitメッセージなんてただのラベルに過ぎない。

その言葉からお前がわかってないのが明らかなんだけど？
1042 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 19:26:23.98 ID:VM2X6i580.net]: >>988
うん。だからそのchromeはここまで徹底してコミットを管理してる
それを見習え
https://github.com/chromium/chromium/commits/main
1043 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 19:27:42.33 ID:VM2X6i580.net]: regressionする際にもコミットを管理するのは重要で
コミット単位で戻してテストする
動かないコードをコミットすることはない
お前みたいにテキストエディタで修正するたびにコミットとかしない
1044 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 19:28:57.43 ID:VM2X6i580.net]: なんでchromeのコミットメッセージが
こんなに詳しく書かれているのか、その理由を考えたら？
1045 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 19:32:31.47 ID:VM2X6i580.net]: バージョン管理はソースコードの変更履歴を管理するものなので
そこにバグ管理という別の概念を持ち出すのも頭悪い
バグ管理は別のツールでやれ
1046 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 19:55:47.23 ID:sj15aRfA0.net]: >>986
> 例えば今回俺が送った再現コード、あれはどこに配置されるのだ？
修正コミットのログから URL で辿れるようになるかな。
https://public-inbox.org/git/20221102220142.574890-2-szeder.dev@gmail.com/
1047 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 20:08:52.18 ID:OfQ8ymDc0.net]: >>994
それは鯖に置いてるだけだろ。まあそれはそれで十分で、（この意味では最初のMLでも十分)
問題は、

1. .git上、つまりソースコード改変ツリーから簡単に辿れるよう、
commitメッセージにそのリンクは落とされている(落とされる予定）なのか？
そうじゃないと>>977が達成出来ないだろ。
2. そしてregressionテストパターンとして登録され、今後ずっと実行されるのか？
3. そもそも根本の原因はソースコードの程度が酷いことであり、レビューしろよマジで

だよ。
レイヤーの考え方がない奴等ばかりなので通じないかもしれないが、
gitは適用/記録という下層レイヤーであって、バグ/パッチ「管理」は上位レイヤーの戦略だから、
gitで「管理」出来ると思ってるのが間違いなんだよ。記録は出来るが、管理は出来ない。
gitで出来るのは上の1だけだね。
だからcommitメッセージは勿論丁寧に書くべきなんだけど、丁寧に書けばいいわけでもないんだ。
それでバグやパッチが減るわけでもないから。
目的と手段の混同はどの界隈でもあるけど、ここの連中も大概だよ。 []; [ここ壊れてます]
1049 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 20:11:50.13 ID:OfQ8ymDc0.net]: >>994
と思ったがすまん、見落とした。

> 修正コミットのログ

つまりこれ、コミットメッセージそのものなのか？
ちょっと確認したいんだが、どこ見ればいいんだ？GitのGitHubから？
1050 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 20:22:10.42 ID:sj15aRfA0.net]: >>996
そう。コミットメッセージを含めてML上でレビュー中。まだ本体リポジトリには入ってない。
挙がってるレビューコメントを受けてそのうち第２弾が投稿されて取り込まれるんじゃないかな。
君もソースコードの質が気になるなら修正を送ってくれていいんだよ。さぁさぁ。
1051 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 20:38:50.28 ID:OfQ8ymDc0.net]: >>997
つまりあれがそのままに近い状態で入るのか？
まあそれは見守るとして、本来はちゃんとラベルを付け替えないとまずい。

俺が送った段階では高い確率で「free忘れによるメモリリーク」と推定出来たが、
断定は出来なかったので、単に「メモリ食いすぎ」としてる。
だから、メモリリークだと「断定」出来た人が概略を書き直さないといけない。

が、まあ、これは多分為されるだろう。見守るよ。

> 君もソースコードの質が気になるなら修正を送ってくれていいんだよ。さぁさぁ。
これは本質的に無理だ。多分俺、というか、いわゆるCコードを拒絶すると思うよ。
間違いなく、連中は自己の能力に自信持ってて、傲慢で、言うこと聞かない連中だ。
世の中のCコードなんて、基本通りやってる物でほぼ全部だから、見たこと無いわけが無い。
それが何故そうなってるか理解出来ない、
つまり、王道を王道と理解出来ない奴等だからデタラメやってるわけで、
言うこと聞く連中ならそうはならない。

通常だと、やらせるだけやらせて、でもどうにももうダメポなときに、
そもそもお前のコードがおかしい、ここをこう直せ、なら簡単にメモリリークは抑えられる、とすると効くのだろうけど、
問題はバザールで、無限にモグラ叩き出来てしまって、実際にそれでやろうとしてることだよ。
マジかー、って、ちょっと驚きだが、まあ観戦だ。
ああちなみに、俺以外の誰でも、まともなC書ける奴なら、ちょっと引くコードだよ。
だからそこら辺の奴等に書かせても、もっとましなコードになるよ。そして俺もその程度だし。
というか単発のコードでそんなに技量の差なんて出ないし。
1052 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 20:40:54.42 ID:VM2X6i580.net]: >>998
お前がちゃんとやれって言われるだけだよ
お前雑なんだよ。無能なのに張り切るな。空回りしてるぞｗ
1053 名前：デフォルトの名無しさん mailto:sage [2022/11/06(日) 20:46:49.73 ID:wlljBD17M.net]: 質問いいすか？
1054 名前：1001 [Over 1000 Thread.net]: このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 197日 17時間 21分 4秒
1055 名前：過去ログ ★ [[過去ログ]]: ■ このスレッドは過去ログ倉庫に格納されています

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

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