[過去ﾛｸﾞ] Git 19 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
67(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 5e03-zlm6) [sage] 2022/11/10(木) 00:31:57.21 ID:eyva6wLj0(1/2) AAS
> Gitなんて超超超超オーバースペックだ。
誰が困るんだ？
必要ない機能なら使わなければいいだろ
68(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 5e03-zlm6) [sage] 2022/11/10(木) 00:32:49.23 ID:eyva6wLj0(2/2) AAS
>>66
×ユーザーが本当に欲しかったもの： 消えないゴミ箱
○バージョン管理を理解してないバカ（お前）が理解できるギリギリの機能：消えないゴミ箱
こうやで、間違えんな
69(1): デフォルトの名無しさん (ｱｳｱｳｳｰ Sacd-oA9A) [sage] 2022/11/10(木) 00:46:30.79 ID:Av/Z41zQa(1) AAS
管理者の為の仕様部分がオーバースペックって言ってるんかな。
管理の都合で記録残したりが嫌かな。
言いたいことが分からんでもないが、みんな人間的に欠陥持って仕事しているので、数人で仕事する時にはその機能があって良かった時も出てくるで。
70(1): デフォルトの名無しさん (ﾜｯﾁｮｲ debb-qVfh) [sage] 2022/11/10(木) 02:36:46.00 ID:CrU8rP2e0(1/3) AAS
世の中にはバージョン管理が理解できなくて、必要性を全く感じない人もいるのだな。
git の機能は実際に必要な人が多数いたから実装されたものがほとんどなんだけど。
自分が不要な機能は他の人も不要と思っちゃうところが素人の限界なんだろうな。
そういう馬鹿ユーザー層にも git の知名度が上がったんだろうけど、今頃ようやく勉強始めてスレを長文で荒らすのは勘弁して欲しい。
git は既にかなり長い歴史のあるソフトウェアなんで長期間便利に使い続けている人が多数いるんだぜ。
何が気に入らないか知らんけど、このスレを荒らしても git には勝てないぞ。
71(1): デフォルトの名無しさん (ｱｳｱｳｱｰ Sac6-Tlaq) [sage] 2022/11/10(木) 04:58:42.46 ID:zjNgRmcKa(1) AAS
このスレを荒らすことでgitに勝った気になりたい人なんじゃないかな多分
72(1): デフォルトの名無しさん (ﾜｯﾁｮｲ b163-FlYH) [sage] 2022/11/10(木) 05:14:26.10 ID:CBCnjUQK0(1) AAS
長文君は「傲慢でつけあがっている」人たちがつくっているgitを使わずに「バケツ」アプリを使えばいいのに。
みんなの望んでいるのがgitでなく「バケツ」アプリというのが本当なら、実際にそういうアプリがつくられて
改良を続けられているはずだから。それこそgitよりもずっとね
>Xの修正に留めるのは、変に壊さない為だが、Git陣営は今壊れているところすらも「きちんと」直そうとしてない。
>Gitは今打てる最善手すら打とうとしてない。
>だから多分技術的にも足りてなくて、それは本人達の慢心だよ。
>傲慢でつけあがってるから、他人がどういう解決をしているか調べたこと無いんだよ。
>まさに、例のブランコ状態。Gitなんて超超超超オーバースペックだ。
>ユーザーが本当に欲しかったもの： 消えないゴミ箱
>「バケツ」アプリで、GUIは完全にゴミ箱と同じ、ただし消せないし消えない、で一般には十分なんだよ。
73(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 515f-nsye) [sage] 2022/11/10(木) 09:30:46.14 ID:bawORDDu0(1) AAS
今時のOSはバケツ機能が標準搭載されてるから
Gitを理解できない長文君でも安心(笑)
Time Machine で Mac をバックアップする
https://support.apple.com/ja-jp/HT201250
Windows のファイル履歴
https://support.microsoft.com/ja-jp/windows/17128
74: デフォルトの名無しさん (ﾜｯﾁｮｲ debb-qVfh) [sage] 2022/11/10(木) 11:07:23.60 ID:CrU8rP2e0(2/3) AAS
それこそ電動ドリルのスレに来て、「メーカーは釘打ちユーザーのことを何もわかってない。オーバースペック」とわめいてるレベルなんだよな。
メーカーに直接クレームいてれ迷惑かけてないだけまだマシという考え方もあるが、恥というものを知らないらしい。
75: デフォルトの名無しさん (ﾜｯﾁｮｲ 515f-pSqO) [sage] 2022/11/10(木) 12:18:43.03 ID:PYTCWKKr0(1) AAS
「今後は君達に問題点を見つけても無視する」とか書いてあってちょっと期待したのに１日も我慢できないじゃねーの。ほんとこいつ
76: デフォルトの名無しさん (ﾜｯﾁｮｲ debb-qVfh) [sage] 2022/11/10(木) 13:02:48.06 ID:CrU8rP2e0(3/3) AAS
初心者の中には以下の違いの区別ついてないやつがいる
1）バックアップ…ハードウェアなどの故障に備えてデータの保全を図るシステム
2）作業記録…作業ミスなどに備えてデータの更新を記録するシステム。セキュリティ目的の場合もある
3）バージョン管理…作業の成果物を効率的に管理して情報共有や意思決定を支援するシステム
git はこのうちの3)のために特化したツールなので1)や2)の目的で使おうとしても無理がある。ちゃんとやりたいなら他の仕組を併用しなければならない
77(1): デフォルトの名無しさん (ﾜｯﾁｮｲ adb0-o+MF) [sage] 2022/11/10(木) 20:45:32.99 ID:waDPm/2h0(1) AAS
バージョン管理で意思決定とかちょっと何言ってんのかよく分かんないがman gitしても意思の決定を支援してくれそーなコマンドは出てこなかったよ
Siriみたいのがあーしろこーしろ答えてくれるコマンドがあんのか?
78: デフォルトの名無しさん (ﾜｯﾁｮｲ 85c2-evei) [sage] 2022/11/10(木) 22:00:16.17 ID:rcgr86R60(1) AAS
>>77
たぶんgitとGitHubの区別が付いてないと思う
79: デフォルトの名無しさん (ｱｳｱｳｳｰ Sacd-oA9A) [sage] 2022/11/10(木) 23:24:58.33 ID:6zeJdr0ca(1) AAS
これは GitHub のAI は賢いよ、という御告げかな。
使ったことないのだけど。
80: デフォルトの名無しさん (ﾜｯﾁｮｲ debb-qVfh) [sage] 2022/11/11(金) 02:15:01.88 ID:gKK2uUPF0(1/5) AAS
バージョン管理でいう「意思決定の支援」は、適切な情報を保存し提供することで変更方法や戦略などの取捨選択を素早くできるようにするというやつだな。必要な情報を必要な時に参照できるのがバージョン管理の必須要素だよ。
81: デフォルトの名無しさん (ﾜｯﾁｮｲ debb-qVfh) [sage] 2022/11/11(金) 02:31:05.65 ID:gKK2uUPF0(2/5) AAS
バックアップしたデータや作業ログを見てもバグ修正の方法とか機能追加の方針とかは決めれないけど、git のコミット履歴があると決定の助けになるだろ。
機械が勝手に判断してくれる魔法みたいな話じゃないので期待すんな。
git log, git blame, git bisect などで素早く目的の情報を探し出せるというのは重要機能。
82(2): デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2022/11/11(金) 06:49:36.44 ID:k022U7g40(1/6) AAS
>>67-72
GitはGitで良いんだよ。Linusが必要だから作ったのだし、
確かに全世界で同時開発してて、既に安定版もリリース済みなLinuxには最適だろう。
ただ、今Gitが一般人や職場で使われてる領域では、世界規模な同時開発なんてやってない。
日々の進捗を記録し、履歴を保持し、バックアップが簡単に取れれば十分なんだよ。
これにGitが使われてるだけ。実際欲しがられてるのは「全自動履歴保持バケツ」。
だからGitが悪いのではなくて、他のアプリがしょぼすぎてGitを滅ぼせないのが問題なんだが。
なお散々言ってるが、俺はGit自体が気に入らないのではなく
・Gitの仕様がグダグダ過ぎて、余計な学習コストがかかりまくるのと
・Gitの開発がグダグダ過ぎ。
俺達はGitを使ってるから世界一の開発出来てる！とでも勘違いしてるからあんなことになるんだよ。
Gitはツールでしかない。上手く使えてるかはまた別だ。
肝心の本家がグダグダ過ぎ。
本家はGitとはこう使う！という広告塔でもあるのだから、もうちょっと真面目にやれよ。
これにソースを読み書き出来ない君達は気づけないだけ。
君達もゴキブリ駆除業者呼んで「ゴキブリホイホイの多数設置」されたらブチ切れるだろ？
割とこれ、当たってる例えだからな。(身近にCを「きちんと」書ける奴がいたら聞いてみるといい)
じゃあ自分で作れ？なら、確かに作れるが、我慢してGitを勉強した方が早い。(再開発が面倒なだけ)
だから誰も作らないわけで、Gitが日々の業務にフィットしているわけではまるでない。
83(2): デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2022/11/11(金) 06:51:48.71 ID:k022U7g40(2/6) AAS
あとGitが不味いのは、
・「素人向け」ではないこと。
これはCの様に、切れ味抜群だが、素人が使ったら怪我をする、が外面仕様としてモロに見えているところだ。
GUI版はここら辺対策出来てるのかもしれんが。ただ一般に言われてる
「Gitは難しすぎる。ちょっとした規模の開発になると、リポジトリを破壊する奴が出てきて、
『Git用員』が必要になってしまう。こんな事は他のVCSではなかった」には納得だ。
(正確に言うと、難しいのではなく、仕様が直感的でないのが問題。多機能は本来は問題にならない)
そして君達はまさにこの「Git用員」で、
ユーザーであるプログラマに「管理側に都合がいいGitの使い方」を強いてて、嫌われてるわけだ。
ただこれ、Gitの思想もおかしくて、両者が簡単に共存出来るようにすぐに出来るんだが、(Viewの変更だけで済む)
「管理側」が作ってるから実装したくないのだろうよ。だからこの辺、サクッと実装した物が出てくれば話は変わる。
C++やRustの連中も大概だが、実際問題としてCの糞コードを修正するよりは、最初から書いた方が早い。
これは基本アーキテクチャが素晴らしいからだ。
ただ実態は、幸か不幸か、ソースや開発体制のクソっぷりが基本アーキの良さで誤魔化せてしまってる。
ただこれも、バザールでは仕様なんだろう。なんだかねー。
> 9. 賢いデータ構造と間抜けなコードのほうが、その逆よりずっとまし。
これも例えて言うとな、Gitは「1本目の包丁」向けの仕様ではないんだよ。
今現在、Gitは無視出来ない存在になってて、プログラミング入門者、場合によっては大学でも使い方を教えるだろう。
ただ本来、VCSを学ぶのはまともなコードが書けてからで十分で、本末転倒なんだ。
むしろその程度の初心者ならセーブ禁止で、
毎日毎回「自分の頭の中にあるコード」を写経させた方が上達するだろうよ。学生には嫌われるだろうけど。
Gitは柳刃包丁や中華包丁と同様、「5～6本目の包丁」仕様であって、
三徳包丁のような「1本目の包丁」仕様ではないんだ。
ただ既に言ったが、これはGitが悪いのではなく、Gitを滅ぼせない他アプリが問題だから、
俺が加担するとしたら他アプリ＝「バケツ」製作側だ。
そして君達「Git用員」の需要を世界規模で消滅させ、路頭に迷わせるのが正しい解だね。
84: デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2022/11/11(金) 06:52:27.39 ID:k022U7g40(3/6) AAS
具体的に言うなら、「学習コスト高すぎ」問題だ。
見る限り50-100時間程度か？少なくともチームの一員として
「リポジトリを破壊せず、普段のコード提出は問題なくでき、チームに『Git用員』が不要」なレベルに到達するまでに。
ただこれは本当に酷い話で、「ゴミ箱」アプリなら完全に把握するまでに5分だろ。なら、50-100時間丸々開発に使える。
あと今回俺が言ってるクソソース問題、
実はCの場合は言語機能がほぼ無いので、ソリューションはどれも馬鹿げているほど単純で、
見れば分かるものしかない。(他言語では文法でサポートされてるので各々2-3時間の勉強が必須)
そしてあまりに馬鹿げてるから「イケてない」扱いされ、傲慢な若者には無視され、結果、メモリリークしてるわけだ。
これは「何故みんなこうするのか」をレクチャーすれば済む話で、
技術的には10分あれば十分なんだよ。(パッチ送ってくるレベルの奴には)
ただ、絶対人の話を聞かない連中だから、Linusがやるしかないけど、
これを省いてGitに学習時間50-100時間かけてクソコードを量産してるんだから、完全に本末転倒だろ。
ここで同種のバグを一掃しないと余計に時間がかかる、という感覚がないのもどうかしてるし。
gitが難しくて、結果的に「『頑張って』勉強するんだ！」みたいな奴が集まってるのはいいのかもしれんが、
頑張る方向を完全に間違ってる。
「ゴキブリホイホイの無限設置だ！」と頑張られても、そりゃ違う、と思うだろ。
(頑張る連中なんだから、正しい方向に導けば上手く流れるだけなのに、そうしないのは上部の怠慢だよ。つまりLinusだな。
頑張らない連中のケツを蹴飛ばして何とかするのとはだいぶ訳が違う)
85(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2022/11/11(金) 06:53:12.04 ID:k022U7g40(4/6) AAS
とはいえGitは大体把握した。
俺が使いたい範囲で何が出来て何が足りないかも分かったし、聞いてた話とも整合性が取れた。
色々情報をくれた人はありがとう。
「バケツ」アプリ、割とマジでゴミ箱仕様で作ってもいいんだが、需要あるかね？
(まあこのスレに来ない連中に聞かないと駄目だが)
今すぐ、というわけではないが、アプリ製作も一回やってみようと思ってはいるから。
あと勘違いしてる奴がいるが、俺が今回Gitを使うのは既定路線だ。
その際にバグに遭遇していろいろ内実が見えて、クソだなと感想を漏らしてるだけ。
あとこれ、rebase履歴も保持されないよな？
commit履歴は基本的に整理用だが、
rebase履歴が保持されないのは仕様としてかなり不味い。
そりゃお前らGit屋は完成したパッチしか興味ないのだろうが、
実際のプログラマは各ブランチで平行作業してパッチを製作し、マージする段になって、一本鎖で済むようにrebaseするのだろ？
その際、rebaseでの競合は「手動」で解決するだろ。だからそこでバグを組み込む可能性があって、
パッチを作る側としては、rebase前に「いつでも」「どのポイントにも」戻れないと不味いんだよ。
だからここら辺も本来はViewを分離したアーキにして、
rebaseは「見た目」一本鎖になりますが、内部DBはそこでマージされてるだけで、rebase前の状態も全部残ってます、が正しい。
(まあrebaseしなければいいだけだ！といういかにもC的な馬鹿っぽいソリューションはあるが、それでは管理側に許してもらえないんだろ？)
LinusはGUI全く作ったことがない？のか知らんが、アーキにMVC感がまるでない。
ただMVCも、きちんとやった方が後々色々楽なんだけどね。
86: デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2022/11/11(金) 06:53:58.17 ID:k022U7g40(5/6) AAS
ついでにSubVersionの糞っぷりも見えてきてるぞ。
> r13222, r13223, r13232
> libsvn_fs_fs の自動マージアルゴリズムを書き直した
> 変更する理由:
> 30万リビジョンが格納されたリポジトリのパフォーマンスが許容できない
> (小さなコミットをしても50分以上かかる)
> https://producingoss.com/ja/stabilizing-a-release.html
勿論もう直ってるんだろうけど、これはそもそも基本アーキがゴミだからこんな事になる。
順方向履歴しか持ってないのだろうよ。最低限逆方向履歴も持たないと駄目だ。
(持ってても整合性取れるまでcommitさせない仕様なら意味無いが)
あと俺がGitに批判的なのは、今の「PC不要論」と同じだ。
スマホで十分な連中には、PCはもう要らないのと同様、バケツで十分な連中には、Gitは要らない。
今はバケツがないからそう感じられないだけ。
87: デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2022/11/11(金) 06:54:51.83 ID:k022U7g40(6/6) AAS
>>73
それは知ってるが、余計に使いにくいのと、
実際は空き領域を使う(SSDでいうウェアレベリング)でしかないので、
満タンになると自動的に消されるので使えない。
手動でディレクトリごとzipして名前に日付付けて並べた方がまだマシ。
88(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 6914-zlm6) [sage] 2022/11/11(金) 06:54:56.54 ID:KNn1/gM50(1/2) AAS
>>85
ちゃんとテストするから問題ない
お前とは違う
89(1): デフォルトの名無しさん (ｱｳｱｳｳｰ Sacd-oA9A) [sage] 2022/11/11(金) 07:55:19.91 ID:IJg9gJTfa(1/3) AAS
これを思い出した。
Linus曰く「Subversionは史上最も無意味なプロジェクト」
https://m.srad.jp/story/07/12/03/1024220
90(1): デフォルトの名無しさん (ﾜｯﾁｮｲ debb-qVfh) [sage] 2022/11/11(金) 09:04:46.52 ID:gKK2uUPF0(3/5) AAS
>>82
電動ドリルのスレで、釘を打つにはコツがいる。学習コストが高いって子供が文句言ってるだけだな
電動ドリルはお子様には向いてない危険な道具なのでどっか行け
91: デフォルトの名無しさん (ﾜｯﾁｮｲ b163-FlYH) [sage] 2022/11/11(金) 09:36:15.40 ID:C2rEhT880(1) AAS
>>82
グダグダと思うのを使わずに「全自動履歴保持バケツ」を使えばいい
皆が欲しがっているのが「全自動履歴保持バケツ」というのが本当なら誰かがそれをつくるはずだからな
誰もつくらないのなら「皆が欲しがっているのは『全自動履歴保持バケツ』」は間違いということ
gitはそれを欲しがっている人たちによってつくられてきたわけだが、その人たちに
「俺が欲しいのはそれじゃない。俺が欲しいものをつくれ」と言うだけで自分ではやらない
口だけ番長の長文君
92(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 5e8f-gUJl) [sage] 2022/11/11(金) 10:11:58.79 ID:xTZiT+Nz0(1) AAS
>>83
へえー君の言うバケツ方式なら猿並みの脳みそでもリポジトリ破壊しないのかーすごいなー是非作って欲しいわー
93: デフォルトの名無しさん (ﾜｯﾁｮｲ 6914-zlm6) [sage] 2022/11/11(金) 10:37:17.96 ID:KNn1/gM50(2/2) AAS
>>92
バックアップするだけだからな
誰でも出来る
バックアップを取り出したり比較したり
そこからパッチ作ったりマージするのが難しいだけ
猿にそんなものは必要ない
94(2): デフォルトの名無しさん (ｱｳｱｳｳｰ Sacd-oA9A) [sage] 2022/11/11(金) 10:39:45.87 ID:IJg9gJTfa(2/3) AAS
長文の人頑張れ。君ならできる(かもしれん)。
Linusが2週間でgitを作った話。 を検索するとgitの初期の話が出てくるよ。
95(3): デフォルトの名無しさん (ｱｳｱｳｳｰ Sacd-oA9A) [sage] 2022/11/11(金) 10:44:54.12 ID:IJg9gJTfa(3/3) AAS
追加で
https://gihyo.jp/dev/serial/01/alpha-geek/0040
96: デフォルトの名無しさん (ﾜｯﾁｮｲ debb-qVfh) [sage] 2022/11/11(金) 11:21:45.64 ID:gKK2uUPF0(4/5) AAS
>>94
絶対無理じゃよ。
今までの文章見ててもまともなコード(動くコードって意味じゃなくて長期間メンテするような有意義なコード)を書いたことは無いのは明らかだ。
本とかウェブで読んだことを理解できずに超解釈して受け売りするだけの転売ヤー。
97(1): デフォルトの名無しさん (ﾜｯﾁｮｲ debb-v03j) [] 2022/11/11(金) 15:29:19.65 ID:gKK2uUPF0(5/5) AAS
長文君にぴったりの git の使い方教えてやるわ
他の人は参考にすんなよ
初期化: git init -q ; git add .; git commit -qm "box"
一覧: git stash list --pretty='format:%h %ai %gD' ; echo
保存: git stash -aq; git stash apply -q
取出: git reset -q --hard; git clean -qfdx; git stash apply -q <xxx>
削除: git stash drop -q <xxx>
commitメッセージもindexも不要な長文君はこの五つの手順だけ覚えとけばいいぞ
コマンド長くて覚えられなかったらエイリアスにでもしとけな
98(1): デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv) [sage] 2022/11/12(土) 06:42:22.57 ID:h41UD2lS0(1/29) AAS
>>88
バグにはすぐに引っかかるものと、そうでないものがあるんだよ。
お前らが理解出来るとは思ってないけど。
Gitはパッチ適用ツールであって、本当に、パッチ書く側のサポートが全くない。
Git作ってる連中も、コミッタ？は結局パッチ適用側に回ってしまって、自分でパッチ書かなくなるから気づけない。
ありがちな展開だけどさ。
そして使う側は（目的外使用ではあるが）書く側として使うからずれる。
だから、求められてるのは「書く側」向けの「全自動完全履歴保持バケツ」。
99: デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv) [sage] 2022/11/12(土) 06:43:34.00 ID:h41UD2lS0(2/29) AAS
>>90
Gitが提供しているもの： 1000ページの取扱説明書を読まないとまともに使えない、超高性能電動ドリル
ユーザーが欲しかったもの： 引き金を引けば回るだけ、簡単で今すぐ使える、ホビー用電動ドリル
100: デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv) [sage] 2022/11/12(土) 06:46:43.39 ID:h41UD2lS0(3/29) AAS
ちな、CodeOfConduct読んで、あいつら中の人か！ってのが分かったので俺的査定。
Avar Arnfjord Bjarmason: 今なんとか方向修正を試みてるように見える。上手く導ければ有能だが、果たして？
Christian Couder: 出てきてないので不明
Junio C Hamano: 休暇中？らしい (40)
Taylor Blau: 無能。ってか閻魔大王が全スルーするならいないのと同じ。ちゃんと門番やれ。
そういえばGitのコーディングルールはどこにあるのだ？
今回ほどの糞コードは、コーディングルールで引っかけて落とせるはずだが。
101(5): デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv) [sage] 2022/11/12(土) 06:52:44.85 ID:h41UD2lS0(4/29) AAS
>>89,94,95
全部読んだ。なかなか面白かった。(89はコメントも全部読んだ)
君が冷やかしかマジかは分からないが、マジで要るんなら作ってみてもいい。
ただし今すぐ取りかかれるわけでもないし、全般的に考えて本年度末(3月末)位が現実的な目標になる。
今考えている構成をざっくり言うと以下
・Gitをゴミ箱/バケツ化するラッパ(フロントエンドのみ。バックエンドはGitで、Gitは別インストール必須)
・electronで作ってwindowsストアに配置(広告付き無料アプリ)
十分売れてる限り保守してやんよ(その必要すらないほど単純なアプリだが)
・プロプライエタリで伽藍開発。バザールなんてとても無理。コードは俺が書くから、お前らは使い勝手をフィードバックしろ。
・GitBucket(仮称)、Gitと付けたら不味いのなら考え直す
・コンセプトは、「何も知らなくても使える『全自動完全履歴保持バケツ』」
よって仕様は限りなく簡素化し、それ以上やりたければDBはgitだからgitアプリ使え、とする
・diffは取れるがmergeは直感的GUIがないので無理。が、主にバイナリを保存する連中には全く関係ないし。
・branchはディレクトリに割り当てて手動で。というより、git内にcommit履歴が保持されてないのでbranchの識別が出来ない。
102(3): デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv) [sage] 2022/11/12(土) 06:54:37.10 ID:h41UD2lS0(5/29) AAS
実装するだけなら2週間程度で十分だが、
・electron使ったこと無いので調査に2週間ほどかかる
・アプリストアも広告付きのアプリも作ったことないので、これも2週間ほど調査必要
・仕様を練らないとろくな事にならない、
Linusが2週間と言ってるのは実装であって、それ以前にずっといろいろVCS使ってきてるから仕様が熟成済みだっただけ。
・そもそも顧客がいるかどうか
・一応は他WindowsGitアプリを全部確認する必要がある。今tortoiseGit試しにインストールしてみたところ。
があるので、冷やかしでないのなら新しくスレ立てて様子見する。
スレタイには GitBucket(仮称)と、何か「Gitはもう諦めた系」「頑張らない系」の連中を集められる文言を入れたいが、何がいいか。
板はここかソフトウェア板だと思うが、他に候補があるか。
ただ対象ユーザーはここに来る連中ではなくガチのど素人なので、もっと全然違うところの方がいいかも？
スレタイ案：
A. もうGitBucket(仮称)でええやん。
B. GitBucket(仮称)使ってるからって、Gitが分からなかった訳じゃないんだからねっ！！！
C. GitBucket(仮称)計画中、Gitに疲れた奴集まれ
D. 日常のバックアップツールGitBucket(仮称)
冷やかしじゃない奴からの投票を受け付ける。
103(5): デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv) [sage] 2022/11/12(土) 06:57:39.26 ID:h41UD2lS0(6/29) AAS
>>97
(わざわざ色々考えてくれたのなら手間かけてすまんが)
正直全く分からんし、俺はstashも糞仕様と思うから使う気ない。
というか、Gitの連中、「仕様は小さくあるべき」という感覚がそもそも無いと思う。
俺だったら、branchなんて、各ディレクトリにそのままマッピングする。
つまり、sample.txtの開発なら、
.git
master/sample.txt
develop/sample.txt
featureXXX/sample.txt
stash/sample.txt
で、実行パスは xxxx/current/sample.txt としておいて、
ブランチの切換はcd、実行ブランチの切換は ln -s master current でよかった。
stashなんて不要機能そのものだよ。直感的じゃないし、そこまでGit信じ切れないし。
この馬鹿仕様で git add -A で取ってれば各ブランチの同時開発状況含めて完全にcommit履歴が保持出来る。これで十分だ。
Gitによってカレントディレクトリの内容が「上書き」されるのはかなり気持ち悪い。
zip展開するときと同様、バケツからは明示的に取り出さないと上書きされない、が分かりやすくて良いんだよ。
branch切換で全部上書きで入れ替わるのは、頻繁に過去と現在を往復するにはいい仕様だが、普通の人には要らん。
というわけでGitBucketは基本この方針でmasterに全ての履歴を数珠繋ぎ、
平行開発はディレクトリとシンボリックリンクで手動でやれ、
git branch xxxx で切り替えれば勿論切り替わるが、バックアップはその状態で取るのであしからず、
それが嫌なら一々masterに手動で戻せ、(自動戻しは失敗するときがあるので付けない)
だから戻し忘れたら一見ちぐはぐになるが、どのみち何処かに残ってるからなんとか探し出せ、という仕様。
要するにGitBucketはbranchを無視する。
(現在のbranchの記録はしておく。これでbranchを使う人も使わない人も問題ない)
104(1): デフォルトの名無しさん (ｱｳｱｳｳｰ Saa9-9aJV) [sage] 2022/11/12(土) 09:27:34.24 ID:xzRuq+6da(1) AAS
electron 使うなら、ブラウザ上にOSのデスクトップ画面を再現するのと同じ事ができるだろう。
ゴミ箱/バケツのところでなくて、デスクトップに置いて管理されている事になっているファイルをコントロールできるようにして欲しい。
105(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 2514-H0Ic) [sage] 2022/11/12(土) 09:30:46.94 ID:Cj/ueztB0(1/9) AAS
>>98
> Gitはパッチ適用ツールであって、本当に、パッチ書く側のサポートが全くない。
パッチ適用ツールはpatchコマンドっていうんだよ
gitはそれ以上のサポートがたくさんある
これ以上何がほしいいっていうんだよｗ
106(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 2514-H0Ic) [sage] 2022/11/12(土) 09:31:53.24 ID:Cj/ueztB0(2/9) AAS
>>103
> 俺だったら、branchなんて、各ディレクトリにそのままマッピングする。
同じ名前のブランチが複数あることを想定してないね
ちょっと失格かな。
107: デフォルトの名無しさん (ﾜｯﾁｮｲ 2514-H0Ic) [sage] 2022/11/12(土) 09:37:06.39 ID:Cj/ueztB0(3/9) AAS
>>103
> というわけでGitBucketは基本この方針でmasterに全ての履歴を数珠繋ぎ、
ああ、GitとGitHubの区別もついてなさそうだね
108(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 2514-H0Ic) [sage] 2022/11/12(土) 09:39:05.08 ID:Cj/ueztB0(4/9) AAS
>>103
> branch切換で全部上書きで入れ替わるのは、頻繁に過去と現在を往復するにはいい仕様だが、普通の人には要らん。
branch切り替えで入れ替わるのはコミットしたものだけだよ
これは便利でコミットしてない設定ファイルやデータファイルなどは
そのまま残る
こういうことまで考えつかなかったでしょ？ｗ
109: デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv) [sage] 2022/11/12(土) 10:59:50.02 ID:h41UD2lS0(7/29) AAS
>>104
> デスクトップに置いて管理されている事になっているファイルをコントロールできるようにして欲しい。
それはやる。というか、今考えている動作モードは2つで、
A. ある階層以下全部の履歴を記録
B. 明示的に指定したファイルまたはディレクトリの履歴を記録
で、Aがgit的、Bがゴミ箱的な使い方になる。
ライトユーザーにはBの方が直感的だろう。
毎日「ゴミ箱ならぬ記録箱」にブッ込んでおけば、万一の時に引っ張り出せるだけ、という使い方だ。
ただし中身がgitなので、当然Aの方が実装しやすい。
当たり前だが同居させないと余分なコードがいるので、無理にでも同居させる。
この解だが、一応
.git
c/users/user/desktop
みたいに、カレントをルートと見立てたファイルツリーとし、
明示的に指定されたらそこ(ディレクトリまたはファイル)を指すシンボリックリンクを作ってgitに取らせるつもり。
(この場合は上記desktopが実際のdesktopを指すシンボリックリンク)
これで不味いかね？普通に読むだけならシンボリックリンクは実体が見えるので、
gitがシンボリックリンクを特に区別しないならこれで全く問題ないはずなんだが。(未調査)
或いは git add c:/users/user/desktop とか、絶対パスで指定した方が上手く行くのだろうか？
しかし見る限り git add で指定するのは通常はカレント下だけなので、
(仕様的には使えたとしても)変なバグを踏みそうなので回避した方が無難ではある。
この仕様で問題なのは、パスが糞長いと記録出来なくなること。
つまり、カレント下に絶対パスを付け加えるので、実体のファイルツリーよりも「常に」カレント分だけパスが長くなり、
パスの文字数の上限(今も260文字らしい)を越えると記録出来なくなる。
> https://learn.microsoft.com/ja-jp/windows/win32/fileio/maximum-file-path-limitation
だからガチもん商用アプリではこの解は使えない。
(仮にルートに置いてもc:\の3文字は長くなるので、ユーザーファイルが合計258-260文字のパスになってるときに記録出来ない)
が、今回は、「そんな糞長いパスにするな」で終わり、諦める。(WARNINGは出す)
110: デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv) [sage] 2022/11/12(土) 11:00:10.29 ID:h41UD2lS0(8/29) AAS
てな話を仕様として詰める必要があって、つまり、
1. どういう機能が欲しいか
2. それはこの仕様(実装)でいけるか
みたいなこと。
ちょこちょこやるのはさておき、本格的にやるならスレ分けるべきだな、という話。
111(1): デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv) [sage] 2022/11/12(土) 11:11:14.80 ID:h41UD2lS0(9/29) AAS
>>105
commit/rebase履歴の全保持と、commitのフィルタ機能だね。
記録側からみればゴミなcommitも、プログラマからみれば重要なんだよ。だからそれを見えなくする機能だね。
CSSでいうdisplay:noneの機能。
今は、「綺麗に清書して＝プログラマには必要だったコミットも全部消して」提出しろ、になってるだろ。
これが無駄だし、プログラマ的には不快だ。
それは悪戦苦闘の記録であって、デグレードした場合に参照したい時もあるんだよ。消してるのは不味い。
ローカルだけにしろ、はその通りだが、今はローカルだけにも出来ない仕様だろ。(無駄にブロックチェーンしてるので)
112: デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv) [sage] 2022/11/12(土) 11:11:41.80 ID:h41UD2lS0(10/29) AAS
>>106
世界規模で勝手に開発してるLinuxならそうだろう。
しかし、ローカルファイルシステム、或いは共有ファイルシステムに於いては、当たり前だが「同じディレクトリ名」＝「同一」なんだよ。
だからディレクトリ名が被って困る、なんて事はない。
そして、バックアップ的には、branchはパスが伸びた程度の意味しかないから、これで問題ない。
(git流のbranchの使い方をしてても、これで問題ない。
通常のファイルシステムでは、パス+ファイル名が同じなら同一と見なすが、
ここがgitではパス+ファイル名+ブランチ名になってるだけ。
branch自体の参照先も変えられる！と思うかもしれんが、それはユーザーがそうしたのであって、
確か○月○日頃の○○ブランチ内にそのファイルがあるはず、と思い出すのはユーザー責任だ。
いずれにしても何処かに記録はされてるから、あとは頑張って探せという仕様)
113: デフォルトの名無しさん (ﾜｯﾁｮｲ adc2-owoj) [sage] 2022/11/12(土) 11:13:16.58 ID:inQx9iPN0(1/3) AAS
git関係ないけどWindows10 1607以降はMAX_PATH制限なくなってるんだな
114(1): デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv) [sage] 2022/11/12(土) 11:13:17.79 ID:h41UD2lS0(11/29) AAS
>>108
知ってるぞ。
ただ、切り替わらなくてもいい共通ファイル類はその場合には .git 階層に置くんだよ。
というかね、gitが何故か「カレント主義」になってて、とにかく「カレントディレクトリ」なんだよな。
これは本当によく分からない。
俺がGitGUIで最初にやったのは、「Open repository ...」を探すこと、だからな。
無いから、「え？まさか？カレントで起動しないと駄目なのか？」でわざわざショートカット作り直して起動し直した。
普通そんなアプリ無い。この辺は、「いつも通りのアプリ」じゃないと駄目なんだよ。
115(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 1563-sfiH) [sage] 2022/11/12(土) 11:26:13.02 ID:403mRijK0(1/9) AAS
>>101
仕様や開発グループがグダグダだと思っているものをバックエンドにするのか
「gitがグダグダだからできなかった」と言い訳して終わりそう
>>103
mergeのことは考えてないんだな
116: デフォルトの名無しさん (ﾜｯﾁｮｲ 4bbb-tcgO) [sage] 2022/11/12(土) 11:28:11.58 ID:zxvXZjfz0(1/14) AAS
>>102
投票とかどうでもいいから早く別スレ行け
馬鹿向けのアプリは馬鹿だけが多数寄ってきて繁盛するからそっちで頑張れ
git は馬鹿には使えないことが理解できたんだろ
117(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 4bbb-tcgO) [sage] 2022/11/12(土) 11:37:38.69 ID:zxvXZjfz0(2/14) AAS
>>103
ブランチにディレクトリを使うのは既に subversion がやって失敗した道だぞ
ファイル数やファイルサイズが大きくなるとブランチ切るのに時間とディスク容量がかかり過ぎる
過去話読んでも何も学ばないやつはゴミを再発明するよな
とはいえ、お前やお前が想定しているユーザー層はたいした規模のプログラム組まないだろうからゴミでも十分かもな、知らんけど
118(2): デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv) [sage] 2022/11/12(土) 11:45:13.42 ID:h41UD2lS0(12/29) AAS
>>115
車輪の再開発はしないんだよ。
どこまで使えるか判断して、その範囲は使うし、それを超えた範囲は使わない。
(今の実態だと、git add 絶対パス、はほぼ確実にバグを踏むから使わない)
自分で作ればバグがない物が簡単に出来るわけでもないし。
> mergeのことは考えてないんだな
GUIでmerge、例えばドラッグアンドドロップでmergeは怖いだろ。
コピーするつもりがmergeされたら悲惨なことになる。
(コピーや移動と同じGUIにmergeをアサインしてはいけない）
だからmerge自体はgitアプリで明示的にやれ、という仕様。その方が安心だ。
そもそもバイナリはmerge出来ないし、
GitBucket使うような連中にはmergeなんてほぼ要らん。
てゆうかね、そもそもmergeが主な仕事ならgit使うべき。あれは完全にmerge特化型だから。
GitBucketのユーザーは、そのmergeのネタを作る側、つまりプログラマとかクリエーターとかだ。
管理側じゃなくて、管理される側。
119(2): デフォルトの名無しさん (ﾜｯﾁｮｲ 4bbb-tcgO) [sage] 2022/11/12(土) 11:59:07.72 ID:zxvXZjfz0(3/14) AAS
>>111
アホでやんの。マニュアル斜め読みしただけで実際に使用してないので本質が見えてないな
rebase する前に新しいブランチ切ってやれば
rebase前とrebase後の両方残せるという基礎の基礎すら理解できてないのか
普通はそうやって使うんだよ。マージも一緒。
ブランチが軽量で好きなだけ切れるので情報残したい数だけブランチを切ればいいだけだよ
rebase --keep-base みたいな使い方もあるけど基本が理解できてないやつは混乱するだけだろうな
120(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 1563-sfiH) [sage] 2022/11/12(土) 11:59:16.76 ID:403mRijK0(2/9) AAS
>>118
× mergeが主な仕事ならgit使うべき。
○ mergeを使う可能性があるならgitを使うべき
長文君ソフト(仮)ではmergeのことを考えてないんだから
すでに書かれてるけど他のスレに行ってくれ
仕様の検討も含めてそっちでやればいいんだから
121(1): デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv) [sage] 2022/11/12(土) 12:01:03.49 ID:h41UD2lS0(13/29) AAS
>>117
ああその失敗情報は有り難い。
ただ、そこは理論的に問題ない。
技術的には、Gitでもカレントを「上書き」するのだからコピーと同じだけのI/Oが必要であり、
I/Oバウンドの場合、GitでもSubversionでもその部分の処理時間は同じになる。
(Gitのbranch切換とSubversionのブランチ作成が同じI/O負荷）
そこで速度差が出るのだから、実際は、86で既に言ったとおり、Subversionが各ソースを「展開」するのが遅くて、
それはおそらく順方向履歴しか持ってないからだ。
(逆方向履歴持ってれば、commitは早くならないかもしれないが、branch切り出しはコピーと同速に出来る）
ここら辺はSubversionの基本アーキが腐ってるからだが、
この点GitBucketは中身Gitだから、コピーするだけで、結果的には本家Git（上書きするだけ）と同速だよ。
そのコピーが重い？
だったらbranch切換セレクタだけは付けるから、それで勝手に自前で管理しろ。
バックアップツールとしては、branchはパスが伸びただけの意味しかないからそうする、というのは112の通り。
コピーオンライトのファイルシステム、つまりハードリンクにする手もあるけど、これはユーザーが付いて来れないだろ。
ならコピー時間待たせた方がいい。
122(1): デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv) [sage] 2022/11/12(土) 12:09:47.00 ID:h41UD2lS0(14/29) AAS
>>119
> rebase する前に新しいブランチ切ってやれば
そこはbranchではなくてタグだとは思うが、要はそれ、gcされないようにポインタ残してるだけだろ。
しかし開発しなくなったbranchは刈り取れ、というのが一般の使い方だろ。（それが推奨されてるように見える）
そもそもgcされないようにxxする、というのが間違ってるんだよ。
そんなところまでユーザーが密結合すべきではない。
普通にオススメ通りやったら、探せば何処かに履歴はあるよ、程度じゃないと。
まあ--keep-baseについては見てみるよ。
Bookの方が断然良かったのでman の方読むの止めてたから、知らなかった。
123: デフォルトの名無しさん (ﾜｯﾁｮｲ 4bbb-tcgO) [sage] 2022/11/12(土) 12:11:08.00 ID:zxvXZjfz0(4/14) AAS
>>121
お前、作成の負荷と切り替えの負荷の区別ついてないだろ
実用上で問題になるのは作成の負荷、切り替えはディレクトリ方式の方が軽いけどそこは重要じゃない
124(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 4bbb-tcgO) [sage] 2022/11/12(土) 12:15:51.67 ID:zxvXZjfz0(5/14) AAS
>>122
必要なものには後で探せるように名前をつけておく。
名前のないものはいらないものなので掃除の時に捨てる。
基本中の基本すら理解できないの？
125(1): デフォルトの名無しさん (ﾜｯﾁｮｲ d55f-BvCT) [sage] 2022/11/12(土) 12:18:07.20 ID:bWvYfJDZ0(1) AAS
Subversion のブランチ作成がファイル数やサイズで重くなるとか・・・
てきとうなこと言うやつが二人になってカオス。二人とも早く別スレに行くか黙るかしてくれ。
126(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 4bcf-IBSA) [sage] 2022/11/12(土) 12:34:32.74 ID:ajB/boEg0(1/4) AAS
GitBucket をdisってんのかと思った。
その名前はもう使われてるから変えろバカ。
127(4): デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv) [sage] 2022/11/12(土) 12:54:11.71 ID:h41UD2lS0(15/29) AAS
>>120
多分な、開発現場において「ファイル内の」mergeが日常ってのはあまりないと思うぞ。
それは各自が勝手にどのファイルをどういじってもいい、ということだから。
gitによって開発フローが変わった！ってのがこの辺かもしれんが、
普通は担当を振り分けて、結果的に
「この期間にこのファイルを触るのは○○だけ」
と交通整理される。
同時に変更する必要があれば、同じ奴に同時にやらせるだけ。（注文が増えるだけ)
そして各自が変更したファイルをかき集めて、くっつけて終わりだ。
お前らはこれもmergeと言ってる気がするが、
これは「更新日時が新しければ上書きする」だけの話で、手動でも楽勝だし、
プログラマはこれをmergeとは言わない。
プログラマが言う「ファイル内」のmergeが日常的に発生するかどうかはその部署のオペレーションによる。
(が、会社とか統制取れる場所でこれをする意味はないから、OSS以外ではほぼないと思うが）
128: デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv) [sage] 2022/11/12(土) 12:57:01.77 ID:h41UD2lS0(16/29) AAS
>>126
了解。考え直すよ。一度位ググるべきだったわ。
129: デフォルトの名無しさん (ﾜｯﾁｮｲ 4bbb-tcgO) [sage] 2022/11/12(土) 13:00:04.63 ID:zxvXZjfz0(6/14) AAS
>>125
お前的には svn copy だけがブランチの作成で svn checkout は不要という主張したいの？
svn 的には checkout までが作成で、ブランチの切り替えは cd じゃないか。
オフトピなので svn の思想の話を続ける気はないけど、気になった。
130(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 1563-sfiH) [sage] 2022/11/12(土) 13:08:13.18 ID:403mRijK0(3/9) AAS
>>127
結局これだろ
mergeを使う可能性があるなら長文君ソフトでなくgitを使うべき
gitのスレなのにmergeの意味が違うとか言い出すし…
131(2): デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv) [sage] 2022/11/12(土) 13:18:34.58 ID:h41UD2lS0(17/29) AAS
>>130
つまりお前らGit屋の要求仕様は、
ファイル内のmerge：要らん
ディレクトリ内のmerge(=新しい方を取るだけ）：要る
ってのか？これなら手動でやった方が楽だよ。
普通にゴミ箱＝エクスプローラ的GUIになんだから、日付でソートして纏めて選択して持ってくだけ。
いちいち「オレオレアプリ的merge」とか用意するから余計混乱する。
使い慣れたエクスプローラで苦も無く出来るのだから、それで十分なんだよ。
132(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 1563-sfiH) [sage] 2022/11/12(土) 13:25:22.90 ID:403mRijK0(4/9) AAS
>>131
訳のわからないこと言ってないで、とっとと長文君ソフト(仮)スレ立てて移動しろ
133(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 4bbb-tcgO) [sage] 2022/11/12(土) 13:25:51.41 ID:zxvXZjfz0(7/14) AAS
>>131
そんな低レベルの話してるのはお前だけだぞ
134(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 4b8f-X3QC) [sage] 2022/11/12(土) 13:45:55.74 ID:/s1n3tt70(1/2) AAS
>>127
> 普通は担当を振り分けて、結果的に
> 「この期間にこのファイルを触るのは○○だけ」
> と交通整理される。
いつの時代のこと言ってんの？待ちが発生すること自体問題とは考えないの？
> 同時に変更する必要があれば、同じ奴に同時にやらせるだけ。（注文が増えるだけ)
> そして各自が変更したファイルをかき集めて、くっつけて終わりだ。
> お前らはこれもmergeと言ってる気がするが、
> これは「更新日時が新しければ上書きする」だけの話で、手動でも楽勝だし、
> プログラマはこれをmergeとは言わない。
更新日時見てマージとか、複数の人が並行開発した場合を考えてないよね
135(2): デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv) [sage] 2022/11/12(土) 13:47:01.20 ID:h41UD2lS0(18/29) AAS
>>132-133
最初に言っておくべきだったが、俺が作るアプリはお前らGit屋向けではないよ。
プログラマ、或いはクリエイター向けで、
Gitなんか勉強したくない、何でもいいからバックアップと履歴が取れてればいい、という人向けだ。
だから内部DBには都合がいい物を使うだけで、SQLiteもあり得るし、途中での変更もあり得る。
Git屋はGitを使うべきだよ。そもそもGitがGit屋向けフルチューンだし、
だからこそ文句言われてるわけだが、目的外使用なのだからLinusから見れば完全に筋違いだ。
なら、俺が「プログラマ/クリエイター向け」のツールを提供しよう、というだけ。
136: デフォルトの名無しさん (ﾜｯﾁｮｲ 4bbb-tcgO) [sage] 2022/11/12(土) 13:49:39.50 ID:zxvXZjfz0(8/14) AAS
>>135
だから、このスレでやるな。
自分のスレ作って引き籠もれ。
137(2): デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv) [sage] 2022/11/12(土) 13:51:09.55 ID:h41UD2lS0(19/29) AAS
>>134
それなら、お前にはフィットしないだろうし、お前の周りはGitを引き続き使えばいいだけ。
俺は127方式やもっと小規模(個人)レベルでの開発を想定したツールを提供するだけ。
目論見が外れてたら、思ったより売れなくて、俺の骨折り損なだけ。
これで何の問題もないだろ。
138(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 1563-sfiH) [sage] 2022/11/12(土) 14:12:47.90 ID:403mRijK0(5/9) AAS
>>135>>137
長文君ソフト(仮)ではmergeのことを考えてないから
mergeを使う可能性があるなら長文君ソフト(仮)ではなくgitを使うべき
ってことだろ。なんなんだよGit屋って。
とっとと長文君ソフト(仮)スレ立てて移動しろ
139: デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv) [sage] 2022/11/12(土) 14:55:15.80 ID:h41UD2lS0(20/29) AAS
>>119,124
--keep-base見たが、これ仕様が欠けてるんだよ。
だから君みたいな「あらかじめポインタ(branchまたはtag)を確保しておく」使い方しか出来ない。
rebaseが成功したらbranchは新しい方を指すので、古い方は名無しになってしまう。（放置したらgc対象)
だから本来の仕様は、 --keep-base "AsThisBranch" とかで、新しいbranch名かタグ名を指定出来ないとおかしい。
これ --keep-base だけしても名無しのままだから即削除されないだけで、じきにgcされるから、意味ないと思うぞ。
こういうところがGitは仕様が雑なんだよ。仕様の重要さをまるで理解してない。これただの落とし穴だよ。
そして落ちない工夫が「あらかじめbranchにしておく」君のやり方で、バッドノウハウになってるだけ。
そりゃ君らみたいなGit屋にとっては落とし穴は多ければ多いほど重宝されて都合がいいんだろうけどさ。
それでちょっと確認したいんだけど、君がbranchに拘ってるのは、もしかしてタグ付けてもgc対象になったりする？
何かこの辺雑だし、下手すればあり得るので怖いんだけどさ。
あと俺が欲しい仕様は、rebaseした奴の親としてrebase前の記録が全部保持されるタイプで、--keep-baseではない。
まあ俺はrebase無しで運用してこの辺回避するからいいんだけどさ。(つかmergeでいい)
140(1): デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv) [sage] 2022/11/12(土) 14:56:22.97 ID:h41UD2lS0(21/29) AAS
>>138
プログラマ： 主にソースコードを書いてる連中
クリエイター： 例えば主にフォトショで絵を描いてる連中
Git屋： Gitを操作することが主な仕事(>>83内のGit用員)、ソースコードは書けないし、絵も描けない
141(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 4bcf-IBSA) [sage] 2022/11/12(土) 15:04:56.83 ID:ajB/boEg0(2/4) AAS
まあ、こうやって素人考えをぶつけてみることでgitの良いところを再認識できるのであれば
まったくの無駄ではないのかもしれまい。
142(2): デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv) [sage] 2022/11/12(土) 15:24:26.31 ID:h41UD2lS0(22/29) AAS
>>141
× Gitの良いところ
○ Gitと被るところ
バックアップツールで必須な
・更新されたファイルを保存しておく
・変更されてないファイルは改めては取得しない
・変更履歴も保持し、必要なら古いファイルも取り出せる
・可能なら定期的に圧縮する
をGitが持ってるから、目的外使用されてるだけだな。
まあ基本アーキがいいから目的外使用でも本来ツールと戦えるということではあるけど。
ただ変更を酷く許してないところは頂けない。ここは俺はぶち壊す予定。
(間違ったファイルをコミットして大騒ぎ、結局全部作り直し、みたいのを無くして、ファイルを普通に消せるようにする。
ハッシュがずれたところで、ツリーには関係ない)
Gitのバックエンドは出来がいいんだと思うよ。多分。（俺が問題に遭遇してないだけかもだが）
Gitが糞なのは、フロントエンドと、仕様だね。ドキュメントは多すぎるが、よく書かれているし、少ないよりは断然いい。
143(1): デフォルトの名無しさん (ﾜｯﾁｮｲ c597-AMkR) [] 2022/11/12(土) 15:51:38.43 ID:pkT2sKDg0(1) AAS
どうでもいいが95%はコード書いて検証してる時間で、複数人でレビューしながら開発とかでない限りGitに使う時間って5%くらいだろ。
皆プログラム書きつつGit触れて普通だと思うんだけど。それこそWeb業界では。難しいことになるときがないとは言わないけどたまーにでしょ。
グラフィックの感性で勝負とか、そういう特殊な世界のプログラマー以外でWeb系でGitも使えないんじゃ普通仕事にならないけどな。
144(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 4bbb-tcgO) [sage] 2022/11/12(土) 16:11:19.82 ID:zxvXZjfz0(9/14) AAS
>>142
git はバックアップツールじゃないぞ。
料理に例えるならお前が欲しがってるのは出来た料理を保管するための冷凍庫。
git が提供してるのは料理を作ったりアレンジするためのレシピ本(とその編集機能)
あとお前の言う「プログラマ」って、単なるコーダーで、本物のプログラマじゃないだろ。工場で刺し身にタンポポ載せてるやつは料理研究家じゃないからな間違えんなよ。
145: デフォルトの名無しさん (ﾜｯﾁｮｲ 1563-sfiH) [sage] 2022/11/12(土) 17:09:07.94 ID:403mRijK0(6/9) AAS
>>140
長文君はgitをバックアップツールとしか見てないのに、Git屋というそのためだけの要員を
わざわざ雇っている会社があるという妄想に取り憑かれているんだな
146(2): デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv) [sage] 2022/11/12(土) 17:57:20.46 ID:h41UD2lS0(23/29) AAS
>>143
いや5%(=24分)も十分多すぎだけどな。
まあそれはさておき、コードと開発体制も糞だったのを忘れてたから、
Gitの良い所： 基本アーキ、バックエンド、ドキュメント
Gitの糞な所： フロントエンド、仕様、コード、開発体制、(ドキュメント多すぎ)
となる。ここで、駄目なところは全部マネジメントに起因してる。
一般の会社なら課長/係長クラスで締める部分が締まってない。
これは指揮系統を持たない「バザール」の宿命で、他知らんけどこんなもんなのかもしれないが、
OSSという意味ではchromeとかもっとガッツリやってる（ように見える）し、少なくともregressionテストは流しまくってる。
あっちはGoogleが締めてるのかもしれないが、Gitは見た目1本もregressionテスト流してないのは駄目だろ。
Subversion(58内記事)ではregressionテストに落ちたらcommit禁止だったらしいし。これが普通。
CVSはこの辺ガッツリやりすぎて、テスト用の3万行超のシェルスクリプトに
(自分がcommitする部分の為の)新規テストを追加しなければcommitしちゃ駄目、とかで問題だったとも書いてあったが。
>>144
料理の味で勝負をしたいのに、冷蔵庫の使い方を100時間かけて勉強して、
冷蔵庫のご機嫌を取らないといけない事に、みんな文句言ってるんだよ。
ただこれはテクノロジーが達してないだけではある。
昔は航空機関士が同乗してたように。（乗ってて何とかなったとはとても思えないが、それはそれ)
今はGit屋が必要なレベルで、じきにもっと簡単な物が出てきてお役ご免になるはず。
出てこないようなら俺が作るよ、ということ。
147(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 4bbb-tcgO) [sage] 2022/11/12(土) 18:26:38.13 ID:zxvXZjfz0(10/14) AAS
>>146
だから料理の「レシピ本の作り方」をどんなに読み込んでも冷凍庫の使い方は載ってないぞ。少しなら冷凍庫の使い方のヒントになる部分もあるので勘違いしてるんだろうけど。
冷凍庫欲しかったた冷凍庫買え。レシピ本に冷蔵庫の代わりを求めるな。
148: デフォルトの名無しさん (ﾜｯﾁｮｲ 1563-sfiH) [sage] 2022/11/12(土) 18:35:41.91 ID:403mRijK0(7/9) AAS
>>146
俺が作ると言うだけなら簡単だ
スレ立ててそっちに移ることすらできない奴でも
俺が作ると言うことはできる
149(1): デフォルトの名無しさん (ﾜｯﾁｮｲ adc2-owoj) [sage] 2022/11/12(土) 18:40:42.95 ID:inQx9iPN0(2/3) AAS
うちの会社にも取引先にもgit使えないプログラマーなんていないけど
git屋わざわざ雇ってる会社のプログラマーてアホばっかりなん
150(1): デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv) [sage] 2022/11/12(土) 18:42:32.33 ID:h41UD2lS0(24/29) AAS
>>147
料理人： 冷蔵庫なんてブッ込んでおけば冷える、で十分
Git： 正しいブッ込み方じゃないから直せ、いやそもそもブッ込み方を知らない奴が使うな！と文句を言う冷蔵庫
151(1): デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv) [sage] 2022/11/12(土) 18:55:39.59 ID:h41UD2lS0(25/29) AAS
>>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単位での同期で十分だったはず。
152: デフォルトの名無しさん (ﾜｯﾁｮｲ 4bbb-tcgO) [sage] 2022/11/12(土) 18:56:07.38 ID:zxvXZjfz0(11/14) AAS
>>150
git: レシピを他の人と共有したりアレンジ料理のアイディア出しに使うツール。
そもそも冷凍庫が欲しい人はお呼びじゃない。どっか行け
153: デフォルトの名無しさん (ﾜｯﾁｮｲ 4bbb-tcgO) [sage] 2022/11/12(土) 19:00:06.45 ID:zxvXZjfz0(12/14) AAS
>>151
既知も大騒ぎもない。最初からだよ。
理由が分からない時点でおっさし案件
154(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 2514-H0Ic) [sage] 2022/11/12(土) 19:46:47.33 ID:Cj/ueztB0(5/9) AAS
>>114
> ただ、切り替わらなくてもいい共通ファイル類はその場合には .git 階層に置くんだよ。
複雑な仕組みを入れるな。
gitは、gitを使わない場合と全く同じ形のディレクトリ構造に保たれている
バージョン管理をしない通常の開発フェーズでは、gitを使わないのと全く同じ
お前が言うやり方では、gitのためにディレクト構造を作らないといけなくなる
あ～ほらし
まあね、この程度なんだよ
155(1): デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv) [sage] 2022/11/12(土) 20:11:12.01 ID:h41UD2lS0(26/29) AAS
>>154
> gitのためにディレクト構造を作らないといけなくなる
ここら辺がGit信者が勘違いしまくってる点だよ。
これは
× Gitの為に
○ branchの為に
であって、ツールを『何も使わずに』branchを用意する場合の構造と同じなんだ。
本来ツールは「使えば便利」で十分なんだよ。
例えば何度も言われてる「電動ドリル」なら、
ユーザーが求めていたもの： 手動ドリルだと手が疲れるので、
手が疲れないだけで、使い勝手や小回りの良さは手動ドリルと同じ程度の電動ドリル
であって、
Git： 世界中どんな物にも穴が開けられる据え付け型超高性能電動ドリル、
ただし取り扱い要注意なので1000ページの説明書を読め、
なんて要らないんだよ。可能であれば、それ以前のユーザーがやっていた方式と
出来るだけシームレスに接続出来た方がいい。
だからこの点は、Subversionの方が仕様として正しい。
上書き切換方式がよければ、Opt-inにすべき。
ただ高級機は必要ではあるので、ここら辺はGitが悪いと言うよりは、
普及機がないからそのまま高級機を使ってて愚痴ってる奴が悪い。
だから俺が普及機を用意してやる、ということ。
156: デフォルトの名無しさん (ﾜｯﾁｮｲ 2514-H0Ic) [sage] 2022/11/12(土) 20:16:31.82 ID:Cj/ueztB0(6/9) AAS
> であって、ツールを『何も使わずに』branchを用意する場合の構造と同じなんだ。
> 本来ツールは「使えば便利」で十分なんだよ。
その発想が根本的に間違っている
本来ツールは「なければ不便過ぎて苦痛」だから作られた
157: デフォルトの名無しさん (ﾜｯﾁｮｲ 2514-H0Ic) [sage] 2022/11/12(土) 20:18:52.70 ID:Cj/ueztB0(7/9) AAS
× ユーザーが求めていたもの： 手動ドリルだと手が疲れるので、
手が疲れないだけで、使い勝手や小回りの良さは手動ドリルと同じ程度の電動ドリル
○ ユーザーが求めていたもの： 手動ドリルだと作業が面倒すぎて時間がかかり過ぎで
現実時間で解決することができない。人間には不可能な問題を解決するためものが電動ドリル
158: デフォルトの名無しさん (ﾜｯﾁｮｲ 2514-H0Ic) [sage] 2022/11/12(土) 20:19:33.56 ID:Cj/ueztB0(8/9) AAS
Git： 短時間で遠くまで移動できる自動車
ただし取り扱い要注意なので免許を取れ
159: デフォルトの名無しさん (ﾜｯﾁｮｲ adc2-owoj) [sage] 2022/11/12(土) 20:27:52.45 ID:inQx9iPN0(3/3) AAS
force pushでもされない限り復旧不能なリポジトリ破壊なんてされないけどな
サーバー側でforce禁止にすればいいし
160(2): デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv) [sage] 2022/11/12(土) 20:40:30.40 ID:h41UD2lS0(27/29) AAS
まあとにかくだ、基本思想が違ってて、俺は「簡単は正義」だから、
Git： 使いこなせない馬鹿が悪い
俺： 難しい物を作る馬鹿が悪い
で、平行線なんだよ。
ただお前らからは普及機は出てこないのは分かったから、俺が作るよ。
（もっと調査してからだが）
俺は、難しくなる妥当な理由があるのなら仕方ないが、そうでなければ簡単にしろ、で
ジョブスの「ボタンは一個にしろ！！！」は肯定派。(Apple使う気ないけどさ)
つかよ、Gitの勉強じゃなくて、お前らコードの勉強しろよ、だからな。
あのパッチの顛末、マジで酷いぞ。C読める奴が居たら本当に聞いてみ。
Git等のツールは、最終的にはソフトウェアのコードの品質を上げる為であって、
Gitに習熟したけど糞コードしか書けません、では完全に本末転倒だ。
161(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 1563-sfiH) [sage] 2022/11/12(土) 21:02:25.04 ID:403mRijK0(8/9) AAS
>>160
俺が作ると言うだけなら簡単
実際に作って公開しなければ口だけ番長と思われてお終い
162(1): デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv) [sage] 2022/11/12(土) 21:26:19.25 ID:h41UD2lS0(28/29) AAS
>>161
いや101の仕様で手こずると思ってるお前もかなりヤバいけどな。
これも周りにプログラマが居たら聞いてみ。
ただ、自分で使う用に動けばいい物と、他人が(デタラメに)使う用に作るのはだいぶ違うんだ。
だからきちんと状況確認して仕様はしっかり詰めるべきなんだよ。
Gitにはこの辺の感覚がない。
まあLinusが個人的に必要だから作った、完全特定個人向けチューニングだからではあるが。
この辺がGit(を使わされる側)の不幸なところだよ。
163(2): デフォルトの名無しさん (ﾜｯﾁｮｲ 2514-H0Ic) [sage] 2022/11/12(土) 21:31:32.81 ID:Cj/ueztB0(9/9) AAS
>>160
> Git： 使いこなせない馬鹿が悪い
> 俺： 難しい物を作る馬鹿が悪い
でも、難しいと思ってるはお前だけなんだ
お前が馬鹿というだけじゃね？
それとも完全自動運転車が登場するまで
ずっと無能呼ばわりされたいということかね？
164: デフォルトの名無しさん (ｱｳｱｳｳｰ Saa9-9aJV) [sage] 2022/11/12(土) 21:46:15.33 ID:M1Nw2seMa(1/2) AAS
>>163
流石にそれは言い過ぎ。
git は難しいよ。
環境の準備やチーム内のルールも知らないと仕事始められないので。
165: デフォルトの名無しさん (ﾜｯﾁｮｲ 4bcf-IBSA) [sage] 2022/11/12(土) 22:10:50.71 ID:ajB/boEg0(3/4) AAS
>環境の準備やチーム内のルールも知らないと仕事始められないので。
その点に関してはsubversionの方が難しい気がする。
166(3): デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv) [sage] 2022/11/12(土) 22:19:07.47 ID:h41UD2lS0(29/29) AAS
>>163
いや結局>>137なんだよ。
お互いの見解は異なるし、同意する必要もない。ただフォークすればいい。
俺は売れそうだと思ったら作るだけ、欲しい奴は乗っかればいいだけ、要らない奴は使わなければいいだけ。
俺は(というよりプログラマ全般は）ツールだけ使えてコード書けない奴は死ねばいいとしか思ってないから、方向性もいい。
俺の目論見が外れればお前らの勝ち、お前らが食うのに困れば俺の勝ち、勝敗はフォークで、だ。
俺が想定してるのが時代遅れで馬鹿だらけの現場なのか、お前らが壮大に勘違いしてたのかも、それで分かるよ。
ただ当たり前だがこのスレはGitを理解してるか、最低限理解しようとしてる連中の場所であって、
俺が相手にしようとしてる、理解する気もない連中の溜まり場ではないから、
壮絶アウェイになって然るべきで、散発でも賛同者や擁護が出てくる時点でヤバイと気づける位の方がいいと思うが。
スレは立てるが、肝心のアプリ名を今考え直してるところだから、来週まで待ってくれ。
GitBucket気に入ってたのにちくしょ～。
上下前次1-新書関写板覧索設栞歴
あと 836 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.031s