Git 19

2022/11/06(日) 16:40:27.51

ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。

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

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

◆前スレ
Git 17
https://mevius.5ch.net/test/read.cgi/tech/1599016710/
Git 18
http://mevius.5ch.net/test/read.cgi/tech/1650651945/

VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

2023/05/09(火) 17:30:01.20

>>541
人が目で見て解析できる書き方はされてないから無理じゃないかな、と試みて諦めた事はある。
xlsx は、共同編集できるし、SharePointならバックアップに戻れるしで他所の製品凄いと思っている。

2023/05/09(火) 19:03:05.97

>>539
tex か簡単なときはmd ですね
公開とデバグの順序でgitを使うべきか決めることに違和感があったので文書の例を挙げてみたんです

2023/05/09(火) 21:06:02.48

>>541
自分ですら絶対にやらないことを人に勧めるものではないよ。
ただそもそもExcelには差分表示機能があったはず。

つか、515って普通に背任案件の気がしてきた。
git信者が布教するなら、普通は「『僕が』インストールして回って、教育もしますから、一緒に頑張りましょう」だろ。
全く知らん奴に全部やらせるのは、明らかにおかしい。失敗するに決まってる。

>>543
君が使ってて君がそれでいいんならそうだねとしか。
しかしmdってMarkdownかー。時代は変わるもんだね。
今時HTML手打ちってどんな奴よ？と思ってたが、Wordの代わりに使ってる奴居るのね。

2023/05/09(火) 22:00:19.19

>>544
作るとか言ってたなんとかツールは結局どうなったの?

2023/05/09(火) 22:20:30.89

ズレたコメントするから長文くんてすぐにわかるねw

2023/05/11(木) 13:20:24.80

だって >>515 自体、読んだ瞬間に嘘ネタって分かるもの。

ドキュメントの履歴管理したいならMicrosoft365のSharePointだけで実現できるし、タブレットが
なんか知らんがandroidやiPadなら英語版しかないGitクライアントなんかPC初心者に扱える訳なくて
どんなに無能なコンサルでもGitなんか提案してくる訳ないから。

2023/05/11(木) 13:35:23.92

>>547
「だって」って何なんだろ
話がつながらないんだけど

本当に「読んだ瞬間に嘘ネタって分かる」ようなものなら
スルーするか「嘘ネタ乙」で終わりにすればいいようなものだけど
長文くんらしき人もそうしてないんだよな

2023/05/16(火) 20:12:24.34

Git v2.41.0-rc0

2023/05/20(土) 03:22:53.91

Git v2.41.0-rc1

2023/06/02(金) 21:08:39.93

Git v2.41.0

2023/06/08(木) 21:49:01.57

3点質問させてほしい

次郎と太郎は、Aブランチにチェックアウトしている時に git branch -u origin/A コマンドを実行したことがあるとする。

次郎がまずAブランチにpushをした。

次に、太郎がAブランチの内容をpull(①git pullじゃなくてgit pull originと打ってやる必要がある？？)して、少し変更を加えてAブランチにpushした。

最後に、次郎がAブランチをBブランチにマージしたい。
そのためにローカルリポジトリを最新化する必要があるはず。
②この時、次郎はAブランチにチェックアウトしている状態で、git pull originと打てばいい？それともgit pull origin Aと打たなきゃダメ？

③Aブランチにチェックアウトしている時にgit pull originを実行するとローカルのBブランチも最新化される？

自分で試せばいいじゃんと思う質問もあるかもしれないけど、git初心者すぎていずれも試そうとしたけどよくわからんかった

すまんが知恵を貸してくれ

2023/06/08(木) 22:33:33.64

git fetch origin
git branch -f B origin/B

2023/06/09(金) 00:04:51.74

git は動作をカスタマイズできるのでカスタマイズしてない前提で
① git pull と git pull origin は全く同じ動作。 origin の全ブランチを取得してローカルを更新
➁ git pull origin A は origin からブランチ A だけ取得してローカルのAを更新
➂ 上の2つ見れば分かるだろう

2023/06/09(金) 23:02:05.34

>>554
回答ありがとう
②についてだけど、もしBブランチにチェックアウトしている時にgit pull origin Aとやったら、ローカルのBブランチにoriginのAブランチの内容が反映されるの？

2023/06/10(土) 01:16:50.63

>>555
されない。pull の場合、今どれをチェックアウトしてるかは関係ない。あくまで origin の A を取って来てローカルの A を更新

2023/06/10(土) 01:38:23.55

ややこしいの考える前に基本の使い方を覚えろ。B に A をマージしたいんなら慣れるまでは
git pull （AとBを最新に更新）
git checkout B （Bを対象にする）
git merge A （BにAをマージする）
git push （今更新したBをプッシュ）
としろ。

2023/06/21(水) 08:18:04.06

gitって個人で使ってる分にはなんてことないけど
複数で使うと途端にいろんなトラブル起きるなぁ
ソフトを開発することが仕事なのに、ソースを管理することが目的になってる人もいるくらいw

2023/06/21(水) 08:55:55.22

>>558
別にそんなことないけど

2023/06/21(水) 09:27:39.89

Gitがトラブル起こしてるんじゃなくてGitを運用してる人がトラブル起こしてるんじゃないの
開発規模にもよるとは思うけどただ導入するんじゃなくてある程度運用ルール決めないとみんな自由気ままに使ってめんどくさくなるだけだと思う

2023/06/21(水) 09:41:11.46

>>559
別にそんなことないけど

2023/06/21(水) 10:59:35.25

具体的にトラブルの事例書いてくれ

2023/06/21(水) 12:07:34.93

複数で使う＝低レベルプログラマーが使う
という事ではないから必ずトラブルが起こるなんてことはない

2023/06/21(水) 12:13:40.13

>>558
同感だが、理由は、Gitはパッチ管理ツールであって、ソースコード管理ツールではないからだ。
Gitをソースコード管理ツールとして見た場合、典型的にはGitHubFlowなんて敗北そのものだが、
このスレの連中は信者だからこれにも気づけない。

ただ、パッチ管理ツールとしては極めて優秀だよ。
だから他のろくでもないソースコード管理ツールの代用とされているわけだが、やはり無理がある。
なお、信者は常に「運用が悪い」と考えて「Gitの不備」とは認めないから、このスレでは会話は成立しない。
ネットで言えば、「岡山の用水路」だね。
「落ちる奴が悪い」か「落ちるような構造なのが悪い」か。

2023/06/21(水) 12:24:57.58

>>564
君の使い方の参考になる資料のリンクを下さい。

**デフォルトの名無しさん** (JP 0Hd5-iIiP) · 2023/06/21(水) 12:33:39.30

>>564
お？
WitBucketくんかな？

2023/06/21(水) 14:38:02.37

>>564
長文君はまず自分の仕事したら？

gitがパッチ(変更)管理ツールなのは同意だが、ソフト開発に必要なのは変更管理ツールであって、素人の欲しがるようなソースコード管理ツールではないという点に気付いたら戻って来てね

2023/06/21(水) 14:53:26.93

git は「いつ、誰が、何のために、どこの、何を、どのように」変更したかを管理するツール。
5W1H だな。注目すべきは「何のために」

2023/06/21(水) 16:32:39.23

gitがパッチ管理ツールとかもう少し勉強してからきてほしい

2023/06/21(水) 16:42:42.46

うわぁめちゃめちゃしょうもない「自転車置き場の議論」に触っちまったみたいだ
みんなごめん

2023/06/21(水) 17:12:19.88

いつどいつがどのようにしてソースに変更加えたか犯した罪を記録して行くツール

2023/06/21(水) 17:36:57.91

>>570
「パーキンソンの凡俗法則」か
>自転車置き場については誰もが理解している（もしくは理解していると自分では思っている）ため、
>自転車置き場の設置については終わりのない議論が生じることになる。
>関係者の誰もが自分のアイデアを加えることによって自分の存在を誇示したがるのである。

2023/06/21(水) 17:50:22.17

>>567
何が言いたいのか意味が分からん
南朝鮮の人？

2023/06/21(水) 18:01:06.09

トラブルとやらの事例がまだ出てきてないので
gitの設計上の問題か使い方がアホなのか
判断できないのではよよろしく

2023/06/21(水) 20:42:01.85

>>573
どうしても知りたかったら過去のやつ嫁。
お勧めはしないが

2023/06/21(水) 21:20:08.79

混乱してる人のために書くと
gitスレには「長文君」と呼ばれるアンチが住み着いていてな
「gitは難しすぎるし品質が悪いゴミ、git信者は難しいのを強要する悪、素人が求めているソースコード管理はゴミ箱」というのが持論なんや
「オレが理想のソースコード管理ツール作って売る」といって専用スレまで立ち上げたんだが絶賛放置中でな
今もgitスレにいて、詳しい人には太刀打ちできないので、素人っぽい質問が来た時に湧いて出て持論を展開するんや

2023/06/21(水) 21:35:02.59

>>564の「ソースコード管理ツール」の定義はどういうものなんだろうな。
あんまり他人に伝わらないオレオレ定義のような気がするが。

2023/06/21(水) 22:51:16.49

>>558
ついでに言っておくと、Gitが改善することはない。未来永劫このままだ。

Linusにとっては、確かに今のGitで何も問題ない。
Git信者にとっては、Gitは完璧であり全ての問題は使用者に起因している。
結果、Git陣営には改善能力がない。問題なんて、そもそも存在しないのだから。
よって、今君が感じてる問題は、今後も改善することはない。

ここ見てたら納得だろ。

2023/06/22(木) 00:58:48.76

>>578
お前みたいな簡単なアプリケーション一つ満足に作れないやつが何言っても説得力ないんだよ

日常の進捗履歴記録ツールWitBucket(仮称)検討中
https://mevius.5ch.net/test/read.cgi/tech/1668901194/

アプリの名称とかいうどうでもいいところにこだわって何も作れなかったくせに

**デフォルトの名無しさん** (JP 0H91-4s7H) · 2023/06/22(木) 01:14:56.37

>>578
Linuxと同じ轍を踏むな、こりゃ

2023/06/22(木) 01:23:15.85

自演かな？

2023/06/22(木) 02:31:42.28

構うのもそこそこにしとき
キリがない

2023/06/22(木) 08:22:03.78

git pull A
は
git checkout A
git fetch origin A
git merge FETCH_HEAD
と同じ？

2023/06/22(木) 09:55:40.82

トラブってネットで調べてる暇があったら

cloneしてきて、手作業でマージした方がはやいよな

単なる共有のストレージとしてしか、使ってないわ

2023/06/22(木) 11:16:39.70

git log graphで作業できるツールって公式にあったっけ？ vscodeのgit graph extensionみたいなの。

ソースコードにしろ何にしろ、管理をサポートする気ならGUIは必須だと思うけど、公式はGUIやる気無いんかな。

2023/06/22(木) 11:20:36.66

>>585
gitk

2023/06/22(木) 15:46:02.12

>>583
git pull origin A
と
git fetch origin A
git merge FETCH_HEAD
が同じかな。checkout はしない。あと origin 省略すんな

2023/06/22(木) 15:47:57.34

>>584
それでも良いけど、最新版のソース欲しいだけなら tar か zip で落としてきた方が早くないか？

2023/06/22(木) 19:16:31.45

>>584
トラブルって単なるコンフリクトのこと？

2023/06/22(木) 20:21:01.56

>>589
なんでコンフリクトがトラブルなんだよwww
初心者か？

2023/06/22(木) 21:09:14.79

>>590
じゃあ手作業でマージした方が早いトラブルってなに？

2023/06/22(木) 22:31:06.05

ブランチがあちこちにあるヤツとかモジュール貼ってるけどバージョン管理適当なヤツでもってくるとコンパイル失敗するとか

2023/06/23(金) 00:53:10.41

ブランチ更新したは良いけど本体の持って来かたがわからず詰んだ
旧本体からのブランチで新本体を持って来るのはどれだ……？チェリーピック？新本体に切り替えたらブランチで更新したやつ消えるよね？

2023/06/23(金) 01:46:48.97

git reset --hard 新本体

2023/06/23(金) 02:03:39.42

本体って何だ？

2023/06/23(金) 03:33:05.35

新本体に切り替える前にコミットすればいいのでは

2023/06/23(金) 08:07:28.92

コマンド打ってるやつを見ると、誰でも知ってるし
ネットを漁ればいろんなところに書いてあるようなのばっか。

そんなのGU Iならワンクリックだわ。

オプションを5個も6個も並べて令和人を見たことがない
愚直にgit push
wwwww

2023/06/23(金) 08:49:33.29

標準でSourcetreeぐらいのクライアントは欲しいところ。

2023/06/23(金) 08:59:09.98

git 普通に使ってオプションを5つも6つもつけることとか滅多にないぞ
どんな使い方してるんだ？
知能が足りてないんじゃないか？

2023/06/23(金) 09:19:08.37

複数のオプションを並べないといけないならそもそも設計が終わってると思う

パイプで複数のコマンドを繋いでるとかならまだ理解できるけど

2023/06/23(金) 12:18:23.80

議論の本質が分からず、そこ？なんてところを掘り下げる頭の悪い人いるよね

2023/06/23(金) 12:49:56.85

こいつはバケツくんとは別人かな？

2023/06/23(金) 13:47:38.17

GUIの用語で説明しても他のGUIアプリ使ってる人には伝わらないから共通語としてコマンドで説明してるだけ

2023/06/24(土) 00:54:58.63

>>558
> ソフトを開発することが仕事なのに、ソースを管理することが目的になってる人もいるくらいw
さらについでに言うとな、Gitプロジェクト自体が既にこうなっている。

見れば分かるが、Gitのソースコードは素人以下のゴミで、
Gitプロジェクト自体が、手の込んだ金庫に大切にウンコを保管している状態だ。
個人的には履歴管理以前にソースコードを改善する努力をするべきだと思うよ。

まあ「手段の目的化」はどこでもある話だが、Gitは多分にそうなりやすい。
これはGitの難易度が中途半端で、>>570の通り、「自転車置き場の議論化」するからだ。
「そのソースコードが美しいか、適切か」(≒原子炉の話)には全く付いていけないから、
「Gitのつかいかた」(≒屋根の色)で「自転車置き場の議論」をしてるのがこのスレだ。

信者ならあの糞コード何とかしろよ、と思うけどな。
お前らにその能力がないのは了解してるが、
それはお前らがコードを管理することに注力してるから、肝心のコードを書く能力が全く上達してないだけだし。

2023/06/24(土) 01:18:56.93

出た長文君

2023/06/24(土) 02:27:10.04

>>604
長文君は自分の仕事にもどれ

2023/06/24(土) 03:20:37.66

長文くんはツンデレだからgitの素晴らしさを素直に認めないし、表現力皆無だから下手くそな例えしかすることができない

2023/06/24(土) 03:42:45.08

malloc() に関して
初級者：free() することを学ぶ
中級者：free() しないことを学ぶ
上級者：本当に必要な時のみ free() する
長文君は初級者なので、中級者や上級者のコードが理解できないのが笑いどころ

2023/06/24(土) 03:48:07.31

黙ってNGせーや

2023/06/24(土) 08:45:58.77

>上級者：本当に必要な時のみ free() する
>長文君は初級者なので、中級者や上級者のコードが理解できないのが笑いどころ

同じ臭いがするんだが。

2023/06/24(土) 09:33:11.70

gitのソースが綺麗だとgitの使い心地にどう関係あるの

2023/06/24(土) 09:40:16.93

>>608
今は上級者はrust使うだろ

2023/06/24(土) 13:05:33.61

俺は単に冷静に状況を把握してるつもりなんだけどね。
色々整合性も取れてしまったし、多分そこそこ合ってる。

ソースコードの品質は、判断出来るなら自分で見るのが一番納得するだろう。
ここで水掛け論する意味はないし、議論出来る相手がいるとも思ってない。

Linusが奇妙なほどCVSに対して攻撃的な事については、
実は今現在の俺はLinusのCVS体験をGitで追体験してるだけだとも分かった。
なるほどボロクソにしか言わないのも納得ではある。
ただLinusもアプリに対する人間的な本質部分を修正してないので、
歴史が繰り返し、俺も強制的に追体験させられてしまってる。
この点、巻き込まれた被害者としては、あんたもそこまで言えるほど修正出来てねえよな、とは思う。
(まあLinusはGitをCVSの代替として作ったわけではないので、知らんがな、だろうけど)

あと何か、Git界隈で傍から見て謎な件あったっけ？

2023/06/24(土) 13:06:05.33

>>611
表面的には『関係ない』。ここがミソだ。
実際、ソースコードが糞であっても、アプリなんざ動けばいいのは事実。

ただ一般的にはメンテナンス性を上げる為に品質を保ち、結果的にアップデートが早くなる。
或いは、グチャグチャすぎてアップデート出来なくなるのを防ぐ。

俺の場合は、少し踏み込んだらバグに当たってしまったので、
少なくとも今のGitは俺が安心して使える品質ではないこと、
コードの品質を見る限り短期的には、戦略見る限り長期的にも、改善しないことは分かった。
結果、俺の使い方だと、Gitを使って得られる時間より、Gitを使って失う時間の方が多く、
俺はGitは出来るだけ触らない方針で行くと決めた。

ただ、これまで散々使い倒してきてて、全くバグに遭遇したことがないのなら、
少なくともその使い方では問題ないのだろうから、使い続ければいいと思うよ。

いずれにしても単純に、「Gitを使って得られる時間」と
「Gitを使って失う時間」を比較して決めればいいだけだ。ただのツールなんだし。
(そして初心者の内からGitに精を出し始めると、
本来コードと格闘すべき時間がGit関連に配分され、肝心のコード記述能力が上達しなくなる。
これは初心者は本当に気を付けた方がいい。
そして既にそうなってるのがこのスレやGit周りの連中だ。
だからあんな糞コードでも糞だと認識出来ないわけでね)

2023/06/24(土) 13:14:59.19

>>613
ツールの方はどうなったのか現況くらい報告してもいいんでは

2023/06/24(土) 13:55:42.57

「水掛け論だから俺の好きなように水かけさせろ」

2023/06/24(土) 14:08:47.40

>>616
それはお前もな。

実際、お前自身が確認する以外でお前が納得する方法はないだろ。
ならそれで終わりにするしかない。
対案はないが反対するだけの人種ですか？

2023/06/24(土) 14:16:38.34

>>587
ありがとう。最後のorigin省略するなっていうのは、originを描き損ねるとローカルリポジトリの該当ブランチからマージされてしまうことになるからということだよね？

checkoutは必要ないとのことだけど、
現在masterブランチにcheckoutしている場合、
git pull origin A
だと、ワーキングツリーには変化なし。
もちろんmasterブランチの中身(ソースコードなど)にも変化なし …であってる？

2023/06/24(土) 14:18:00.22

長文君は同じ主張を繰り返してないで自分の開発に戻れ
「必要とされているバージョン管理システムをオレが作って見せてやる」
って言ってたお前はどこにいった？そこで好きなだけ「綺麗」なコード書いてればいいじゃないか
ここはお前の嫌いなgit信者の巣窟なので寄り付くな

2023/06/24(土) 14:21:04.91

>>618
状況にもよるが origin 省略して git pull A ってやると A がブランチ名じゃなくてリポジトリ名と解釈されて A なんてリポジトリ知らねってなるからだよ

2023/06/24(土) 14:26:32.80

>>618
naster ブランチをチェックアウト中に git pull origin A ってやると
1) origin の A を取ってきて、ローカルの origin/A にマージ
2) その後にローカルの origin/A をローカルの master にマージ (working tree も更新)
という動作になる

2023/06/24(土) 16:44:15.37

>>619
ゆとりだね。相変わらずお前らは「ぼくはぜったいだいせいぎ！！！」と信じて疑わない。
俺は反撃してるだけ。反撃されたくなければそもそも攻撃しなければいいだけ。

そしてここがGit信者の巣窟だと知ってるからこそ、
それが問題な場合には俺なりにアドバイスをする事はあるよ。
結果的に大体においてGit信者とは異なる意見になるが、
どちらが正しいかは当人に判断して貰うしかない。まあいつもの5chだ。
逆にコマンドの使い方なんて信者に聞くのがベストだし、実際俺もそれに口挟んでないでしょ。

2023/06/24(土) 17:00:34.99

>>617
だからあんた、その長文を他人に理解してもらおうと思って書いてないわけだろ？

2023/06/24(土) 17:27:14.85

>>622
WitBucketはもう止めたんか？

2023/06/24(土) 17:53:52.56

頑なにゴミ箱に触れないあたりがいい答え合わせになってるわな

2023/06/24(土) 18:09:33.70

質問が続きそうなので予め書いておくと
master をチェックアウトしている状態で git pull origin A とするのは推奨されない（少なくとも初心者のやることではない）
ローカルに
- master
- A
- origin/master
- origin/A
という４つのブランチがあって、master がチェックアウトされている状態で git pull origin A とすると
- master ← 更新される
- A ← 更新されない
- origin/master ← 更新されない
- origin/A ← 更新される
というチグハグな状態になる
git pull は常に引数つけずに使うものと思っておくべき（初心者のうちは）

2023/06/24(土) 19:14:45.47

>>623
それだと意味が曖昧なので厳密にすると、
俺が何を言ってるかの「理解」は出来るように書いてるよ。勿論「同意」はしなくていい。
俺はGit信者だけからの偏った見方に反対意見を付けてるだけだから。

逆にお前こそ、「理解」というこの状況に於いて意味が曖昧な単語を使って意図的に混乱させてるよね。
その辺がゆとりの問題だよ。

2023/06/24(土) 19:19:57.81

>>626
そもそもpullは使うべきではなくfetch とmergeを別々に実行するほうがいい。

特に初心者はpull禁止にすべきだと思うけど、解説とかでpullから解説しているのはなぜかね？

2023/06/24(土) 19:22:04.78

>>627
でバケツだかゴミ箱だかはどうなったんだ？
誰にも理解できねーぞ！

2023/06/24(土) 19:42:42.59

>>628
さすがに禁止はないとかと
git switch master
git fetch origin master
git merge origin/master
みたいに毎回打ってるの？
普通は
git switch master
git pull
でいいだろう？これが一番事故が少ないしタイプも楽なはず

2023/06/24(土) 19:50:47.60

つまり>>616ってことだろ

2023/06/24(土) 21:22:08.93

>>630
俺はリモートの状態がどうなってるかわからないままpullするのが怖いんで
先にfetchするのが癖になってしまった。

2023/06/24(土) 22:21:06.02

>>632
リモート次第だね。信頼できなくて無視する選択肢があればそうするのが良い
一方で共通の中央サーバがリモートの場合は信頼するしかない。そこが間違っていても巻き戻しはできないので、一旦取り込んで修正するしかないし

2023/06/24(土) 22:28:26.37

>>628
> そもそもpullは使うべきではなくfetch とmergeを別々に実行するほうがいい。
まだそんな事言ってるの？
何を根拠にして言ってるのか知らんけど
それ言ったの素人でしょ？

2023/06/24(土) 22:30:03.91

>>632
--ff-onlyをつければいいだけ

2023/06/25(日) 00:23:34.87

>>622
「ぼくがぜったいせいぎだ」と言ってんのはお前だろ
こっちはそれほど反撃するならエビデンス出せやと言ってるだけやで

> 俺なりにアドバイスすることはあるよ。
gitを触るのヤーメターの人間にアドバイスできることはないのでお願いだからやめてもらっていいですか
初心者が困るので

2023/06/25(日) 03:28:04.58

『』が付いたらだいたいミソだよね

2023/06/25(日) 04:33:20.93

例えば、rbenv と、そのツールのruby-build では、

rbenvのインストールは、
git init
git remote add -f -t master origin https://github.com/rbenv/rbenv.git
git checkout -b master origin/master

更新は、
git pull --tags origin master

ruby-buildのインストールは、
git clone https://github.com/rbenv/ruby-build.git "${rbenv_root}/plugins/ruby-build"

更新は、
git pull origin master

2023/06/25(日) 07:35:45.46

>>638
何を主張したいのか分からないけど、それ開発者向けでなくて純粋な利用者向けの記述に見えるが、そこは理解してる？
単なる利用者なら、全部落とすより master だけ選択的に拾ってくればちょっとだけ速いよみたいなやり方

開発者なら
git clone <URL> で開始して
git switch master; git pull で更新すれば良いよ
というかそんな小さなプロジェクトは利用者でも master だけ選択的に落とす意味はなさそう

2023/06/25(日) 07:41:22.18

もしかしたら速度でなくて、ディスク容量とかを気にしてるのかもしれないけど、どっちにしろ、そんなの気にするほどのサイズのプロジェクトか？って思う

2023/06/25(日) 09:03:42.06

>>636
> それほど反撃するなら
どこのこと？というかマジでお前らちゃんと分かるように書けよ。勝手に以下だとエスパーするが、

Gitのソースコードが素人以下のゴミな事は見れば分かるし、それ以上のエビデンスはないだろ。
判断する能力がないのはお前の問題だ。

ああちなみにこれは、
> 素人が求めているソースコード管理は (576)
とか勘違いしているお前らに、「Gitのソースコードも素人以下のゴミなんですが」と突っ込んでるだけ。

2023/06/25(日) 11:00:27.19

「オレには分かるが他の誰にも分からない」ｗｗｗ