Git 19

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん (ﾜｯﾁｮｲ 8be4-Cw2/)
垢版 |
2022/11/06(日) 16:40:27.51ID:az1H5JFk0
ソースコード管理を行う分散型バージョン管理システム、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
2022/11/12(土) 18:42:32.33ID:h41UD2lS0
>>147
料理人： 冷蔵庫なんてブッ込んでおけば冷える、で十分
Git： 正しいブッ込み方じゃないから直せ、いやそもそもブッ込み方を知らない奴が使うな！と文句を言う冷蔵庫
2022/11/12(土) 18:55:39.59ID:h41UD2lS0
>>149
> 公開リポジトリにプッシュしたコミットをリベースしてはいけない
> https://www.git-scm.com/book/ja/v2/Git-%E3%81%AE%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E6%A9%9F%E8%83%BD-%E3%83%AA%E3%83%99%E3%83%BC%E3%82%B9
これは既知の問題だけど、これが既知とされるまでにだいぶ大騒ぎしてるはずだよ。

プルリクして、公開リポジトリの操作自体は分かってる奴がやる、
(その時点でおかしい構造ならまずローカルを修正させる）
というのがセオリーなんだろうけど、それをやるのがGit係＝「Git屋」だよ。
他のVCSだとそもそもおかしい操作ができない(=操作出来る範囲が最初から制限されまくってる）からそうはならない。

全世界で唯一の履歴を持つんだ！とか壮大な風呂敷広げてるからこうなる。
ローカルリポジトリは好きにさせて、リポジトリ単位ではなく、commit単位での同期で十分だったはず。
2022/11/12(土) 18:56:07.38ID:zxvXZjfz0
>>150
git: レシピを他の人と共有したりアレンジ料理のアイディア出しに使うツール。
そもそも冷凍庫が欲しい人はお呼びじゃない。どっか行け
2022/11/12(土) 19:00:06.45ID:zxvXZjfz0
>>151
既知も大騒ぎもない。最初からだよ。
理由が分からない時点でおっさし案件
2022/11/12(土) 19:46:47.33ID:Cj/ueztB0
>>114
> ただ、切り替わらなくてもいい共通ファイル類はその場合には .git 階層に置くんだよ。

複雑な仕組みを入れるな。
gitは、gitを使わない場合と全く同じ形のディレクトリ構造に保たれている
バージョン管理をしない通常の開発フェーズでは、gitを使わないのと全く同じ

お前が言うやり方では、gitのためにディレクト構造を作らないといけなくなる
あ～ほらし

まあね、この程度なんだよ
2022/11/12(土) 20:11:12.01ID:h41UD2lS0
>>154
> gitのためにディレクト構造を作らないといけなくなる
ここら辺がGit信者が勘違いしまくってる点だよ。
これは

× Gitの為に
○ branchの為に

であって、ツールを『何も使わずに』branchを用意する場合の構造と同じなんだ。
本来ツールは「使えば便利」で十分なんだよ。
例えば何度も言われてる「電動ドリル」なら、

ユーザーが求めていたもの： 手動ドリルだと手が疲れるので、
　手が疲れないだけで、使い勝手や小回りの良さは手動ドリルと同じ程度の電動ドリル

であって、

Git： 世界中どんな物にも穴が開けられる据え付け型超高性能電動ドリル、
　ただし取り扱い要注意なので1000ページの説明書を読め、

なんて要らないんだよ。可能であれば、それ以前のユーザーがやっていた方式と
出来るだけシームレスに接続出来た方がいい。
だからこの点は、Subversionの方が仕様として正しい。
上書き切換方式がよければ、Opt-inにすべき。

ただ高級機は必要ではあるので、ここら辺はGitが悪いと言うよりは、
普及機がないからそのまま高級機を使ってて愚痴ってる奴が悪い。
だから俺が普及機を用意してやる、ということ。
2022/11/12(土) 20:16:31.82ID:Cj/ueztB0
> であって、ツールを『何も使わずに』branchを用意する場合の構造と同じなんだ。
> 本来ツールは「使えば便利」で十分なんだよ。

その発想が根本的に間違っている
本来ツールは「なければ不便過ぎて苦痛」だから作られた
2022/11/12(土) 20:18:52.70ID:Cj/ueztB0
× ユーザーが求めていたもの： 手動ドリルだと手が疲れるので、
　手が疲れないだけで、使い勝手や小回りの良さは手動ドリルと同じ程度の電動ドリル

○ ユーザーが求めていたもの： 手動ドリルだと作業が面倒すぎて時間がかかり過ぎで
　現実時間で解決することができない。人間には不可能な問題を解決するためものが電動ドリル
2022/11/12(土) 20:19:33.56ID:Cj/ueztB0
Git： 短時間で遠くまで移動できる自動車
　ただし取り扱い要注意なので免許を取れ
2022/11/12(土) 20:27:52.45ID:inQx9iPN0
force pushでもされない限り復旧不能なリポジトリ破壊なんてされないけどな
サーバー側でforce禁止にすればいいし
2022/11/12(土) 20:40:30.40ID:h41UD2lS0
まあとにかくだ、基本思想が違ってて、俺は「簡単は正義」だから、

Git： 使いこなせない馬鹿が悪い
俺： 難しい物を作る馬鹿が悪い

で、平行線なんだよ。
ただお前らからは普及機は出てこないのは分かったから、俺が作るよ。
（もっと調査してからだが）
俺は、難しくなる妥当な理由があるのなら仕方ないが、そうでなければ簡単にしろ、で
ジョブスの「ボタンは一個にしろ！！！」は肯定派。(Apple使う気ないけどさ)

つかよ、Gitの勉強じゃなくて、お前らコードの勉強しろよ、だからな。
あのパッチの顛末、マジで酷いぞ。C読める奴が居たら本当に聞いてみ。
Git等のツールは、最終的にはソフトウェアのコードの品質を上げる為であって、
Gitに習熟したけど糞コードしか書けません、では完全に本末転倒だ。
2022/11/12(土) 21:02:25.04ID:403mRijK0
>>160
俺が作ると言うだけなら簡単
実際に作って公開しなければ口だけ番長と思われてお終い
2022/11/12(土) 21:26:19.25ID:h41UD2lS0
>>161
いや101の仕様で手こずると思ってるお前もかなりヤバいけどな。
これも周りにプログラマが居たら聞いてみ。

ただ、自分で使う用に動けばいい物と、他人が(デタラメに)使う用に作るのはだいぶ違うんだ。
だからきちんと状況確認して仕様はしっかり詰めるべきなんだよ。
Gitにはこの辺の感覚がない。
まあLinusが個人的に必要だから作った、完全特定個人向けチューニングだからではあるが。
この辺がGit(を使わされる側)の不幸なところだよ。
2022/11/12(土) 21:31:32.81ID:Cj/ueztB0
>>160
> Git： 使いこなせない馬鹿が悪い
> 俺： 難しい物を作る馬鹿が悪い

でも、難しいと思ってるはお前だけなんだ

お前が馬鹿というだけじゃね？
それとも完全自動運転車が登場するまで
ずっと無能呼ばわりされたいということかね？
2022/11/12(土) 21:46:15.33ID:M1Nw2seMa
>>163
流石にそれは言い過ぎ。
git は難しいよ。
環境の準備やチーム内のルールも知らないと仕事始められないので。
2022/11/12(土) 22:10:50.71ID:ajB/boEg0
>環境の準備やチーム内のルールも知らないと仕事始められないので。

その点に関してはsubversionの方が難しい気がする。
2022/11/12(土) 22:19:07.47ID:h41UD2lS0
>>163
いや結局>>137なんだよ。
お互いの見解は異なるし、同意する必要もない。ただフォークすればいい。

俺は売れそうだと思ったら作るだけ、欲しい奴は乗っかればいいだけ、要らない奴は使わなければいいだけ。
俺は(というよりプログラマ全般は）ツールだけ使えてコード書けない奴は死ねばいいとしか思ってないから、方向性もいい。
俺の目論見が外れればお前らの勝ち、お前らが食うのに困れば俺の勝ち、勝敗はフォークで、だ。
俺が想定してるのが時代遅れで馬鹿だらけの現場なのか、お前らが壮大に勘違いしてたのかも、それで分かるよ。

ただ当たり前だがこのスレはGitを理解してるか、最低限理解しようとしてる連中の場所であって、
俺が相手にしようとしてる、理解する気もない連中の溜まり場ではないから、
壮絶アウェイになって然るべきで、散発でも賛同者や擁護が出てくる時点でヤバイと気づける位の方がいいと思うが。


スレは立てるが、肝心のアプリ名を今考え直してるところだから、来週まで待ってくれ。
GitBucket気に入ってたのにちくしょ～。
2022/11/12(土) 22:20:47.69ID:/s1n3tt70
難しいなら入門書熟読すればいいし、わからないなら素直に聞けばいいんだよ
それすらやらず、ドキュメント読みたくないとか自分の思想に合わないからgitはクソだとか、小学生並みのわがまま言ってるから無能と言われる
2022/11/12(土) 22:27:14.56ID:zxvXZjfz0
>>166
git は馬鹿に売るために作った製品じゃないのでフールプルーフじゃないんだぜ。無料のオープンソースだからな。
作った人自身が使い易くて余計な時間を消費しないのが最優先。
文句あったらこれより良い製品をオープンソースで公開してみろ。ソース読んで良ければ尊敬するかもしれない。
2022/11/12(土) 22:54:07.27ID:ajB/boEg0
この手のツールは機能や使い勝手の多少の違いよりも信頼性や将来性が重要なものだからな。
コミュニティの立ち上げどころか協力者を一人集めることすら難しそうなこの人が何を夢見ているんだろうか。
2022/11/12(土) 23:22:40.78ID:zxvXZjfz0
長文君や長文君が利用者と考える馬鹿ユーザーは、信頼できるチームでメンテナンスが継続的なされるかとか、ツールに透明性があるかとか一切気にしないのかもしれない。
2022/11/12(土) 23:25:48.94ID:M1Nw2seMa
沢山語る事かある人達楽しそうだな。
VCS はエディタの補助機能で世代交代する事もあるけど、なんとなく使えてたらOK! って思ってた。
2022/11/12(土) 23:27:07.46ID:403mRijK0
>>162
作ると言ってるだけで作らず、皆が興味をなくすのを待つと思っている
ここで偉そうにするだけならそれで十分だからな

本当に作ると言うなら進捗状況を週に一度くらい公表すればいい
そのためにスレを立ててトリップを付けてでもいいしツイッターとかでもいい
実際にプログラムを書きはじめたらそれもどこかで公開する
進捗状況が分かるようにな
来年3月末目標ということで >>101
2022/11/13(日) 00:04:02.56ID:Qr8ucfLW0
どうせやるならgithubにあげて欲しいものだ
2022/11/13(日) 02:55:30.08ID:XlBdLl1o0
git にフォークなんて無いんだが。
git のあいうえおも分からないやつが
git の批判してても何も響かないんだよ。
いい加減去って欲しいわ。
2022/11/13(日) 05:33:33.29ID:S7gZHHW/0
これのソフト？は内容は世界中の人と共有されるの？分散型ってどういうこと？
2022/11/13(日) 06:54:51.14ID:Eh77ZCvU0
考えてみたが、やっぱGitは根本的に思想が俺とは違うんだな。
俺はツールはあくまでアプリの品質を上げる手段だと思ってる。
ここまではおそらく共通なのだが、問題はこの先で、俺は重要な順に、

A. アプリそのものの品質。つまり必要な機能に深刻なバグがないこと。コードの品質がこれに直結する。(コードが本体)
B. 使いやすさ。簡単は正義。使えない機能は存在してないのと同じ。直感的に使えればドキュメントすら必要ない。
C. 持続性。つまり自分が使いたい期間(未来)中ずっと使えるか。

なんだが、Git陣営は全く逆でC>>B>>Aの順に見える。
それはこのスレ内でも散見され、俺は釣りだと思っていたが、マジっぽい。つまり、

C. コミュニティに人を集めれば自然と持続性は確保出来る。つまり人数が一番重要。これを取り持つのがツール(ツールやcommitメッセージが本体)
B. ドキュメントを整備しまくれば、後はがんばって読めばいいだけ。
A. コードの品質なんて後から付いてくる。バグも誰かが勝手に直してくれる。

Git陣営はマジでコードの品質を上げる努力を何一つしてない。具体的には、

・regressionテストを1本も流してない。
・レビューも全くしてない。(マジで、見た瞬間落とされるコードを素通し)
・CodeOfCoductは重要だが、CodingRuleは要らない。

CodeOfConductは最近のポリコレで生まれた、「人の」振る舞いを規定するものだ。
これに対してCodingRuleは「コードの」振る舞いを規定するもので、
CodingRuleなしでCodeOfConductだけってのは、コードはどうでもいい、問題は人だ！と言ってるわけだ。
『人さえいれば、全て何とかなるんだ！』という思想だ。

ただ俺からすると、見る限り完全に「善意のただ乗り」であって、
少なくともコードの品質を上げる努力してないと協力する気にならないよ。
(ITがいくら自動化しても、最終的には人なのは事実としても、コードの質を直接的に改善する努力を全くしないのは不味いだろ)
2022/11/13(日) 06:55:24.88ID:Eh77ZCvU0
俺はコードの品質/アプリの仕様そのものが一番重要で、それさえあれば全てが上手く行く、と思ってる。つまり、
仕様が簡単で直感的なら、ドキュメントを整備するまでもないし、
バグがなければ、後は「十分動く」程度のメンテで済む。だから最初から出来る限り品質の高いアプリを投入すべきだ。
ここら辺は「伽藍」では共通認識のはず。『コード/仕様さえよければ、全て何とかなるんだ！』的な思想だ。

ただここら辺を「バザール」でひっくり返したから話題になったわけだが、やっぱこれは違うよな～とは思うよ。
これって「善意のただ乗り」の仕方が世界一上手かっただけで、みんながこれをやり出したら回らないよ。
2022/11/13(日) 07:21:09.51ID:MdOkAF1j0
>>176
> 考えてみたが、やっぱGitは根本的に思想が俺とは違うんだな。

思想じゃなくて、お前が単純にバージョン管理というものを知らんだけやで
自分が無知であることを知るのが成長の第一歩や
2022/11/13(日) 07:23:03.38ID:MdOkAF1j0
> 俺はコードの品質/アプリの仕様そのものが一番重要で、それさえあれば全てが上手く行く、と思ってる。

うん。やっぱり間違ってるね。
そんなんだから、POSIX原理主義者みたいに、一行書いてデバッグしていれば
バグなんか入らない！とかあり得ない主張をすることになるんだよ。
2022/11/13(日) 07:26:49.86ID:MdOkAF1j0
>>177
伽藍とバザールの話を知っているのであれば、
伽藍方式は間違っていたっていう結論だって知ってるよね？
2022/11/13(日) 07:49:57.39ID:Eh77ZCvU0
>>179,180
(内容が違うが答えは同じで)
いやあれはそういう意味ではない。どう読むかも自由ではあるが。


ただやっぱり、ここら辺はフォークで決着すべきで、それが正しいんだよ。
各自が思う方向に、突っ走ってみればいい。
アプリの品質も、最終的にはユーザー数*満足度の総和だから、Gitのやり方が間違ってる訳でもないんだろうさ。
でも俺は違うと思うから、違う方向を試す。
2022/11/13(日) 08:08:13.98ID:md3JoP5e0
>>176>>177
御託はいいから長文君ソフト(仮)作りにさっさと取りかかれ >>172
御託を並べるのは長文君ソフト(仮)を完成させ、それがgitよりも
使われるソフトになってからにしろ

gitを作っている人たちを皆が望んでいる物を知らないクソと罵っていたんだから
皆が望んでいるソフトを長文君が作れなければ長文君は皆に笑われる
さんざん偉そうなことを言っておきながらその程度かってね
2022/11/13(日) 11:08:14.23ID:4MPzkrV00
気に入らないなら自分で作ればいいだけの話
gitも元はそういう思想から生まれているんだし
それが出来なくて文句言うだけなのは恥ずかしい
2022/11/13(日) 11:25:35.33ID:Qr8ucfLW0
gi自体tの開発の流れってLinuxカーネル開発とほぼ変わらないと思ってるけど違うのかな
1回もレビュー通してないとかいい加減なこと言う人がいるので気になった
2022/11/13(日) 12:40:13.79ID:Eh77ZCvU0
>>184
全通しならレビューの意味がない。よく分からん所でなあなあでウェットなんだよ。

例えば>>58の中盤以降、「どうやってOSSを飼い慣らすか」になっててすさまじく気持ち悪い。
これはタイトル「オープンソースソフトウェアの育て方」からしてそうではあるけども。
しかも書いた奴がCVSにも相当関わってて、Subversionも率いてた奴だってのがかなりキテる。
そして同様の雰囲気をGitからも感じる。

俺は「自分が使ってるツールにバグがあるのは自分も困るので、協力したい」とか、
「自分もそれが欲しいから」という、
個人の利益の追求の方向が偶々揃った程度で連携すべきで、それで十分だと思ってるんだよ。
だから「売れそうなら作るし、欲しければ乗ればいいし、要らないなら無視でいい」になる。(166)
勿論解消も各自の自由で、売れなさそうなら作らないし、ゴミなら使わない、でいい。
極めてドライな連携だ。
そして一般的に匿名掲示板はこの程度だから、俺は気に入ってる。

対して上記本やGit、いかにcontributerを手なずけてコードをタダで貰うか、みたいになってて、本当に気持ち悪い。
それがLinusが世界一上手かったことではあるし、それが成立するという驚きが「伽藍とバザール」だけども。
>>95の内容も若干キモイ。
Linusの個人崇拝になってて、Linus自身はそれにちょっと困ってる、ってのは分かる気がするよ。

コードはコードの内容だけで評価するべきで、
誰が送ってきたとか、これまで彼がどれほど貢献したとか、そういうの、勘案すべきではない。
落とすべきコードはドライに落とすべき。
CodeOfConductでポリコレ宣言せずとも、こんな事はみんな普通にやってきたことだよ。

が、まあ何か思惑はあるのだろうよ。
究極のコードクレクレ君を見せてやるぜ！！！と言われてる状態なので、とりあえず見物だ。
2022/11/13(日) 12:51:13.66ID:QilzRsUJa
世間一般のgitユーザーって Sourcetree 使ってるんかな。
わかばちゃん、サルでもわかる、おもしろいほどわかる、あたりは GUI の使い方書いているみたいだし。
コマンドライン使う説明の本は中級に分類されてそう。

Linux で使っているので Win/Mac に Sourcetree 導入しようとも思わないけど。
2022/11/13(日) 14:05:38.02ID:cAl+3nYf0
>>186
vscode + GitLens + Git Graph おすすめ
Linux/Win/Mac 同じように使える
2022/11/13(日) 14:26:57.07ID:OYfEeFSra
>>187
ありがとう。
git は VSCode のサポートツールにしか見えないね。
2022/11/13(日) 14:31:18.44ID:md3JoP5e0
>>185
長文君の「ただ乗り」批判
長文君ソフト(仮)はその「気持ち悪い」やりかたで作られたgitにただ乗りするんだろ
2022/11/13(日) 14:56:08.51ID:8vm+7sfe0
>>176
無学な長文君らしい発言だなあ。
理解は経験に裏付けられている必要がある。俺には非常に直感的で分かり易い仕様だよ。
他人のソース(自分の過去のソースとかでも良いけど)を頻繁に読まないやつにはとっつき難いんだろうけど。
共同開発の初心者が git 難しいというのは分かる。でも彼らは自分の共同開発の経験が足りないことを理解している。
長文君は自分の経験が足りないことを棚上げして共同開発を全否定することに全力を傾けてる。伽藍とバザールとかいつの時代の話だ、2周くらい周回遅れ。

他人(や過去の自分)と共同開発しないやつに git はいらないよ。そのための専用ツールだからな。
2022/11/13(日) 18:44:25.19ID:Eh77ZCvU0
>>190
俺の価値観からすると、ツール使えるだけで、
肝心の、あのソースコードと開発体制と仕様のヤバさに気づけないのは、本末転倒だと思うけどな。

まあ平行線だからいいよ。決着はforkで、だ。
俺が作るツールは、君ら向けではないし、実際君らには無価値だよ。
そもそもGitを使ってるだけで、Gitを使う為のアプリではないからね。
(これが誤解の元だったから、Gitと冠するのは止めようかと思案中)
だから第一弾で君らが死ぬことはない。
Gitを殺せるとしたら第二弾以降だが、まあ、これも無理だろうよ。これが目的でもないし。
むしろ、Gitを目的外使用してる連中を引き受けるので、お前らは居心地がよくなるかもしれん。
Gitはmerge専用機としてはよく出来てるよ。
しかし一般開発には、通常commit(親が一つのcommit)の方が断然多くて、今使ってる連中の大半もそうだと俺は思うけど。


それはさておき、多分Gitや他気持ち悪い系OSSが維持出来てるのは、
初音ミクの時に言われた、「ヘタウマ」じゃないかと。
日清カップヌードルでも言われてるが、要は「チョイ足し」したくなる絶妙な「ヘタウマ」ならソースコードも集まりやすい。
Linusが書いた完全無欠のコードでは、誰も手が出せないからね。
だからソースコードがある程度ゴミなのは、成功してるOSSの宿命なのかもしれん。
界隈よく知らないけど、例の鳥の詩(国歌)、完成してる感があって2次が少ない(ほぼ無い)と聞くし。
2022/11/13(日) 18:50:03.67ID:2jgXqyDd0
まるで「描かないマンガ家」
2022/11/13(日) 19:03:22.84ID:53QTWROr0
>>191
無能は口を閉じろ
2022/11/13(日) 19:26:29.95ID:2N/MD+QP0
Gitと競ってたDVCSは他にもいくつもあったが全部消えた
2022/11/13(日) 19:35:13.58ID:md3JoP5e0
>>191
その「気持ち悪い」開発方法でしっかりしたソフトが開発できてるから
それをベースにするってことだろ
gitその他の開発方法にケチつけるならそれで開発されたものをベースにするなよ

始めてもいないうちから「第二弾」とかバカ過ぎる
大口叩いてないでさっさと作れ
検討したことや結果を公表する場所を決めて発表するくらいはすぐできるだろ
>>172 >>182
2022/11/13(日) 19:38:47.70ID:53QTWROr0
最強のバージョン管理ツールを
伽藍方式で今考えてるからちょっと待て
最初から完璧な設計でバグもまったくない
100年ぐらいかかる予定だ
2022/11/13(日) 20:22:53.70ID:Eh77ZCvU0
>>195
> その「気持ち悪い」開発方法でしっかりしたソフトが開発できてるから
> それをベースにするってことだろ
違うぞ。既に書いたが>>118,142
というかね、俺はその辺お前らGit勢とは違ってポリコレはしない。
コードに政治は持ち込まない。使えれば使う、程度だ。

SQLiteだとGitの再開発が必要になるのが無駄だ。SVNの方が良ければ乗り換えるかもだが。
(というかバケツ的使用感をSVNが提供してたらそれで終わり、俺がアプリ作るまでもない。
これって今無いのか？
逆にSVNもGitと同様政治的で、バケツなんて提供してヤラネ、学習して使え！
なら俺がバケツアプリSVN版も売れそうなら作るかもだが)
2022/11/13(日) 20:29:12.47ID:53QTWROr0
>>197
俺もお前が書いたものが使えれば使う
使えないから、使ってない。
で、いつになったら使えるようになるの？
使えないなお前
2022/11/13(日) 20:32:39.63ID:Eh77ZCvU0
>>198
>>101,102
2022/11/13(日) 20:45:04.99ID:jMRR13nV0
>>196
彼が作ろうとしてるのは、バージョン管理ツールですらないから(多分わかっていて言ってると思うけど)…
まあバケツ方式でstashしていくやり方でどうやってバージョン順序保証していくか見ものだね

以前彼が言ったように更新日時でとか回答するのであれば失笑ものだがw
2022/11/13(日) 20:48:41.26ID:5qv23escM
本屋でわかばちゃんを少し読んだけど、おじさんが読む本ではなかった。
2022/11/13(日) 21:22:27.78ID:Eh77ZCvU0
>>200
> バージョン管理ツールですらない
Git屋からみればその通りだが、一般人にはこれで十分だ。

というかこの辺も既に書きまくってるが、
普及型で、>>155の様に、これまで手動でやってきた人が使用感そのままでただ楽が出来る程度を目指す。
(だから学習時間ゼロで済む。一番確実なのは既に知ってるGUI=ゴミ箱に合わせること。
意識高い系には馬鹿にされるだろうが、いいんだよこれで）

stashはしない。commitだけだ。
というか、実体はほぼビュワーだから、俺みたいに簡単を正義とするなら既にあるはずなので、妙だなあとは思ってる。
いずれにしてもWindows版のGUIは全部確認しないといけない。これにも時間がかかる。
今のところGitGUIとgitkは違う。tortoiseは、多分違う。
他はまあ、1～2月中位には全部見るかも、程度。
実装着手出来るとしたら3月だから、それまでに、程度で。勿論仕様も練らないといけないし。
でも、これもただの予定であって、予定通り行くかは分からんし、それ以前に売れそうにもなければ作らんし。


まあとにかく、根本的にアプリに対する思想が違うんだよ。
だから君達にはイメージ出来ない。
でも、ゴミ箱で管理する！と聞いて、ああなるほど、と思った人には、納得の出来だろうよ。
どっちが正しいかはforkで勝負だ。
2022/11/13(日) 21:31:16.29ID:5qv23escM
次のカキコはβ版が出たらにしてね
2022/11/13(日) 21:39:36.54ID:Eh77ZCvU0
>>201
それ、前にも少し気になったのだけど、
Git屋はまだ本が主流なのかい？

Web系だと本ではどうにもならないから、ここで初心者が「いい本はありませんか」と聞いてきても
「本なんて全部ゴミ。MDN読め」と返すし、同じノリの奴も多い気がするが。
俺自身、もう本屋に何年も行ってない、に近い。

だからサル先生とか馬鹿にしてるのも、よく分からない。
紙かWebかなんて、どっちに書くかでしかないだろ。
紙媒体なら信用出来るなんて時代はとうに過ぎてる。
そもそも紙媒体の編集者はその選別眼を持ってない。
お前らがあれが糞コードだと理解出来ないように、本職以外の奴が本職の専門家向けに情報を選別するのは無理なんだ。
そして連中はただの印刷業だから、ある意味売れそうなら印刷するだけなんだよ。
だから本当に酷い内容でも本になってたりする。
ただ問題は、初心者にはそれが酷いとは分からないんだよ。

だから俺は適当にググって評判が良さそうなところを読むだけ。
Gitの場合は確かにBook読めではあるが、別にサル先生を馬鹿にする必要はあるまい。
2022/11/13(日) 21:44:03.68ID:md3JoP5e0
>>197
>どこまで使えるか判断して、その範囲は使う

わざわざそんなことをしてでも使いたいくらい
gitのコードはしっかりしているということだろ
「気持ち悪い」とか何とか言っててもそんなもんだ
2022/11/13(日) 21:59:49.24ID:Eh77ZCvU0
>>205

205： 連中がキモイとか言うなら、そいつらが作ったコードも使うべきではない
俺： コードにポリコレは持ち込まない。誰が(キモイ連中)が作ったかは関係なく、そのコードが正しく動く範囲なら使う。

お前らポリコレ過ぎる。コードはコード、作成者がキモかろうが関係ない。
というか、まあ、キモイとか言うなら使うな！というのがCodeOfConductだから、
205の姿勢はGit的には正しいのかもしれんが、とにかく俺はそうじゃない。
(この点も俺はGit勢には馴染まないから、やっぱ遠巻きに見守るべきだな。変に突っ込んでたら大騒ぎだったかもしれん)

しかしこの勢いだと、GPLv4にはポリコレが入って、「キモイとか言う奴には使わせない」とかになりそうだな。
笑えねえ。
2022/11/13(日) 22:01:41.86ID:md3JoP5e0
>>204
gitについて書かれた本を本屋で見た人がいるというだけなのに

>Git屋はまだ本が主流なのかい？

と言い出す長文君
何を参考にするかは人それぞれだろ、普通に考えて。

>俺は適当にググって評判が良さそうなところを読む

適当にググって評判が良さそうな本を買って読む人もいるだろうな
2022/11/13(日) 22:04:13.65ID:Eh77ZCvU0
>>207
いや本に噛みつかれないのがWeb系界隈とは明らかに違う。
2022/11/13(日) 22:05:05.41ID:jMRR13nV0
>>204
1000ページも読みたくない〜とか意味わからんわがまま言って読むの放棄してる奴が何言ってんだかw
2022/11/13(日) 22:07:22.25ID:jMRR13nV0
> 「本なんて全部ゴミ。MDN読め」と返すし、同じノリの奴も多い気がするが。
> 俺自身、もう本屋に何年も行ってない、に近い。
じゃあ自分もこのノリで
「本なんて全部ゴミ。git-scm読め」
2022/11/13(日) 22:17:53.79ID:Eh77ZCvU0
>>205
ちなみに技術的な話をすると、
> gitのコードはしっかりしているということだろ
これは根本的に違ってて、要するに俺が楽したいだけなんだよ。

内部DBを外部ソフトに委ねるのは、最大の目的は、そのソフトのツール群を使えるようにする為。
最悪ユーザー側で何とでもなるというのは、ユーザーにも安心で、これは重要なんだよ。(POSIX君はこの点を問題視してるわけ）
そして外部ソフト自体がバグってても勝手に直してもらえる。
寄っかかることに抵抗がなければ、寄っかかった方がユーザーにも制作側にもメリットがあるんだよ。
(勿論囲い込みは出来なくなるが、最初からそんなのする気ないし）

デメリットは、その外部ソフトのバグもユーザーには俺のバグにに見えるから、俺がバグ対応窓口にさせられる可能性があること。
俺のバグなら致し方ないが、外部ソフトのバグなんて対応してられない。だから安心出来る範囲でしか使わない、ということ。
要は全部楽する為の方策であって、お前らみたいにポリコレまみれではないんだよ。
2022/11/13(日) 22:31:13.00ID:md3JoP5e0
>>206
ベースにしたくなるくらいしっかりしたソフトが開発された方法に
ケチつけるなって話だがな

>>211
寄りかかれば楽ができるくらいgitはしっかりしてるってことだろ

長文君はフォークフォークと言ってるだけで実際に何かを始めたわけではない >>195
2022/11/13(日) 22:41:49.45ID:m9TsWVuY6
Google driveに上書きしてくのじゃあかんの？
2022/11/13(日) 22:43:28.98ID:Eh77ZCvU0
>>212
それはベースにしてるわけではないんだよ。（つか俺がそう言ったっけ？なら訂正だが)

多分OOPの基本すら理解してない君達には通じないが、繰り返すと、
そこは即交換可能なんだよ。
少なくともGitとSVNはほぼ自動的にそうなる。（一般的に普通に組めば自然とそうなる）
SQLiteだとGitやSVNに入っているコードまで自前で書く必要があるから面倒だが。(だからこれはやる気なし)

ベースではなく、外注なんだよ。必要とあればすぐ交換可能だ。

つっても、通じないだろうけどさ。
2022/11/13(日) 22:46:32.10ID:CpNEOOBi0
Git（MSのDevops）にゼロからプルしたらフォルダが40バイトのファイルになったんだが仕様かね
2022/11/13(日) 22:48:27.87ID:Eh77ZCvU0
>>213
詳細仕様分からんが、割とマジでクラウドならデフォで入ってる程度かもな。
なるほど。
2022/11/13(日) 23:09:12.82ID:OYfEeFSra
Git の本は、利用者の裾野が広いせいでバカ向けに書いた本が出回るようになっているのか。
昔だと、教わらなくても Windows95 使えるけど、教えても使えない人の為の本が沢山出ていたのと同じ。
良いことじゃないだろうか。
2022/11/13(日) 23:15:04.42ID:md3JoP5e0
>>214
「外注」したものをベースにしてるってだけだろ
「すぐ交換可能」なら最初からgitをベースにせずに他のを使えばいいだけなのにできないんだから

昨日のことなのに忘れてるし

>>101
>Gitをゴミ箱/バケツ化するラッパ(フロントエンドのみ。バックエンドはGitで、Gitは別インストール必須)

>>199でアンカ貼ってたけど、読んでなかったのか読んだけど2時間ほどで忘れてしまったのか
2022/11/13(日) 23:35:45.59ID:Eh77ZCvU0
>>218
ベースとは言ってないだろ。
フロントエンド/バックエンドとは言ってるが。
それらはまるで意味が違う。
（というのも通じないからもう終わりにするが）

ちなSVNで最初から組むことも問題なく可能だよ。それがOOPでもあるし。
ただSVN確認するのが面倒なので、とりあえずGitで行くってだけで。
(SVNみたいな集中型は鯖立てが必要な可能性があるのでとりあえず敬遠《未調査》)

よく分からんけど、もしGitがお前の持ち物なら、ライセンス変更すればいいんじゃね？
お前の持ち物でもないのに文句言ってるんだったら、お前だいぶ狂ってるよ。
俺からみたら、Gitのコードが糞なのも、Git陣営の動きがキモイのも、事実だよ。
そういう俺が狂ってる、とお前が思うのも自由だが、コードについては第三者に判断可能だから、
お前の周りでCを「きちんと」書ける奴が居たら、今回の顛末見てもらえ、と何度も言ってる。
2022/11/13(日) 23:41:15.62ID:8vm+7sfe0
>>219
お前のいうきちんと書かれたCのコードって例えばどれよ？ お前の妄想内にしかないんじゃね？
2022/11/13(日) 23:46:17.04ID:UN9cy+Utr
>>219
持ち物ではないけど、自分が普段使ってるものに馬鹿だのクソだのいちゃもん言われたら文句言うの当たり前だろうがw
222デフォルトの名無しさん (ﾌﾞｰｲﾓ MM69-AMkR)
垢版 |
2022/11/13(日) 23:50:21.00ID:6O/r8caVM
どうでもいいが、バックアップ取りたいだけならrsnapshotとかあるけど知らないのかな
2022/11/13(日) 23:54:26.54ID:md3JoP5e0
>>219
gitがなければ機能しないものを作るってことなんだからgitがベースってことだろ
糞と思うなら使わなければいいだけ
長文君ソフト(仮)のベースとして役に立つと思っているから使うんだろ

長文君は実際に何かを始めたわけではないけどな >>195
224デフォルトの名無しさん (ﾜｯﾁｮｲ c597-AMkR)
垢版 |
2022/11/14(月) 00:09:27.46ID:0VMo1QiO0
OOPでGitとSubversionを問題なく交換可能かは、それこそ実際に結合テストしてから言ってほしいものだ。
Git開発陣営は少なくとも動くものを作っているけれど、
「OOPの原則に則れば交換可能でなければおかしい」なんてのは机上の空論でしかないし、せいぜい工学的仮説といったところだろう
作れてないんだから仮説の域を出ない。ちゃんと工学的に明らかにしてくれ。
2022/11/14(月) 00:11:39.84ID:aSCqNEw00
>>220
クレクレ君死ね。

ただ、Cのいわゆる伝統的手法は本当にみんなやってるから、そこら辺のCで見あたるよ。
そもそも大概それがCの糞な所とされてるので、見たこと無い奴はほぼ居ないはず。

これも何度も言ってるでしょ。
俺はもうお前らのフォローはしないと宣言したでしょ。
直接的には教えてやらないよ。

でも本当に、Cを「きちんと」書ける人なら全員知ってるから、周りにいる人に聞いてみなよ。
実際問題として、仮に俺がここで丁寧に教えても、お前ら絶対信用しないだろ。
だから、君ら自身が信用出来る人に、直接聞くしかないんだよ。
つまりLinusがベストなんだけどさ。

或いは、これも既に書いたが、結局のところC++/C#/Rustでも同じ解だから、
これらの言語をきちんと勉強しても、同じ所に到達出来る。
だから自分だけで解決したいんなら、これらをやってみるんだね。
新しい言語は、古い言語の駄目なところを改善してるので、彼等がどこを問題視して、どう解決したかが、簡単に見えやすい。

LinusはC++を滅茶苦茶嫌ってて、まあその理由も分かるし、正直同意もするけども、
当たり前だがC++はCのベストプラクティス集みたいな所はあるので。(少なくともC++89/98は。その後明後日の方向に暴走中ではあるが》

あとそもそも最初に言ったが、今回は一番取り扱いが簡単なケースなんだよ。
こんなのでリークするのは、最初から構造がおかしいからだよ。
出来ないのなら、基本に忠実にやれ、でしかない。

ただ君らは構造を議論出来るレベルじゃない。まずはOOPの基本から勉強すべきだよ。
2022/11/14(月) 00:22:09.12ID:aSCqNEw00
>>224
完全に、じゃなくて、そりゃグルーは書くんだよ。
(まあオブジェクト内側にブチ込んでしまえば見た目完全にはなるが)
ただ、俺がやろうとしてることはVCSが普通に持ってる機能(のはず)だから、
VCS自体は何であれ多少の変更で動作するはずなんだよ。

てかお前らには構造の話は通じないから、ここら辺でいいか？

大体、ゴミ箱アプリの中身がGitかSVNかなんて、交換可能に決まってるじゃん。
むしろなんでそれが無理だと思うのかが俺には分からん。
2022/11/14(月) 00:32:35.55ID:aSCqNEw00
>>222
知らんが、要らん。
これなら手動でディレクトリごとzipしとく、の方がマシだ。
2022/11/14(月) 00:50:33.04ID:i6KxBWUg0
>>225
例えばgithubに上げられてるCで書かれてるソフトのうち、「きちんと」書かれていると
思うのをいくつか挙げて、それはgitと比べてどのように「きちんと」しているか説明することは
できないということで、「きちんと」したのは長文君の妄想内にしかないと思われてもしかたないな

>>226
そう思うのならgitの代わりに「コードが糞ではなく開発グループがキモくない」と思うのを使えばいいだけ
2022/11/14(月) 00:52:36.47ID:huosUPX00
>>224
交換可能なはずがないんだよね
そもそもSVNとgitでリポジトリの概念が違うんだから

あとgitは実行速度を重視した実装になっているけど、彼の言うOOPが取り込まれたら実行速度がどれくらい落ちるか、個人的には非常に興味があるね
230デフォルトの名無しさん (ﾜｯﾁｮｲ c597-AMkR)
垢版 |
2022/11/14(月) 01:28:19.71ID:0VMo1QiO0
>>227
またろくに仕様を調べもしないでzipのほうがマシとか言って、傷口を広げるだけですよ

人格攻撃ではないのだが、40代ぐらい、正しいCやOOPは出来るほどの技術力は実際にはあるんだが、
人格に難がありすぎてビッグマウスで信用されずWeb業界でやっと拾ってもらえて、
だがGitが使えずWeb業界でも疎まれていて、鬱憤を晴らしにここにきてるのかな。
Gitを使いこなせないレベルのHTML/CSS屋とかならまあ求められてるものが違うからGitわかんないってのもわかるんだけど、
正しいCとかOOPとか言ってるのにGit使えないというのは、SIerしか考えられない不思議。
231デフォルトの名無しさん (ﾜｯﾁｮｲ c597-AMkR)
垢版 |
2022/11/14(月) 01:31:10.94ID:0VMo1QiO0
>>229
まあ単なる経験則になっちゃうしgit-svnの実装の問題だと言われたら
コードを読んでない自分は反論できないので書かなかったけど、git-svnでどれだけ皆無理だと悟ったか知らないんだろうね
232デフォルトの名無しさん (ﾜｯﾁｮｲ c597-AMkR)
垢版 |
2022/11/14(月) 01:36:05.46ID:0VMo1QiO0
>>226
Gitのコミットはリモートリポジトリだったとしても必ず作業ディレクトリの.gitディレクトリに行われる一方で、Subversionのコミットはリモートリポジトリにする必要があるのに？
どのVCSも同じ機能があると思ったら大間違いだよ。CVSなんかかなり絶望的だと思うぞ(すまんCVSは流石に太古の昔しか使ってないので嘘かも)
2022/11/14(月) 04:51:45.99ID:PeuKV+c+0
「バージョン管理ソフトを利用したゴミ箱アプリの開発」

ただしSubversionを使うときはサーバーが必要です。
ファイルを削除するたびにリモートにファイルを保存したりします。


ってことやろ？
2022/11/14(月) 06:36:03.20ID:Vk7GKPFC0
>>225
長文君、どんどんボロが出るなあ
きんちとしたCのコードなんて基準も何もない妄想って認めてるんだね
2022/11/14(月) 07:31:46.61ID:aSCqNEw00
>>233
SVN全く調べてない俺が勝手に想像してるのはその形態。
鯖立てなんて出来ません！な連中に対応するつもりだから、鯖立て必須は厳しい。


ただ、どうもこのスレの連中は、本当に全くプログラミング出来ないらしい。
>>101,102読めば、ああなるほどね、と並のプログラマならぱっと分かる。
あまりにもトンチンカンな話が多すぎる。マジでお前ら、死ねとしか思われてないぞそれは。
2022/11/14(月) 07:32:21.12ID:aSCqNEw00
ただ、いずれにしてもキモイよ。少なくとも俺には。


俺が想像してた世界：
「はい、バグっぽい何か」「ああバグだね」「直しといたぜ、確認よろしく」「とりあえずこちらでは動いた」

俺が思う本来Gitがあるべき姿：
「そのバグパッチ作ってみました」
「う～ん、君のコードはこの点が問題だから、ここをこう直してくれないかな。そうすれば、もっといいコードになる」
「マジか、このOSSではLinusから直接、技術指導を受けられるのか。なるほど勉強になったぜ」
「次も書くぜ！Linusには悪いが、どんどん教えて貰う！！！」

GitやSubversion：
「はい、バグっぽい何か」
「あらいいプログラマね、お茶してかない？」
「いや俺が欲しいのはバグが無くなったソフトウェアであって、
お茶したいわけでもないし、そもそもお前らと仲良くなりたいわけでもないんだが」（＝「SNSでやれ」)


って書いてて思ったが、
SNS未発達時代のOSSはSNSも兼ねてて、こんなものなのかもしれん。
しかし今もそうなのはやはりキモイ。
完全にドライに技術的なら、CodeOfConduct(=ポリコレ宣言)なんてそもそも要らんし。

ただこれは俺が匿名文化に馴染んでるからであって、
一般人には実名SNS的対応の方が受けるのかもしれんし、まあご自由にどうぞ、ではある。
俺にはキモ過ぎて無理だな、ってだけで。
2022/11/14(月) 07:48:51.42ID:UbsjwJD50
>>236
これかかんの？

俺が想像してた世界：
　略
俺が思う本来Gitがあるべき姿：
　略

俺が実際にやってること：
　　わーわーわーわーわーわーわーわーわーわーわーわーわーわーわーわーわーわー
2022/11/14(月) 07:55:12.73ID:aaTBlyIu0
>俺はもうお前らのフォローはしないと宣言したでしょ。

わかったから他所でやれよ。有言実行。
239デフォルトの名無しさん (ﾜｯﾁｮｲ cd68-YfO/)
垢版 |
2022/11/14(月) 10:23:41.00ID:TzEiJIKc0
ごっみばけっつの人はさっさと専用スレ作って移動しろよ
いつまでめーわくかけ続けるんだよ
2022/11/14(月) 10:26:41.02ID:a8E3Hx5Cr
長文さんってgit とgithubの区別ついてなさそう
2022/11/14(月) 11:29:40.73ID:i6KxBWUg0
>>211
>内部DBを外部ソフトに委ねるのは、最大の目的は、そのソフトのツール群を使えるようにする為。
>最悪ユーザー側で何とでもなるというのは、ユーザーにも安心で、これは重要なんだよ。
>そして外部ソフト自体がバグってても勝手に直してもらえる。

長文君が「糞と思っている」gitをベースにしようとするのは、
コードの品質/アプリの仕様そのものが一番重要で、それさえあれば全てが上手く行く >>177
というのは間違いと思っていて、gitがこうなっているから、ということだな

>C. コミュニティに人を集めれば自然と持続性は確保出来る。つまり人数が一番重要。
>これを取り持つのがツール(ツールやcommitメッセージが本体)
>B. ドキュメントを整備しまくれば、後はがんばって読めばいいだけ。
>A. コードの品質なんて後から付いてくる。バグも誰かが勝手に直してくれる。

長文君は実際に何かを始めたわけではないけどな >>195
2022/11/14(月) 11:40:54.89ID:i6KxBWUg0
>>236
さっさと長文君ソフト(仮)作りを始めて自分の理想のコミュニティを作ればいいのに
検討したことや結果を公表する場所を決めて発表することすらできずに
グダグダ言い続けるだけの長文君
243デフォルトの名無しさん (ｱｳｱｳｳｰ Saa9-FFna)
垢版 |
2022/11/14(月) 12:29:56.96ID:EWF0SvAna
fork して branch した後なら
いくらでも rebase して
push -f しまくってる
244デフォルトの名無しさん (ｱｳｱｳｳｰ Saa9-FFna)
垢版 |
2022/11/14(月) 13:09:25.49ID:EWF0SvAna
やっとここまで読んだ
GitPail がふさわしい名前だと思う
2022/11/14(月) 13:42:15.70ID:Vk7GKPFC0
git って一部でもつけんじゃねー、って思う。
勘違い君に文句言いにこられても困る。
2022/11/14(月) 18:27:40.45ID:huosUPX00
git rebase --ontoを今更ながら知ったが便利だなこれ
今までgit rebase -iした後色々こねくり回してたけど楽になった
2022/11/14(月) 18:31:19.43ID:UbsjwJD50
>>246
長文「バックアップしたいだけなのにそんな難しい機能はいらねーよ！」
2022/11/14(月) 18:38:05.91ID:Vk7GKPFC0
>>246
欲しいって思った機能って調べるとだいたいあるよね。
2022/11/15(火) 06:02:57.49ID:DDE9IX5V0
OSSがコミュニティ的なら、例の「コミュニティの一生」も当てはまってしまうと思うんだよな。
> https://dic.nicovideo.jp/a/%E3%82%B3%E3%83%9F%E3%83%A5%E3%83%8B%E3%83%86%E3%82%A3%E3%81%AE%E4%B8%80%E7%94%9F


【Gitの一生】

Linusが面白いことをする
↓
面白いから凡人が集まってくる >>95
↓
住み着いた凡人が居場所を守るために主張し始める
↓
Linusが見切りをつけて居なくなる
↓
残った凡人が面白くないことをする
↓
面白くないので皆居なくなる


>>176に書いたとおり、人数こそ力の源泉で、「人数の維持」が目的になってるように見える。
だけどそれは本来は手段で、「アプリの品質」を上げるのが目的でしょ。
(まあ賛同されるとは思ってないし、完全に平行線だが)

そもそもGitって今完全にメンテナンス状態？
つまり、本質的な新規機能要求(バックエンドに追加が必要)は無く、View(フロントエンド)をいじってる状態か？
ならまあ、実際面白くもないだろうよ。勿論メンテナはご苦労さんだが。
ああそういえばSHA256対応だっけ？あれは単なる作業だよ、本来は。チャレンジングではないから、面白くもない。
(つかこれがチャレンジングになっちゃうのはコードが糞だからだ。これも何度も説明したけどさ)
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況