22/11/12 06:43:34.00 h41UD2lS0.net
>>90
Gitが提供しているもの： 1000ページの取扱説明書を読まないとまともに使えない、超高性能電動ドリル
ユーザーが欲しかったもの： 引き金を引けば回るだけ、簡単で今すぐ使える、ホビー用電動ドリル
102:デフォルトの名無しさん
22/11/12 06:46:43.39 h41UD2lS0.net
ちな、CodeOfConduct読んで、あいつら中の人か！ってのが分かったので俺的査定。
Avar Arnfjord Bjarmason: 今なんとか方向修正を試みてるように見える。上手く導ければ有能だが、果たして？
Christian Couder: 出てきてないので不明
Junio C Hamano: 休暇中？らしい (40)
Taylor Blau: 無能。ってか閻魔大王が全スルーするならいないのと同じ。ちゃんと門番やれ。
そういえばGitのコーディングルールはどこにあるのだ？
今回ほどの糞コードは、コーディングルールで引っかけて落とせるはずだが。
103:デフォルトの名無しさん
22/11/12 06:52:44.85 h41UD2lS0.net
>>89,94,95
全部読んだ。なかなか面白かった。(89はコメントも全部読んだ)
君が冷やかしかマジかは分からないが、マジで要るんなら作ってみてもいい。
ただし今すぐ取りかかれるわけでもないし、全般的に考えて本年度末(3月末)位が現実的な目標になる。
今考えている構成をざっくり言うと以下
・Gitをゴミ箱/バケツ化するラッパ(フロントエンドのみ。バックエンドはGitで、Gitは別インストール必須)
・electronで作ってwindowsストアに配置(広告付き無料アプリ)
十分売れてる限り保守してやんよ(その必要すらないほど単純なアプリだが)
・プロプライエタリで伽藍開発。バザールなんてとても無理。コードは俺が書くから、お前らは使い勝手をフィードバックしろ。
・GitBucket(仮称)、Gitと付けたら不味いのなら考え直す
・コンセプトは、「何も知らなくても使える『全自動完全履歴保持バケツ』」
よって仕様は限りなく簡素化し、それ以上やりたければDBはgitだからgitアプリ使え、とする
・diffは取れるがmergeは直感的GUIがないので無理。が、主にバイナリを保存する連中には全く関係ないし。
・branchはディレクトリに割り当てて手動で。というより、git内にcommit履歴が保持されてないのでbranchの識別が出来ない。
104:デフォルトの名無しさん
22/11/12 06:54:37.10 h41UD2lS0.net
実装するだけなら2週間程度で十分だが、
・electron使ったこと無いので調査に2週間ほどかかる
・アプリストアも広告付きのアプリも作ったことないので、これも2週間ほど調査必要
・仕様を練らないとろくな事にならない、
Linusが2週間と言ってるのは実装であって、それ以前にずっといろいろVCS使ってきてるから仕様が熟成済みだっただけ。
・そもそも顧客がいるかどうか
・一応は他WindowsGitアプリを全部確認する必要がある。今tortoiseGit試しにインストールしてみたところ。
があるので、冷やかしでないのなら新しくスレ立てて様子見する。
スレタイには GitBucket(仮称)と、何か「Gitはもう諦めた系」「頑張らない系」の連中を集められる文言を入れたいが、何がいいか。
板はここかソフトウェア板だと思うが、他に候補があるか。
ただ対象ユーザーはここに来る連中ではなくガチのど素人なので、もっと全然違うところの方がいいかも？
スレタイ案：
A. もうGitBucket(仮称)でええやん。
B. GitBucket(仮称)使ってるからって、Gitが分からなかった訳じゃないんだからねっ！！！
C. GitBucket(仮称)計画中、Gitに疲れた奴集まれ
D. 日常のバックアップツールGitBucket(仮称)
冷やかしじゃない奴からの投票を受け付ける。
105:デフォルトの名無しさん
22/11/12 06:57:39.26 h41UD2lS0.net
>>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を使う人も使わない人も問題ない)
106:デフォルトの名無しさん
22/11/12 09:27:34.24 xzRuq+6da.net
electron 使うなら、ブラウザ上にOSのデスクトップ画面を再現するのと同じ事ができるだろう。
ゴミ箱/バケツのところでなくて、デスクトップに置いて管理されている事になっているファイルをコントロールできるようにして欲しい。
107:デフォルトの名無しさん
22/11/12 09:30:46.94 Cj/ueztB0.net
>>98
> Gitはパッチ適用ツールであって、本当に、パッチ書く側のサポートが全くない。
パッチ適用ツールはpatchコマンドっていうんだよ
gitはそれ以上のサポートがたくさんある
これ以上何がほしいいっていうんだよｗ
108:デフォルトの名無しさん
22/11/12 09:31:53.24 Cj/ueztB0.net
>>103
> 俺だったら、branchなんて、各ディレクトリにそのままマッピングする。
同じ名前のブランチが複数あることを想定してないね
ちょっと失格かな。
109:デフォルトの名無しさん
22/11/12 09:37:06.39 Cj/ueztB0.net
>>103
> というわけでGitBucketは基本この方針でmasterに全ての履歴を数珠繋ぎ、
ああ、GitとGitHubの区別もついてなさそうだね
110:デフォルトの名無しさん
22/11/12 09:39:05.08 Cj/ueztB0.net
>>103
> branch切換で全部上書きで入れ替わるのは、頻繁に過去と現在を往復するにはいい仕様だが、普通の人には要らん。
branch切り替えで入れ替わるのはコミットしたものだけだよ
これは便利でコミットしてない設定ファイルやデータファイルなどは
そのまま残る
こういうことまで考えつかなかったでしょ？ｗ
111:デフォルトの名無しさん
22/11/12 10:59:50.02 h41UD2lS0.net
>>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文字らしい)を越えると記録出来なくなる。
> URLﾘﾝｸ(learn.microsoft.com)
だからガチもん商用アプリではこの解は使えない。
(仮にルートに置いてもc:\の3文字は長くなるので、ユーザーファイルが合計258-260文字のパスになってるときに記録出来ない)
が、今回は、「そんな糞長いパスにするな」で終わり、諦める。(WARNINGは出す)
112:デフォルトの名無しさん
22/11/12 11:00:10.29 h41UD2lS0.net
てな話を仕様として詰める必要があって、つまり、
1. どういう機能が欲しいか
2. それはこの仕様(実装)でいけるか
みたいなこと。
ちょこちょこやるのはさておき、本格的にやるならスレ分けるべきだな、という話。
113:デフォルトの名無しさん
22/11/12 11:11:14.80 h41UD2lS0.net
>>105
commit/rebase履歴の全保持と、commitのフィルタ機能だね。
記録側からみればゴミなcommitも、プログラマからみれば重要なんだよ。だからそれを見えなくする機能だね。
CSSでいうdisplay:noneの機能。
今は、「綺麗に清書して＝プログラマには必要だったコミットも全部消して」提出しろ、になってるだろ。
これが無駄だし、プログラマ的には不快だ。
それは悪戦苦闘の記録であって、デグレードした場合に参照したい時もあるんだよ。消してるのは不味い。
ローカルだけにしろ、はその通りだが、今はローカルだけにも出来ない仕様だろ。(無駄にブロックチェーンしてるので)
114:デフォルトの名無しさん
22/11/12 11:11:41.80 h41UD2lS0.net
>>106
世界規模で勝手に開発してるLinuxならそうだろう。
しかし、ローカルファイルシステム、或いは共有ファイルシステムに於いては、当たり前だが「同じディレクトリ名」＝「同一」なんだよ。
だからディレクトリ名が被って困る、なんて事はない。
そして、バックアップ的には、branchはパスが伸びた程度の意味しかないから、これで問題ない。
(git流のbranchの使い方をしてても、これで問題ない。
通常のファイルシステムでは、パス+ファイル名が同じなら同一と見なすが、
ここがgitではパス+ファイル名+ブランチ名になってるだけ。
branch自体の参照先も変えられる！と思うかもしれんが、それはユーザーがそうしたのであって、
確か○月○日頃の○○ブランチ内にそのファイルがあるはず、と思い出すのはユーザー責任だ。
いずれにしても何処かに記録はされてるから、あとは頑張って探せという仕様)
115:デフォルトの名無しさん
22/11/12 11:13:16.58 inQx9iPN0.net
git関係ないけどWindows10 1607以降はMAX_PATH制限なくなってるんだな
116:デフォルトの名無しさん
22/11/12 11:13:17.79 h41UD2lS0.net
>>108
知ってるぞ。
ただ、切り替わらなくてもいい共通ファイル類はその場合には .git 階層に置くんだよ。
というかね、gitが何故か「カレント主義」になってて、とにかく「カレントディレクトリ」なんだよな。
これは本当によく分からない。
俺がGitGUIで最初にやったのは、「Open repository ...」を探すこと、だからな。
無いから、「え？まさか？カレントで起動しないと駄目なのか？」でわざわざショートカット作り直して起動し直した。
普通そんなアプリ無い。この辺は、「いつも通りのアプリ」じゃないと駄目なんだよ。
117:デフォルトの名無しさん
22/11/12 11:26:13.02 403mRijK0.net
>>101
仕様や開発グループがグダグダだと思っているものをバックエンドにするのか
「gitがグダグダだからできなかった」と言い訳して終わりそう
>>103
mergeのことは考えてないんだな
118:デフォルトの名無しさん
22/11/12 11:28:11.58 zxvXZjfz0.net
>>102
投票とかどうでもいいから早く別スレ行け
馬鹿向けのアプリは馬鹿だけが多数寄ってきて繁盛するからそっちで頑張れ
git は馬鹿には使えないことが理解できたんだろ
119:デフォルトの名無しさん
22/11/12 11:37:38.69 zxvXZjfz0.net
>>103
ブランチにディレクトリを使うのは既に subversion がやって失敗した道だぞ
ファイル数やファイルサイズが大きくなるとブランチ切るのに時間とディスク容量がかかり過ぎる
過去話読んでも何も学ばないやつはゴミを再発明するよな
とはいえ、お前やお前が想定しているユーザー層はたいした規模のプログラム組まないだろうからゴミでも十分かもな、知らんけど
120:デフォルトの名無しさん
22/11/12 11:45:13.42 h41UD2lS0.net
>>115
車輪の再開発はしないんだよ。
どこまで使えるか判断して、その範囲は使うし、それを超えた範囲は使わない。
(今の実態だと、git add 絶対パス、はほぼ確実にバグを踏むから使わない)
自分で作ればバグがない物が簡単に出来るわけでもないし。
> mergeのことは考えてないんだな
GUIでmerge、例えばドラッグアンドドロップでmergeは怖いだろ。
コピーするつもりがmergeされたら悲惨なことになる。
(コピーや移動と同じGUIにmergeをアサインしてはいけない）
だからmerge自体はgitアプリで明示的にやれ、という仕様。その方が安心だ。
そもそもバイナリはmerge出来ないし、
GitBucket使うような連中にはmergeなんてほぼ要らん。
てゆうかね、そもそもmergeが主な仕事ならgit使うべき。あれは完全にmerge特化型だから。
GitBucketのユーザーは、そのmergeのネタを作る側、つまりプログラマとかクリエーターとかだ。
管理側じゃなくて、管理される側。
121:デフォルトの名無しさん
22/11/12 11:59:07.72 zxvXZjfz0.net
>>111
アホでやんの。マニュアル斜め読みしただけで実際に使用してないので本質が見えてないな
rebase する前に新しいブランチ切ってやれば
rebase前とrebase後の両方残せるという基礎の基礎すら理解できてないのか
普通はそうやって使うんだよ。マージも一緒。
ブランチが軽量で好きなだけ切れるので情報残したい数だけブランチを切ればいいだけだよ
rebase --keep-base みたいな使い方もあるけど基本が理解できてないやつは混乱するだけだろうな
122:デフォルトの名無しさん
22/11/12 11:59:16.76 403mRijK0.net
>>118
× mergeが主な仕事ならgit使うべき。
○ mergeを使う可能性があるならgitを使うべき
長文君ソフト(仮)ではmergeのことを考えてないんだから
すでに書かれてるけど他のスレに行ってくれ
仕様の検討も含めてそっちでやればいいんだから
123:デフォルトの名無しさん
22/11/12 12:01:03.49 h41UD2lS0.net
>>117
ああその失敗情報は有り難い。
ただ、そこは理論的に問題ない。
技術的には、Gitでもカレントを「上書き」するのだからコピーと同じだけのI/Oが必要であり、
I/Oバウンドの場合、GitでもSubversionでもその部分の処理時間は同じになる。
(Gitのbranch切換とSubversionのブランチ作成が同じI/O負荷）
そこで速度差が出るのだから、実際は、86で既に言ったとおり、Subversionが各ソースを「展開」するのが遅くて、
それはおそらく順方向履歴しか持ってないからだ。
(逆方向履歴持ってれば、commitは早くならないかもしれないが、branch切り出しはコピーと同速に出来る）
ここら辺はSubversionの基本アーキが腐ってるからだが、
この点GitBucketは中身Gitだから、コピーするだけで、結果的には本家Git（上書きするだけ）と同速だよ。
そのコピーが重い？
だったらbranch切換セレクタだけは付けるから、それで勝手に自前で管理しろ。
バックアップツールとしては、branchはパスが伸びただけの意味しかないからそうする、というのは112の通り。
コピーオンライトのファイルシステム、つまりハードリンクにする手もあるけど、これはユーザーが付いて来れないだろ。
ならコピー時間待たせた方がいい。
124:デフォルトの名無しさん
22/11/12 12:09:47.00 h41UD2lS0.net
>>119
> rebase する前に新しいブランチ切ってやれば
そこはbranchではなくてタグだとは思うが、要はそれ、gcされないようにポインタ残してるだけだろ。
しかし開発しなくなったbranchは刈り取れ、というのが一般の使い方だろ。（それが推奨されてるように見える）
そもそもgcされないようにxxする、というのが間違ってるんだよ。
そんなところまでユーザーが密結合すべきではない。
普通にオススメ通りやったら、探せば何処かに履歴はあるよ、程度じゃないと。
まあ--keep-baseについては見てみるよ。
Bookの方が断然良かったのでman の方読むの止めてたから、知らなかった。
125:デフォルトの名無しさん
22/11/12 12:11:08.00 zxvXZjfz0.net
>>121
お前、作成の負荷と切り替えの負荷の区別ついてないだろ
実用上で問題になるのは作成の負荷、切り替えはディレクトリ方式の方が軽いけどそこは重要じゃない
126:デフォルトの名無しさん
22/11/12 12:15:51.67 zxvXZjfz0.net
>>122
必要なものには後で探せるように名前をつけておく。
名前のないものはいらないものなので掃除の時に捨てる。
基本中の基本すら理解できないの？
127:デフォルトの名無しさん
22/11/12 12:18:07.20 bWvYfJDZ0.net
Subversion のブランチ作成がファイル数やサイズで重くなるとか・・・
てきとうなこと言うやつが二人になってカオス。二人とも早く別スレに行くか黙るかしてくれ。
128:デフォルトの名無しさん
22/11/12 12:34:32.74 ajB/boEg0.net
GitBucket をdisってんのかと思った。
その名前はもう使われてるから変えろバカ。
129:デフォルトの名無しさん
22/11/12 12:54:11.71 h41UD2lS0.net
>>120
多分な、開発現場において「ファイル内の」mergeが日常ってのはあまりないと思うぞ。
それは各自が勝手にどのファイルをどういじってもいい、ということだから。
gitによって開発フローが変わった！ってのがこの辺かもしれんが、
普通は担当を振り分けて、結果的に
「この期間にこのファイルを触るのは○○だけ」
と交通整理される。
同時に変更する必要があれば、同じ奴に同時にやらせるだけ。（注文が増えるだけ)
そして各自が変更したファイルをかき集めて、くっつけて終わりだ。
お前らはこれもmergeと言ってる気がするが、
これは「更新日時が新しければ上書きする」だけの話で、手動でも楽勝だし、
プログラマはこれをmergeとは言わない。
プログラマが言う「ファイル内」のmergeが日常的に発生するかどうかはその部署のオペレーションによる。
(が、会社とか統制取れる場所でこれをする意味はないから、OSS以外ではほぼないと思うが）
130:デフォルトの名無しさん
22/11/12 12:57:01.77 h41UD2lS0.net
>>126
了解。考え直すよ。一度位ググるべきだったわ。
131:デフォルトの名無しさん
22/11/12 13:00:04.63 zxvXZjfz0.net
>>125
お前的には svn copy だけがブランチの作成で svn checkout は不要という主張したいの？
svn 的には checkout までが作成で、ブランチの切り替えは cd じゃないか。
オフトピなので svn の思想の話を続ける気はないけど、気になった。
132:デフォルトの名無しさん
22/11/12 13:08:13.18 403mRijK0.net
>>127
結局これだろ
mergeを使う可能性があるなら長文君ソフトでなくgitを使うべき
gitのスレなのにmergeの意味が違うとか言い出すし…
133:デフォルトの名無しさん
22/11/12 13:18:34.58 h41UD2lS0.net
>>130
つまりお前らGit屋の要求仕様は、
ファイル内のmerge：要らん
ディレクトリ内のmerge(=新しい方を取るだけ）：要る
ってのか？これなら手動でやった方が楽だよ。
普通にゴミ箱＝エクスプローラ的GUIになんだから、日付でソートして纏めて選択して持ってくだけ。
いちいち「オレオレアプリ的merge」とか用意するから余計混乱する。
使い慣れたエクスプローラで苦も無く出来るのだから、それで十分なんだよ。
134:デフォルトの名無しさん
22/11/12 13:25:22.90 403mRijK0.net
>>131
訳のわからないこと言ってないで、とっとと長文君ソフト(仮)スレ立てて移動しろ
135:デフォルトの名無しさん
22/11/12 13:25:51.41 zxvXZjfz0.net
>>131
そんな低レベルの話してるのはお前だけだぞ
136:デフォルトの名無しさん
22/11/12 13:45:55.74 /s1n3tt70.net
>>127
> 普通は担当を振り分けて、結果的に
> 「この期間にこのファイルを触るのは○○だけ」
> と交通整理される。
いつの時代のこと言ってんの？待ちが発生すること自体問題とは考えないの？
> 同時に変更する必要があれば、同じ奴に同時にやらせるだけ。（注文が増えるだけ)
> そして各自が変更したファイルをかき集めて、くっつけて終わりだ。
> お前らはこれもmergeと言ってる気がするが、
> これは「更新日時が新しければ上書きする」だけの話で、手動でも楽勝だし、
> プログラマはこれをmergeとは言わない。
更新日時見てマージとか、複数の人が並行開発した場合を考えてないよね
137:デフォルトの名無しさん
22/11/12 13:47:01.20 h41UD2lS0.net
>>132-133
最初に言っておくべきだったが、俺が作るアプリはお前らGit屋向けではないよ。
プログラマ、或いはクリエイター向けで、
Gitなんか勉強したくない、何でもいいからバックアップと履歴が取れてればいい、という人向けだ。
だから内部DBには都合がいい物を使うだけで、SQLiteもあり得るし、途中での変更もあり得る。
Git屋はGitを使うべきだよ。そもそもGitがGit屋向けフルチューンだし、
だからこそ文句言われてるわけだが、目的外使用なのだからLinusから見れば完全に筋違いだ。
なら、俺が「プログラマ/クリエイター向け」のツールを提供しよう、というだけ。
138:デフォルトの名無しさん
22/11/12 13:49:39.50 zxvXZjfz0.net
>>135
だから、このスレでやるな。
自分のスレ作って引き籠もれ。
139:デフォルトの名無しさん
22/11/12 13:51:09.55 h41UD2lS0.net
>>134
それなら、お前にはフィットしないだろうし、お前の周りはGitを引き続き使えばいいだけ。
俺は127方式やもっと小規模(個人)レベルでの開発を想定したツールを提供するだけ。
目論見が外れてたら、思ったより売れなくて、俺の骨折り損なだけ。
これで何の問題もないだろ。
140:デフォルトの名無しさん
22/11/12 14:12:47.90 403mRijK0.net
>>137
長文君ソフト(仮)ではmergeのことを考えてないから
mergeを使う可能性があるなら長文君ソフト(仮)ではなくgitを使うべき
ってことだろ。なんなんだよGit屋って。
とっとと長文君ソフト(仮)スレ立てて移動しろ
141:デフォルトの名無しさん
22/11/12 14:55:15.80 h41UD2lS0.net
>>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でいい)
142:デフォルトの名無しさん
22/11/12 14:56:22.97 h41UD2lS0.net
>>138
プログラマ： 主にソースコードを書いてる連中
クリエイター： 例えば主にフォトショで絵を描いてる連中
Git屋： Gitを操作することが主な仕事(>>83内のGit用員)、ソースコードは書けないし、絵も描けない
143:デフォルトの名無しさん
22/11/12 15:04:56.83 ajB/boEg0.net
まあ、こうやって素人考えをぶつけてみることでgitの良いところを再認識できるのであれば
まったくの無駄ではないのかもしれまい。
144:デフォルトの名無しさん
22/11/12 15:24:26.31 h41UD2lS0.net
>>141
× Gitの良いところ
○ Gitと被るところ
バックアップツールで必須な
・更新されたファイルを保存しておく
・変更されてないファイルは改めては取得しない
・変更履歴も保持し、必要なら古いファイルも取り出せる
・可能なら定期的に圧縮する
をGitが持ってるから、目的外使用されてるだけだな。
まあ基本アーキがいいから目的外使用でも本来ツールと戦えるということではあるけど。
ただ変更を酷く許してないところは頂けない。ここは俺はぶち壊す予定。
(間違ったファイルをコミットして大騒ぎ、結局全部作り直し、みたいのを無くして、ファイルを普通に消せるようにする。
ハッシュがずれたところで、ツリーには関係ない)
Gitのバックエンドは出来がいいんだと思うよ。多分。（俺が問題に遭遇してないだけかもだが）
Gitが糞なのは、フロントエンドと、仕様だね。ドキュメントは多すぎるが、よく書かれているし、少ないよりは断然いい。
145:デフォルトの名無しさん
22/11/12 15:51:38.43 pkT2sKDg0.net
どうでもいいが95%はコード書いて検証してる時間で、複数人でレビューしながら開発とかでない限りGitに使う時間って5%くらいだろ。
皆プログラム書きつつGit触れて普通だと思うんだけど。それこそWeb業界では。難しいことになるときがないとは言わないけどたまーにでしょ。
グラフィックの感性で勝負とか、そういう特殊な世界のプログラマー以外でWeb系でGitも使えないんじゃ普通仕事にならないけどな。
146:デフォルトの名無しさん
22/11/12 16:11:19.82 zxvXZjfz0.net
>>142
git はバックアップツールじゃないぞ。
料理に例えるならお前が欲しがってるのは出来た料理を保管するための冷凍庫。
git が提供してるのは料理を作ったりアレンジするためのレシピ本(とその編集機能)
あとお前の言う「プログラマ」って、単なるコーダーで、本物のプログラマじゃないだろ。工場で刺し身にタンポポ載せてるやつは料理研究家じゃないからな間違えんなよ。
147:デフォルトの名無しさん
22/11/12 17:09:07.94 403mRijK0.net
>>140
長文君はgitをバックアップツールとしか見てないのに、Git屋というそのためだけの要員を
わざわざ雇っている会社があるという妄想に取り憑かれているんだな
148:デフォルトの名無しさん
22/11/12 17:57:20.46 h41UD2lS0.net
>>143
いや5%(=24分)も十分多すぎだけどな。
まあそれはさておき、コードと開発体制も糞だったのを忘れてたから、
Gitの良い所： 基本アーキ、バックエンド、ドキュメント
Gitの糞な所： フロントエンド、仕様、コード、開発体制、(ドキュメント多すぎ)
となる。ここで、駄目なところは全部マネジメントに起因してる。
一般の会社なら課長/係長クラスで締める部分が締まってない。
これは指揮系統を持たない「バザール」の宿命で、他知らんけどこんなもんなのかもしれないが、
OSSという意味ではchromeとかもっとガッツリやってる（ように見える）し、少なくともregressionテストは流しまくってる。
あっちはGoogleが締めてるのかもしれないが、Gitは見た目1本もregressionテスト流してないのは駄目だろ。
Subversion(58内記事)ではregressionテストに落ちたらcommit禁止だったらしいし。これが普通。
CVSはこの辺ガッツリやりすぎて、テスト用の3万行超のシェルスクリプトに
(自分がcommitする部分の為の)新規テストを追加しなければcommitしちゃ駄目、とかで問題だったとも書いてあったが。
>>144
料理の味で勝負をしたいのに、冷蔵庫の使い方を100時間かけて勉強して、
冷蔵庫のご機嫌を取らないといけない事に、みんな文句言ってるんだよ。
ただこれはテクノロジーが達してないだけではある。
昔は航空機関士が同乗してたように。（乗ってて何とかなったとはとても思えないが、それはそれ)
今はGit屋が必要なレベルで、じきにもっと簡単な物が出てきてお役ご免になるはず。
出てこないようなら俺が作るよ、ということ。
149:デフォルトの名無しさん
22/11/12 18:26:38.13 zxvXZjfz0.net
>>146
だから料理の「レシピ本の作り方」をどんなに読み込んでも冷凍庫の使い方は載ってないぞ。少しなら冷凍庫の使い方のヒントになる部分もあるので勘違いしてるんだろうけど。
冷凍庫欲しかったた冷凍庫買え。レシピ本に冷蔵庫の代わりを求めるな。
150:デフォルトの名無しさん
22/11/12 18:35:41.91 403mRijK0.net
>>146
俺が作ると言うだけなら簡単だ
スレ立ててそっちに移ることすらできない奴でも
俺が作ると言うことはできる
151:デフォルトの名無しさん
22/11/12 18:40:42.95 inQx9iPN0.net
うちの会社にも取引先にもgit使えないプログラマーなんていないけど
git屋わざわざ雇ってる会社のプログラマーてアホばっかりなん
152:デフォルトの名無しさん
22/11/12 18:42:32.33 h41UD2lS0.net
>>147
料理人： 冷蔵庫なんてブッ込んでおけば冷える、で十分
Git： 正しいブッ込み方じゃないから直せ、いやそもそもブッ込み方を知らない奴が使うな！と文句を言う冷蔵庫
153:デフォルトの名無しさん
22/11/12 18:55:39.59 h41UD2lS0.net
>>149
> 公開リポジトリにプッシュしたコミットをリベースしてはいけない
> URLﾘﾝｸ(www.git-scm.com)
これは既知の問題だけど、これが既知とされるまでにだいぶ大騒ぎしてるはずだよ。
プルリクして、公開リポジトリの操作自体は分かってる奴がやる、
(その時点でおかしい構造ならまずローカルを修正させる）
というのがセオリーなんだろうけど、それをやるのがGit係＝「Git屋」だよ。
他のVCSだとそもそもおかしい操作ができない(=操作出来る範囲が最初から制限されまくってる）からそうはならない。
全世界で唯一の履歴を持つんだ！とか壮大な風呂敷広げてるからこうなる。
ローカルリポジトリは好きにさせて、リポジトリ単位ではなく、commit単位での同期で十分だったはず。
154:デフォルトの名無しさん
22/11/12 18:56:07.38 zxvXZjfz0.net
>>150
git: レシピを他の人と共有したりアレンジ料理のアイディア出しに使うツール。
そもそも冷凍庫が欲しい人はお呼びじゃない。どっか行け
155:デフォルトの名無しさん
22/11/12 19:00:06.45 zxvXZjfz0.net
>>151
既知も大騒ぎもない。最初からだよ。
理由が分からない時点でおっさし案件
156:デフォルトの名無しさん
22/11/12 19:46:47.33 Cj/ueztB0.net
>>114
> ただ、切り替わらなくてもいい共通ファイル類はその場合には .git 階層に置くんだよ。
複雑な仕組みを入れるな。
gitは、gitを使わない場合と全く同じ形のディレクトリ構造に保たれている
バージョン管理をしない通常の開発フェーズでは、gitを使わないのと全く同じ
お前が言うやり方では、gitのためにディレクト構造を作らないといけなくなる
あ～ほらし
まあね、この程度なんだよ
157:デフォルトの名無しさん
22/11/12 20:11:12.01 h41UD2lS0.net
>>154
> gitのためにディレクト構造を作らないといけなくなる
ここら辺がGit信者が勘違いしまくってる点だよ。
これは
× Gitの為に
○ branchの為に
であって、ツールを『何も使わずに』branchを用意する場合の構造と同じなんだ。
本来ツールは「使えば便利」で十分なんだよ。
例えば何度も言われてる「電動ドリル」なら、
ユーザーが求めていたもの： 手動ドリルだと手が疲れるので、
手が疲れないだけで、使い勝手や小回りの良さは手動ドリルと同じ程度の電動ドリル
であって、
Git： 世界中どんな物にも穴が開けられる据え付け型超高性能電動ドリル、
ただし取り扱い要注意なので1000ページの説明書を読め、
なんて要らないんだよ。可能であれば、それ以前のユーザーがやっていた方式と
出来るだけシームレスに接続出来た方がいい。
だからこの点は、Subversionの方が仕様として正しい。
上書き切換方式がよければ、Opt-inにすべき。
ただ高級機は必要ではあるので、ここら辺はGitが悪いと言うよりは、
普及機がないからそのまま高級機を使ってて愚痴ってる奴が悪い。
だから俺が普及機を用意してやる、ということ。
158:デフォルトの名無しさん
22/11/12 20:16:31.82 Cj/ueztB0.net
> であって、ツールを『何も使わずに』branchを用意する場合の構造と同じなんだ。
> 本来ツールは「使えば便利」で十分なんだよ。
その発想が根本的に間違っている
本来ツールは「なければ不便過ぎて苦痛」だから作られた
159:デフォルトの名無しさん
22/11/12 20:18:52.70 Cj/ueztB0.net
× ユーザーが求めていたもの： 手動ドリルだと手が疲れるので、
手が疲れないだけで、使い勝手や小回りの良さは手動ドリルと同じ程度の電動ドリル
○ ユーザーが求めていたもの： 手動ドリルだと作業が面倒すぎて時間がかかり過ぎで
現実時間で解決することができない。人間には不可能な問題を解決するためものが電動ドリル
160:デフォルトの名無しさん
22/11/12 20:19:33.56 Cj/ueztB0.net
Git： 短時間で遠くまで移動できる自動車
ただし取り扱い要注意なので免許を取れ
161:デフォルトの名無しさん
22/11/12 20:27:52.45 inQx9iPN0.net
force pushでもされない限り復旧不能なリポジトリ破壊なんてされないけどな
サーバー側でforce禁止にすればいいし
162:デフォルトの名無しさん
22/11/12 20:40:30.40 h41UD2lS0.net
まあとにかくだ、基本思想が違ってて、俺は「簡単は正義」だから、
Git： 使いこなせない馬鹿が悪い
俺： 難しい物を作る馬鹿が悪い
で、平行線なんだよ。
ただお前らからは普及機は出てこないのは分かったから、俺が作るよ。
（もっと調査してからだが）
俺は、難しくなる妥当な理由があるのなら仕方ないが、そうでなければ簡単にしろ、で
ジョブスの「ボタンは一個にしろ！！！」は肯定派。(Apple使う気ないけどさ)
つかよ、Gitの勉強じゃなくて、お前らコードの勉強しろよ、だからな。
あのパッチの顛末、マジで酷いぞ。C読める奴が居たら本当に聞いてみ。
Git等のツールは、最終的にはソフトウェアのコードの品質を上げる為であって、
Gitに習熟したけど糞コードしか書けません、では完全に本末転倒だ。
163:デフォルトの名無しさん
22/11/12 21:02:25.04 403mRijK0.net
>>160
俺が作ると言うだけなら簡単
実際に作って公開しなければ口だけ番長と思われてお終い
164:デフォルトの名無しさん
22/11/12 21:26:19.25 h41UD2lS0.net
>>161
いや101の仕様で手こずると思ってるお前もかなりヤバいけどな。
これも周りにプログラマが居たら聞いてみ。
ただ、自分で使う用に動けばいい物と、他人が(デタラメに)使う用に作るのはだいぶ違うんだ。
だからきちんと状況確認して仕様はしっかり詰めるべきなんだよ。
Gitにはこの辺の感覚がない。
まあLinusが個人的に必要だから作った、完全特定個人向けチューニングだからではあるが。
この辺がGit(を使わされる側)の不幸なところだよ。
165:デフォルトの名無しさん
22/11/12 21:31:32.81 Cj/ueztB0.net
>>160
> Git： 使いこなせない馬鹿が悪い
> 俺： 難しい物を作る馬鹿が悪い
でも、難しいと思ってるはお前だけなんだ
お前が馬鹿というだけじゃね？
それとも完全自動運転車が登場するまで
ずっと無能呼ばわりされたいということかね？
166:デフォルトの名無しさん
22/11/12 21:46:15.33 M1Nw2seMa.net
>>163
流石にそれは言い過ぎ。
git は難しいよ。
環境の準備やチーム内のルールも知らないと仕事始められないので。
167:デフォルトの名無しさん
22/11/12 22:10:50.71 ajB/boEg0.net
>環境の準備やチーム内のルールも知らないと仕事始められないので。
その点に関してはsubversionの方が難しい気がする。
168:デフォルトの名無しさん
22/11/12 22:19:07.47 h41UD2lS0.net
>>163
いや結局>>137なんだよ。
お互いの見解は異なるし、同意する必要もない。ただフォークすればいい。
俺は売れそうだと思ったら作るだけ、欲しい奴は乗っかればいいだけ、要らない奴は使わなければいいだけ。
俺は(というよりプログラマ全般は）ツールだけ使えてコード書けない奴は死ねばいいとしか思ってないから、方向性もいい。
俺の目論見が外れればお前らの勝ち、お前らが食うのに困れば俺の勝ち、勝敗はフォークで、だ。
俺が想定してるのが時代遅れで馬鹿だらけの現場なのか、お前らが壮大に勘違いしてたのかも、それで分かるよ。
ただ当たり前だがこのスレはGitを理解してるか、最低限理解しようとしてる連中の場所であって、
俺が相手にしようとしてる、理解する気もない連中の溜まり場ではないから、
壮絶アウェイになって然るべきで、散発でも賛同者や擁護が出てくる時点でヤバイと気づける位の方がいいと思うが。
スレは立てるが、肝心のアプリ名を今考え直してるところだから、来週まで待ってくれ。
GitBucket気に入ってたのにちくしょ～。
169:デフォルトの名無しさん
22/11/12 22:20:47.69 /s1n3tt70.net
難しいなら入門書熟読すればいいし、わからないなら素直に聞けばいいんだよ
それすらやらず、ドキュメント読みたくないとか自分の思想に合わないからgitはクソだとか、小学生並みのわがまま言ってるから無能と言われる
170:デフォルトの名無しさん
22/11/12 22:27:14.56 zxvXZjfz0.net
>>166
git は馬鹿に売るために作った製品じゃないのでフールプルーフじゃないんだぜ。無料のオープンソースだからな。
作った人自身が使い易くて余計な時間を消費しないのが最優先。
文句あったらこれより良い製品をオープンソースで公開してみろ。ソース読んで良ければ尊敬するかもしれない。
171:デフォルトの名無しさん
22/11/12 22:54:07.27 ajB/boEg0.net
この手のツールは機能や使い勝手の多少の違いよりも信頼性や将来性が重要なものだからな。
コミュニティの立ち上げどころか協力者を一人集めることすら難しそうなこの人が何を夢見ているんだろうか。
172:デフォルトの名無しさん
22/11/12 23:22:40.78 zxvXZjfz0.net
長文君や長文君が利用者と考える馬鹿ユーザーは、信頼できるチームでメンテナンスが継続的なされるかとか、ツールに透明性があるかとか一切気にしないのかもしれない。
173:デフォルトの名無しさん
22/11/12 23:25:48.94 M1Nw2seMa.net
沢山語る事かある人達楽しそうだな。
VCS はエディタの補助機能で世代交代する事もあるけど、なんとなく使えてたらOK! って思ってた。
174:デフォルトの名無しさん
22/11/12 23:27:07.46 403mRijK0.net
>>162
作ると言ってるだけで作らず、皆が興味をなくすのを待つと思っている
ここで偉そうにするだけならそれで十分だからな
本当に作ると言うなら進捗状況を週に一度くらい公表すればいい
そのためにスレを立ててトリップを付けてでもいいしツイッターとかでもいい
実際にプログラムを書きはじめたらそれもどこかで公開する
進捗状況が分かるようにな
来年3月末目標ということで >>101
175:デフォルトの名無しさん
22/11/13 00:04:02.56 Qr8ucfLW0.net
どうせやるならgithubにあげて欲しいものだ
176:デフォルトの名無しさん
22/11/13 02:55:30.08 XlBdLl1o0.net
git にフォークなんて無いんだが。
git のあいうえおも分からないやつが
git の批判してても何も響かないんだよ。
いい加減去って欲しいわ。
177:デフォルトの名無しさん
22/11/13 05:33:33.29 S7gZHHW/0.net
これのソフト？は内容は世界中の人と共有されるの？分散型ってどういうこと？
178:デフォルトの名無しさん
22/11/13 06:54:51.14 Eh77ZCvU0.net
考えてみたが、やっぱGitは根本的に思想が俺とは違うんだな。
俺はツールはあくまでアプリの品質を上げる手段だと思ってる。
ここまではおそらく共通なのだが、問題はこの先で、俺は重要な順に、
A. アプリそのものの品質。つまり必要な機能に深刻なバグがないこと。コードの品質がこれに直結する。(コードが本体)
B. 使いやすさ。簡単は正義。使えない機能は存在してないのと同じ。直感的に使えればドキュメントすら必要ない。
C. 持続性。つまり自分が使いたい期間(未来)中ずっと使えるか。
なんだが、Git陣営は全く逆でC>>B>>Aの順に見える。
それはこのスレ内でも散見され、俺は釣りだと思っていたが、マジっぽい。つまり、
C. コミュニティに人を集めれば自然と持続性は確保出来る。つまり人数が一番重要。これを取り持つのがツール(ツールやcommitメッセージが本体)
B. ドキュメントを整備しまくれば、後はがんばって読めばいいだけ。
A. コードの品質なんて後から付いてくる。バグも誰かが勝手に直してくれる。
Git陣営はマジでコードの品質を上げる努力を何一つしてない。具体的には、
・regressionテストを1本も流してない。
・レビューも全くしてない。(マジで、見た瞬間落とされるコードを素通し)
・CodeOfCoductは重要だが、CodingRuleは要らない。
CodeOfConductは最近のポリコレで生まれた、「人の」振る舞いを規定するものだ。
これに対してCodingRuleは「コードの」振る舞いを規定するもので、
CodingRuleなしでCodeOfConductだけってのは、コードはどうでもいい、問題は人だ！と言ってるわけだ。
『人さえいれば、全て何とかなるんだ！』という思想だ。
ただ俺からすると、見る限り完全に「善意のただ乗り」であって、
少なくともコードの品質を上げる努力してないと協力する気にならないよ。
(ITがいくら自動化しても、最終的には人なのは事実としても、コードの質を直接的に改善する努力を全くしないのは不味いだろ)
179:デフォルトの名無しさん
22/11/13 06:55:24.88 Eh77ZCvU0.net
俺はコードの品質/アプリの仕様そのものが一番重要で、それさえあれば全てが上手く行く、と思ってる。つまり、
仕様が簡単で直感的なら、ドキュメントを整備するまでもないし、
バグがなければ、後は「十分動く」程度のメンテで済む。だから最初から出来る限り品質の高いアプリを投入すべきだ。
ここら辺は「伽藍」では共通認識のはず。『コード/仕様さえよければ、全て何とかなるんだ！』的な思想だ。
ただここら辺を「バザール」でひっくり返したから話題になったわけだが、やっぱこれは違うよな～とは思うよ。
これって「善意のただ乗り」の仕方が世界一上手かっただけで、みんながこれをやり出したら回らないよ。
180:デフォルトの名無しさん
22/11/13 07:21:09.51 MdOkAF1j0.net
>>176
> 考えてみたが、やっぱGitは根本的に思想が俺とは違うんだな。
思想じゃなくて、お前が単純にバージョン管理というものを知らんだけやで
自分が無知であることを知るのが成長の第一歩や
181:デフォルトの名無しさん
22/11/13 07:23:03.38 MdOkAF1j0.net
> 俺はコードの品質/アプリの仕様そのものが一番重要で、それさえあれば全てが上手く行く、と思ってる。
うん。やっぱり間違ってるね。
そんなんだから、POSIX原理主義者みたいに、一行書いてデバッグしていれば
バグなんか入らない！とかあり得ない主張をすることになるんだよ。
182:デフォルトの名無しさん
22/11/13 07:26:49.86 MdOkAF1j0.net
>>177
伽藍とバザールの話を知っているのであれば、
伽藍方式は間違っていたっていう結論だって知ってるよね？
183:デフォルトの名無しさん
22/11/13 07:49:57.39 Eh77ZCvU0.net
>>179,180
(内容が違うが答えは同じで)
いやあれはそういう意味ではない。どう読むかも自由ではあるが。
ただやっぱり、ここら辺はフォークで決着すべきで、それが正しいんだよ。
各自が思う方向に、突っ走ってみればいい。
アプリの品質も、最終的にはユーザー数*満足度の総和だから、Gitのやり方が間違ってる訳でもないんだろうさ。
でも俺は違うと思うから、違う方向を試す。
184:デフォルトの名無しさん
22/11/13 08:08:13.98 md3JoP5e0.net
>>177
御託はいいから長文君ソフト(仮)作りにさっさと取りかかれ >>172
御託を並べるのは長文君ソフト(仮)を完成させ、それがgitよりも
使われるソフトになってからにしろ
gitを作っている人たちを皆が望んでいる物を知らないクソと罵っていたんだから
皆が望んでいるソフトを長文君が作れなければ長文君は皆に笑われる
さんざん偉そうなことを言っておきながらその程度かってね
185:デフォルトの名無しさん
22/11/13 11:08:14.23 4MPzkrV00.net
気に入らないなら自分で作ればいいだけの話
gitも元はそういう思想から生まれているんだし
それが出来なくて文句言うだけなのは恥ずかしい
186:デフォルトの名無しさん
22/11/13 11:25:35.33 Qr8ucfLW0.net
gi自体tの開発の流れってLinuxカーネル開発とほぼ変わらないと思ってるけど違うのかな
1回もレビュー通してないとかいい加減なこと言う人がいるので気になった
187:デフォルトの名無しさん
22/11/13 12:40:13.79 Eh77ZCvU0.net
>>184
全通しならレビューの意味がない。よく分からん所でなあなあでウェットなんだよ。
例えば>>58の中盤以降、「どうやってOSSを飼い慣らすか」になっててすさまじく気持ち悪い。
これはタイトル「オープンソースソフトウェアの育て方」からしてそうではあるけども。
しかも書いた奴がCVSにも相当関わってて、Subversionも率いてた奴だってのがかなりキテる。
そして同様の雰囲気をGitからも感じる。
俺は「自分が使ってるツールにバグがあるのは自分も困るので、協力したい」とか、
「自分もそれが欲しいから」という、
個人の利益の追求の方向が偶々揃った程度で連携すべきで、それで十分だと思ってるんだよ。
だから「売れそうなら作るし、欲しければ乗ればいいし、要らないなら無視でいい」になる。(166)
勿論解消も各自の自由で、売れなさそうなら作らないし、ゴミなら使わない、でいい。
極めてドライな連携だ。
そして一般的に匿名掲示板はこの程度だから、俺は気に入ってる。
対して上記本やGit、いかにcontributerを手なずけてコードをタダで貰うか、みたいになってて、本当に気持ち悪い。
それがLinusが世界一上手かったことではあるし、それが成立するという驚きが「伽藍とバザール」だけども。
>>95の内容も若干キモイ。
Linusの個人崇拝になってて、Linus自身はそれにちょっと困ってる、ってのは分かる気がするよ。
コードはコードの内容だけで評価するべきで、
誰が送ってきたとか、これまで彼がどれほど貢献したとか、そういうの、勘案すべきではない。
落とすべきコードはドライに落とすべき。
CodeOfConductでポリコレ宣言せずとも、こんな事はみんな普通にやってきたことだよ。
が、まあ何か思惑はあるのだろうよ。
究極のコードクレクレ君を見せてやるぜ！！！と言われてる状態なので、とりあえず見物だ。
188:デフォルトの名無しさん
22/11/13 12:51:13.66 QilzRsUJa.net
世間一般のgitユーザーって Sourcetree 使ってるんかな。
わかばちゃん、サルでもわかる、おもしろいほどわかる、あたりは GUI の使い方書いているみたいだし。
コマンドライン使う説明の本は中級に分類されてそう。
Linux で使っているので Win/Mac に Sourcetree 導入しようとも思わないけど。
189:デフォルトの名無しさん
22/11/13 14:05:38.02 cAl+3nYf0.net
>>186
vscode + GitLens + Git Graph おすすめ
Linux/Win/Mac 同じように使える
190:デフォルトの名無しさん
22/11/13 14:26:57.07 OYfEeFSra.net
>>187
ありがとう。
git は VSCode のサポートツールにしか見えないね。
191:デフォルトの名無しさん
22/11/13 14:31:18.44 md3JoP5e0.net
>>185
長文君の「ただ乗り」批判
長文君ソフト(仮)はその「気持ち悪い」やりかたで作られたgitにただ乗りするんだろ
192:デフォルトの名無しさん
22/11/13 14:56:08
193:.51 ID:8vm+7sfe0.net
194:デフォルトの名無しさん
22/11/13 18:44:25.19 Eh77ZCvU0.net
>>190
俺の価値観からすると、ツール使えるだけで、
肝心の、あのソースコードと開発体制と仕様のヤバさに気づけないのは、本末転倒だと思うけどな。
まあ平行線だからいいよ。決着はforkで、だ。
俺が作るツールは、君ら向けではないし、実際君らには無価値だよ。
そもそもGitを使ってるだけで、Gitを使う為のアプリではないからね。
(これが誤解の元だったから、Gitと冠するのは止めようかと思案中)
だから第一弾で君らが死ぬことはない。
Gitを殺せるとしたら第二弾以降だが、まあ、これも無理だろうよ。これが目的でもないし。
むしろ、Gitを目的外使用してる連中を引き受けるので、お前らは居心地がよくなるかもしれん。
Gitはmerge専用機としてはよく出来てるよ。
しかし一般開発には、通常commit(親が一つのcommit)の方が断然多くて、今使ってる連中の大半もそうだと俺は思うけど。
それはさておき、多分Gitや他気持ち悪い系OSSが維持出来てるのは、
初音ミクの時に言われた、「ヘタウマ」じゃないかと。
日清カップヌードルでも言われてるが、要は「チョイ足し」したくなる絶妙な「ヘタウマ」ならソースコードも集まりやすい。
Linusが書いた完全無欠のコードでは、誰も手が出せないからね。
だからソースコードがある程度ゴミなのは、成功してるOSSの宿命なのかもしれん。
界隈よく知らないけど、例の鳥の詩(国歌)、完成してる感があって2次が少ない(ほぼ無い)と聞くし。
195:デフォルトの名無しさん
22/11/13 18:50:03.67 2jgXqyDd0.net
まるで「描かないマンガ家」
196:デフォルトの名無しさん
22/11/13 19:03:22.84 53QTWROr0.net
>>191
無能は口を閉じろ
197:デフォルトの名無しさん
22/11/13 19:26:29.95 2N/MD+QP0.net
Gitと競ってたDVCSは他にもいくつもあったが全部消えた
198:デフォルトの名無しさん
22/11/13 19:35:13.58 md3JoP5e0.net
>>191
その「気持ち悪い」開発方法でしっかりしたソフトが開発できてるから
それをベースにするってことだろ
gitその他の開発方法にケチつけるならそれで開発されたものをベースにするなよ
始めてもいないうちから「第二弾」とかバカ過ぎる
大口叩いてないでさっさと作れ
検討したことや結果を公表する場所を決めて発表するくらいはすぐできるだろ
>>172 >>182
199:デフォルトの名無しさん
22/11/13 19:38:47.70 53QTWROr0.net
最強のバージョン管理ツールを
伽藍方式で今考えてるからちょっと待て
最初から完璧な設計でバグもまったくない
100年ぐらいかかる予定だ
200:デフォルトの名無しさん
22/11/13 20:22:53.70 Eh77ZCvU0.net
>>195
> その「気持ち悪い」開発方法でしっかりしたソフトが開発できてるから
> それをベースにするってことだろ
違うぞ。既に書いたが>>118,142
というかね、俺はその辺お前らGit勢とは違ってポリコレはしない。
コードに政治は持ち込まない。使えれば使う、程度だ。
SQLiteだとGitの再開発が必要になるのが無駄だ。SVNの方が良ければ乗り換えるかもだが。
(というかバケツ的使用感をSVNが提供してたらそれで終わり、俺がアプリ作るまでもない。
これって今無いのか？
逆にSVNもGitと同様政治的で、バケツなんて提供してヤラネ、学習して使え！
なら俺がバケツアプリSVN版も売れそうなら作るかもだが)
201:デフォルトの名無しさん
22/11/13 20:29:12.47 53QTWROr0.net
>>197
俺もお前が書いたものが使えれば使う
使えないから、使ってない。
で、いつになったら使えるようになるの？
使えないなお前
202:デフォルトの名無しさん
22/11/13 20:32:39.63 Eh77ZCvU0.net
>>198
>>101,102
203:デフォルトの名無しさん
22/11/13 20:45:04.99 jMRR13nV0.net
>>196
彼が作ろうとしてるのは、バージョン管理ツールですらないから(多分わかっていて言ってると思うけど)…
まあバケツ方式でstashしていくやり方でどうやってバージョン順序保証していくか見ものだね
以前彼が言ったように更新日時でとか回答するのであれば失笑ものだがw
204:デフォルトの名無しさん
22/11/13 20:48:41.26 5qv23escM.net
本屋でわかばちゃんを少し読んだけど、おじさんが読む本ではなかった。
205:デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv)
22/11/13 21:22:27.78 Eh77ZCvU0.net
>>200
> バージョン管理ツールですらない
Git屋からみればその通りだが、一般人にはこれで十分だ。
というかこの辺も既に書きまくってるが、
普及型で、>>155の様に、これまで手動でやってきた人が使用感そのままでただ楽が出来る程度を目指す。
(だから学習時間ゼロで済む。一番確実なのは既に知ってるGUI=ゴミ箱に合わせること。
意識高い系には馬鹿にされるだろうが、いいんだよこれで）
stashはしない。commitだけだ。
というか、実体はほぼビュワーだから、俺みたいに簡単を正義とするなら既にあるはずなので、妙だなあとは思ってる。
いずれにしてもWindows版のGUIは全部確認しないといけない。これにも時間がかかる。
今のところGitGUIとgitkは違う。tortoiseは、多分違う。
他はまあ、1～2月中位には全部見るかも、程度。
実装着手出来るとしたら3月だから、それまでに、程度で。勿論仕様も練らないといけないし。
でも、これもただの予定であって、予定通り行くかは分からんし、それ以前に売れそうにもなければ作らんし。
まあとにかく、根本的にアプリに対する思想が違うんだよ。
だから君達にはイメージ出来ない。
でも、ゴミ箱で管理する！と聞いて、ああなるほど、と思った人には、納得の出来だろうよ。
どっちが正しいかはforkで勝負だ。
206:デフォルトの名無しさん (ﾍﾞｰｲﾓ MMab-9aJV)
22/11/13 21:31:16.29 5qv23escM.net
次のカキコはβ版が出たらにしてね
207:デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv)
22/11/13 21:39:36.54 Eh77ZCvU0.net
>>201
それ、前にも少し気になったのだけど、
Git屋はまだ本が主流なのかい？
Web系だと本ではどうにもならないから、ここで初心者が「いい本はありませんか」と聞いてきても
「本なんて全部ゴミ。MDN読め」と返すし、同じノリの奴も多い気がするが。
俺自身、もう本屋に何年も行ってない、に近い。
だからサル先生とか馬鹿にしてるのも、よく分からない。
紙かWebかなんて、どっちに書くかでしかないだろ。
紙媒体なら信用出来るなんて時代はとうに過ぎてる。
そもそも紙媒体の編集者はその選別眼を持ってない。
お前らがあれが糞コードだと理解出来ないように、本職以外の奴が本職の専門家向けに情報を選別するのは無理なんだ。
そして連中はただの印刷業だから、ある意味売れそうなら印刷するだけなんだよ。
だから本当に酷い内容でも本になってたりする。
ただ問題は、初心者にはそれが酷いとは分からないんだよ。
だから俺は適当にググって評判が良さそうなところを読むだけ。
Gitの場合は確
208:かにBook読めではあるが、別にサル先生を馬鹿にする必要はあるまい。
209:デフォルトの名無しさん
22/11/13 21:44:03.68 md3JoP5e0.net
>>197
>どこまで使えるか判断して、その範囲は使う
わざわざそんなことをしてでも使いたいくらい
gitのコードはしっかりしているということだろ
「気持ち悪い」とか何とか言っててもそんなもんだ
210:デフォルトの名無しさん
22/11/13 21:59:49.24 Eh77ZCvU0.net
>>205
205： 連中がキモイとか言うなら、そいつらが作ったコードも使うべきではない
俺： コードにポリコレは持ち込まない。誰が(キモイ連中)が作ったかは関係なく、そのコードが正しく動く範囲なら使う。
お前らポリコレ過ぎる。コードはコード、作成者がキモかろうが関係ない。
というか、まあ、キモイとか言うなら使うな！というのがCodeOfConductだから、
205の姿勢はGit的には正しいのかもしれんが、とにかく俺はそうじゃない。
(この点も俺はGit勢には馴染まないから、やっぱ遠巻きに見守るべきだな。変に突っ込んでたら大騒ぎだったかもしれん)
しかしこの勢いだと、GPLv4にはポリコレが入って、「キモイとか言う奴には使わせない」とかになりそうだな。
笑えねえ。
211:デフォルトの名無しさん
22/11/13 22:01:41.86 md3JoP5e0.net
>>204
gitについて書かれた本を本屋で見た人がいるというだけなのに
>Git屋はまだ本が主流なのかい？
と言い出す長文君
何を参考にするかは人それぞれだろ、普通に考えて。
>俺は適当にググって評判が良さそうなところを読む
適当にググって評判が良さそうな本を買って読む人もいるだろうな
212:デフォルトの名無しさん
22/11/13 22:04:13.65 Eh77ZCvU0.net
>>207
いや本に噛みつかれないのがWeb系界隈とは明らかに違う。
213:デフォルトの名無しさん
22/11/13 22:05:05.41 jMRR13nV0.net
>>204
1000ページも読みたくない～とか意味わからんわがまま言って読むの放棄してる奴が何言ってんだかw
214:デフォルトの名無しさん
22/11/13 22:07:22.25 jMRR13nV0.net
> 「本なんて全部ゴミ。MDN読め」と返すし、同じノリの奴も多い気がするが。
> 俺自身、もう本屋に何年も行ってない、に近い。
じゃあ自分もこのノリで
「本なんて全部ゴミ。git-scm読め」
215:デフォルトの名無しさん
22/11/13 22:17:53.79 Eh77ZCvU0.net
>>205
ちなみに技術的な話をすると、
> gitのコードはしっかりしているということだろ
これは根本的に違ってて、要するに俺が楽したいだけなんだよ。
内部DBを外部ソフトに委ねるのは、最大の目的は、そのソフトのツール群を使えるようにする為。
最悪ユーザー側で何とでもなるというのは、ユーザーにも安心で、これは重要なんだよ。(POSIX君はこの点を問題視してるわけ）
そして外部ソフト自体がバグってても勝手に直してもらえる。
寄っかかることに抵抗がなければ、寄っかかった方がユーザーにも制作側にもメリットがあるんだよ。
(勿論囲い込みは出来なくなるが、最初からそんなのする気ないし）
デメリットは、その外部ソフトのバグもユーザーには俺のバグにに見えるから、俺がバグ対応窓口にさせられる可能性があること。
俺のバグなら致し方ないが、外部ソフトのバグなんて対応してられない。だから安心出来る範囲でしか使わない、ということ。
要は全部楽する為の方策であって、お前らみたいにポリコレまみれではないんだよ。
216:デフォルトの名無しさん
22/11/13 22:31:13.00 md3JoP5e0.net
>>206
ベースにしたくなるくらいしっかりしたソフトが開発された方法に
ケチつけるなって話だがな
>>211
寄りかかれば楽ができるくらいgitはしっかりしてるってことだろ
長文君はフォークフォークと言ってるだけで実際に何かを始めたわけではない >>195
217:デフォルトの名無しさん
22/11/13 22:41:49.45 m9TsWVuY6.net
Google driveに上書きしてくのじゃあかんの？
218:デフォルトの名無しさん
22/11/13 22:43:28.98 Eh77ZCvU0.net
>>212
それはベースにしてるわけではないんだよ。（つか俺がそう言ったっけ？なら訂正だが)
多分OOPの基本すら理解してない君達には通じないが、繰り返すと、
そこは即交換可能なんだよ。
少なくともGitとSVNはほぼ自動的にそうなる。（一般的に普通に組めば自然とそうなる）
SQLiteだとGitやSVNに入っているコードまで自前で書く必要があるから面倒だが。(だからこれはやる気なし)
ベースではなく、外注なんだよ。必要とあればすぐ交換可能だ。
つっても、通じないだろうけどさ。
219:デフォルトの名無しさん
22/11/13 22:46:32.10 CpNEOOBi0.net
Git（MSのDevops）にゼロからプルしたらフォルダが40バイトのファイルになったんだが仕様かね
220:デフォルトの名無しさん
22/11/13 22:48:27.87 Eh77ZCvU0.net
>>213
詳細仕様分からんが、割とマジでクラウドならデフォで入ってる程度かもな。
なるほど。
221:デフォルトの名無しさん
22/11/13 23:09:12.82 OYfEeFSra.net
Git の本は、利用者の裾野が広いせいでバカ向けに書いた本が出回るようになっているのか。
昔だと、教わらなくても Windows95 使えるけど、教えても使えない人の為の本が沢山出ていたのと同じ。
良いことじゃないだろうか。
222:デフォルトの名無しさん
22/11/13 23:15:04.42 md3JoP5e0.net
>>214
「外注」したものをベースにしてるってだけだろ
「すぐ交換可能」なら最初からgitをベースにせずに他のを使えばいいだけなのにできないんだから
昨日のことなのに忘れてるし
>>101
>Gitをゴミ箱/バケツ化するラッパ(フロントエンドのみ。バックエンドはGitで、Gitは別インストール必須)
>>199でアンカ貼ってたけど、読んでなかったのか読んだけど2時間ほどで忘れてしまったのか
223:デフォルトの名無しさん
22/11/13 23:35:45.59 Eh77ZCvU0.net
>>218
ベースとは言ってないだろ。
フロントエンド/バックエンドとは言ってるが。
それらはまるで意味が違う。
（というのも通じないからもう終わりにするが）
ちなSVNで最初から組むことも問題なく可能だよ。それがOOPでもあるし。
ただSVN確認するのが面倒なので、とりあえずGitで行くってだけで。
(SVNみたいな集中型は鯖立てが必要な可能性があるのでとりあえず敬遠《未調査》)
よく分からんけど、もしGitがお前の持ち物なら、ライセンス変更すればいいんじゃね？
お前の持ち物でもないのに文句言ってるんだったら、お前だいぶ狂ってるよ。
俺からみたら、Gitのコードが糞なのも、Git陣営の動きがキモイのも、事実だよ。
そういう俺が狂ってる、とお前が思うのも自由だが、コードについては第三者に判断可能だから、
お前の周りでCを「きちんと」書ける奴が居たら、今回の顛末見てもらえ、と何度も言ってる。
224:デフォルトの名無しさん
22/11/13 23:41:15.62 8vm+7sfe0.net
>>219
お前のいうきちんと書かれたCのコードって例えばどれよ？ お前の妄想内にしかないんじゃね？
225:デフォルトの名無しさん
22/11/13 23:46:17.04 UN9cy+Utr.net
>>219
持ち物ではないけど、自分が普段使ってるものに馬鹿だのクソだのいちゃもん言われたら文句言うの当たり前だろうがw
226:デフォルトの名無しさん
22/11/13 23:50:21.00 6O/r8caVM.net
どうでもいいが、バックアップ取りたいだけならrsnapshotとかあるけど知らないのかな
227:デフォルトの名無しさん
22/11/13 23:54:26.54 md3JoP5e0.net
>>219
gitがなければ機能しないものを作るってことなんだからgitがベースってことだろ
糞と思うなら使わなければいいだけ
長文君ソフト(仮)のベースとして役に立つと思っているから使うんだろ
長文君は実際に何かを始めたわけではないけどな >>195
228:デフォルトの名無しさん
22/11/14 00:09:27.46 0VMo1QiO0.net
OOPでGitとSubversionを問題なく交換可能かは、それこそ実際に結合テストしてから言ってほしいものだ。
Git開発陣営は少なくとも動くものを作っているけれど、
「OOPの原則に則れば交換可能でなければおかしい」なんてのは机上の空論でしかないし、せいぜい工学的仮説といったところだろう
作れてないんだから仮説の域を出ない。ちゃんと工学的に明らかにしてくれ。
229:デフォルトの名無しさん
22/11/14 00:11:39.84 aSCqNEw00.net
>>220
クレクレ君死ね。
ただ、Cのいわゆる伝統的手法は本当にみんなやってるから、そこら辺のCで見あたるよ。
そもそも大概それがCの糞な所とされてるので、見たこと無い奴はほぼ居ないはず。
これも何度も言ってるでしょ。
俺はもうお前らのフォローはしないと宣言したでしょ。
直接的には教えてやらないよ。
でも本当に
230:、Cを「きちんと」書ける人なら全員知ってるから、周りにいる人に聞いてみなよ。 実際問題として、仮に俺がここで丁寧に教えても、お前ら絶対信用しないだろ。 だから、君ら自身が信用出来る人に、直接聞くしかないんだよ。 つまりLinusがベストなんだけどさ。 或いは、これも既に書いたが、結局のところC++/C#/Rustでも同じ解だから、 これらの言語をきちんと勉強しても、同じ所に到達出来る。 だから自分だけで解決したいんなら、これらをやってみるんだね。 新しい言語は、古い言語の駄目なところを改善してるので、彼等がどこを問題視して、どう解決したかが、簡単に見えやすい。 LinusはC++を滅茶苦茶嫌ってて、まあその理由も分かるし、正直同意もするけども、 当たり前だがC++はCのベストプラクティス集みたいな所はあるので。(少なくともC++89/98は。その後明後日の方向に暴走中ではあるが》 あとそもそも最初に言ったが、今回は一番取り扱いが簡単なケースなんだよ。 こんなのでリークするのは、最初から構造がおかしいからだよ。 出来ないのなら、基本に忠実にやれ、でしかない。 ただ君らは構造を議論出来るレベルじゃない。まずはOOPの基本から勉強すべきだよ。
231:デフォルトの名無しさん
22/11/14 00:22:09.12 aSCqNEw00.net
>>224
完全に、じゃなくて、そりゃグルーは書くんだよ。
(まあオブジェクト内側にブチ込んでしまえば見た目完全にはなるが)
ただ、俺がやろうとしてることはVCSが普通に持ってる機能(のはず)だから、
VCS自体は何であれ多少の変更で動作するはずなんだよ。
てかお前らには構造の話は通じないから、ここら辺でいいか？
大体、ゴミ箱アプリの中身がGitかSVNかなんて、交換可能に決まってるじゃん。
むしろなんでそれが無理だと思うのかが俺には分からん。
232:デフォルトの名無しさん
22/11/14 00:32:35.55 aSCqNEw00.net
>>222
知らんが、要らん。
これなら手動でディレクトリごとzipしとく、の方がマシだ。
233:デフォルトの名無しさん
22/11/14 00:50:33.04 i6KxBWUg0.net
>>225
例えばgithubに上げられてるCで書かれてるソフトのうち、「きちんと」書かれていると
思うのをいくつか挙げて、それはgitと比べてどのように「きちんと」しているか説明することは
できないということで、「きちんと」したのは長文君の妄想内にしかないと思われてもしかたないな
>>226
そう思うのならgitの代わりに「コードが糞ではなく開発グループがキモくない」と思うのを使えばいいだけ
234:デフォルトの名無しさん
22/11/14 00:52:36.47 huosUPX00.net
>>224
交換可能なはずがないんだよね
そもそもSVNとgitでリポジトリの概念が違うんだから
あとgitは実行速度を重視した実装になっているけど、彼の言うOOPが取り込まれたら実行速度がどれくらい落ちるか、個人的には非常に興味があるね
235:デフォルトの名無しさん
22/11/14 01:28:19.71 0VMo1QiO0.net
>>227
またろくに仕様を調べもしないでzipのほうがマシとか言って、傷口を広げるだけですよ
人格攻撃ではないのだが、40代ぐらい、正しいCやOOPは出来るほどの技術力は実際にはあるんだが、
人格に難がありすぎてビッグマウスで信用されずWeb業界でやっと拾ってもらえて、
だがGitが使えずWeb業界でも疎まれていて、鬱憤を晴らしにここにきてるのかな。
Gitを使いこなせないレベルのHTML/CSS屋とかならまあ求められてるものが違うからGitわかんないってのもわかるんだけど、
正しいCとかOOPとか言ってるのにGit使えないというのは、SIerしか考えられない不思議。
236:デフォルトの名無しさん
22/11/14 01:31:10.94 0VMo1QiO0.net
>>229
まあ単なる経験則になっちゃうしgit-svnの実装の問題だと言われたら
コードを読んでない自分は反論できないので書かなかったけど、git-svnでどれだけ皆無理だと悟ったか知らないんだろうね
237:デフォルトの名無しさん
22/11/14 01:36:05.46 0VMo1QiO0.net
>>226
Gitのコミットはリモートリポジトリだったとしても必ず作業ディレクトリの.gitディレクトリに行われる一方で、Subversionのコミットはリモートリポジトリにする必要があるのに？
どのVCSも同じ機能があると思ったら大間違いだよ。CVSなんかかなり絶望的だと思うぞ(すまんCVSは流石に太古の昔しか使ってないので嘘かも)
238:デフォルトの名無しさん
22/11/14 04:51:45.99 PeuKV+c+0.net
「バージョン管理ソフトを利用したゴミ箱アプリの開発」
ただしSubversionを使うときはサーバーが必要です。
ファイルを削除するたびにリモートにファイルを保存したりします。
ってことやろ？
239:デフォルトの名無しさん
22/11/14 06:36:03.20 Vk7GKPFC0.net
>>225
長文君、どんどんボロが出るなあ
きんちとしたCのコードなんて基準も何もない妄想って認めてるんだね
240:デフォルトの名無しさん
22/11/14 07:31:46.61 aSCqNEw00.net
>>233
SVN全く調べてない俺が勝手に想像してるのはその形態。
鯖立てなんて出来ません！な連中に対応するつもりだから、鯖立て必須は厳しい。
ただ、どうもこのスレの連中は、本当に全くプログラミング出来ないらしい。
>>101,102読めば、ああなるほどね、と並のプログラマならぱっと分かる。
あまりにもトンチンカンな話が多すぎる。マジでお前ら、死ねとしか思われてないぞそれは。
241:デフォルトの名無しさん
22/11/14 07:32:21.12 aSCqNEw00.net
ただ、いずれにしてもキモイよ。少なくとも俺には。
俺が想像してた世界：
「はい、バグっぽい何か」「ああバグだね」「直しといたぜ、確認よろしく」「とりあえずこちらでは動いた」
俺が思う本来Gitがあるべき姿：
「そのバグパッチ作ってみました」
「う～ん、君のコードはこの点が問題だから、ここをこう直してくれないかな。そうすれば、もっといいコードになる」
「マジか、このOSSではLinusから直接、技術指導を受けられるのか。なるほど勉強になったぜ」
「次も書くぜ！Linusには悪いが、どんどん教えて貰う！！！」
GitやSubversion：
「はい、バグっぽい何か」
「あらいいプログラマね、お茶してかない？」
「いや俺が欲しいのはバグが無くなったソフトウェアであって、
お茶したいわけでもないし、そもそもお前らと仲良くなりたいわけでもないんだが」（＝「SNSでやれ」)
って書いてて思ったが、
SNS未発達時代のOSSはSNSも兼ねてて、こんなものなのかもしれん。
しかし今もそうなのはやはりキモイ。
完全にドライに技術的なら、CodeOfConduct(=ポリコレ宣言)なんてそもそも要らんし。
ただこれは俺が匿名文化に馴染んでるからであって、
一般人には実名SNS的対応の方が受けるのかもしれんし、まあご自由にどうぞ、ではある。
俺にはキモ過ぎて無理だな、ってだけで。
242:デフォルトの名無しさん
22/11/14 07:48:51.42 UbsjwJD50.net
>>236
これかかんの？
俺が想像してた世界：
略
俺が思う本来Gitがあるべき姿：
略
俺が実際にやってること：
わーわーわーわーわーわーわーわーわーわーわーわーわーわーわーわーわーわー
243:デフォルトの名無しさん
22/11/14 07:55:12.73 aaTBlyIu0.net
>俺はもうお前らのフォローはしないと宣言したでしょ。
わかったから他所でやれよ。有言実行。
244:デフォルトの名無しさん
22/11/14 10:23:41.00 TzEiJIKc0.net
ごっみばけっつの人はさっさと専用スレ作って移動しろよ
いつまでめーわくかけ続けるんだよ
245:デフォルトの名無しさん
22/11/14 10:26:41.02 a8E3Hx5Cr.net
長文さんってgit とgithubの区別ついてなさそう
246:デフォルトの名無しさん
22/11/14 11:29:40.73 i6KxBWUg0.net
>>211
>内部DBを外部ソフトに委ねるのは、最大の目的は、そのソフトのツール群を使えるようにする為。
>最悪ユーザー側で何とでもなるというのは、ユーザーにも安心で、これは重要なんだよ。
>そして外部ソフト自体がバグってても勝手に直してもらえる。
長文君が「糞と思っている」gitをベースにしようとするのは、
コードの品質/アプリの仕様そのものが一番重要で、それさえあれば全てが上手く行く >>177
というのは間違いと思っていて、gitがこうなっているから、ということだな
>C. コミュニティに人を集めれば自然と持続性は確保出来る。つまり人数が一番重要。
>これを取り持つのがツール(ツールやcommitメッセージが本体)
>B. ドキュメントを整備しまくれば、後はがんばって読めばいいだけ。
>A. コードの品質なんて後から付いてくる。バグも誰かが勝手に直してくれる。
長文君は実際に何かを始めたわけではないけどな >>195
247:デフォルトの名無しさん
22/11/14 11:40:54.89 i6KxBWUg0.net
>>236
さっさと長文君ソフト(仮)作りを始めて自分の理想のコミュニティを作ればいいのに
検討したことや結果を公表する場所を決めて発表することすらできずに
グダグダ言い続けるだけの長文君
248:デフォルトの名無しさん
22/11/14 12:29:56.96 EWF0SvAna.net
fork して branch した後なら
いくらでも rebase して
push -f しまくってる
249:デフォルトの名無しさん
22/11/14 13:09:25.49 EWF0SvAna.net
やっとここまで読んだ
GitPail がふさわしい名前だと思う
250:デフォルトの名無しさん
22/11/14 13:42:15.70 Vk7GKPFC0.net
git って一部でもつけんじゃねー、って思う。
勘違い君に文句言いにこられても困る。
251:デフォルトの名無しさん (ﾜｯﾁｮｲ 4b8f-X3QC)
22/11/14 18:27:40.45 huosUPX00.net
git rebase --ontoを今更ながら知ったが便利だなこれ
今までgit rebase -iした後色々こねくり回してたけど楽になった
252:デフォルトの名無しさん (ﾜｯﾁｮｲ 1514-H0Ic)
22/11/14 18:31:19.43 UbsjwJD50.net
>>246
長文「バックアップしたいだけなのにそんな難しい機能はいらねーよ！」
253:デフォルトの名無しさん (ﾜｯﾁｮｲ 4bbb-tcgO)
22/11/14 18:38:05.91 Vk7GKPFC0.net
>>246
欲しいって思った機能って調べるとだいたいあるよね。
254:デフォルトの名無しさん
22/11/15 06:02:57.49 DDE9IX5V0.net
OSSがコミュニティ的なら、例の「コミュニティの一生」も当てはまってしまうと思うんだよな。
> URLﾘﾝｸ(dic.nicovideo.jp)
【Gitの一生】
Linusが面白いことをする
↓
面白いから凡人が集まってくる >>95
↓
住み着いた凡人が居場所を守るために主張し始める
↓
Linusが見切りをつけて居なくなる
↓
残った凡人が面白くないことをする
↓
面白くないので皆居なくなる
>>176に書いたとおり、人数こそ力の源泉で、「人数の維持」が目的になってるように見える。
だけどそれは本来は手段で、「アプリの品質」を上げるのが目的でしょ。
(まあ賛同されるとは思ってないし、完全に平行線だが)
そもそもGitって今完全にメンテナンス状態？
つまり、本質的な新規機能要求(バックエンドに追加が必要)は無く、View(フロントエンド)をいじってる状態か？
ならまあ、実際面白くもないだろうよ。勿論メンテナはご苦労さんだが。
ああそういえばSHA256対応だっけ？あれは単なる作業だよ、本来は。チャレンジングではないから、面白くもない。
(つかこれがチャレンジングになっちゃうのはコードが糞だからだ。これも何度も説明したけどさ)
255:デフォルトの名無しさん
22/11/15 06:03:50.02 DDE9IX5V0.net
>>244
Pailは確かにいい。
ただ問題なのは、バケツは全員通じるが、ペール？？？な連中向け(俺含めて)のソフトだということだ。
256:デフォルトの名無しさん
22/11/15 10:54:20.75 ITVdMBx/r.net
チャレンジングなことしたことないやつほどそういう言葉使うよねぇ
エンジニアに妙な憧れ持ってそう
257:デフォルトの名無しさん
22/11/15 11:04:07.91 tWQzaYQC0.net
だから「バケツ(仮)」で新スレつくってそっち行け。git って付けなければ誰も文句は言わん。
258:デフォルトの名無しさん
22/11/15 16:01:59.97 u2Y2Sh
259:/m0.net
260:デフォルトの名無しさん
22/11/15 16:50:03.41 bU8+MPV6a.net
本探してたら、わかばちゃんの旧版の書評に
URLﾘﾝｸ(honto.jp)
>実は現場では、SourceTreeは重要でありながら、きちんと使える人は意外と少ない。
本来はこの手の専門家であるはずのプログラマーは、コマンドでGitを使うため、SourceTreeには縁がないからである。
知らなかった。
261:デフォルトの名無しさん
22/11/15 17:32:15.63 5R6vrZIA0.net
>>253
あるパッチの中にtypoしているのが後で見つかった場合どうするの？
そのパッチを他のブランチに適用する時困るでしょ
262:デフォルトの名無しさん
22/11/15 18:40:15.33 u2Y2Sh/m0.net
>>255
別にまた修正すればいいだけじゃね？
前のブランチに戻って修正するの？ｗ
263:デフォルトの名無しさん
22/11/15 19:22:21.43 5R6vrZIA0.net
>>256
ブランチが3つあったら
3回同じ修正しろって言ってるの？
ちょっと問題外すぎ
rebaseいらない。だって3回修正すればいい
だめだこりゃｗ
264:デフォルトの名無しさん
22/11/15 19:26:08.61 5R6vrZIA0.net
多分最新のコードを見ながら必要な部分を
目視でより分けて修正しろって言ってるんだろうな
265:デフォルトの名無しさん
22/11/15 19:33:40.07 oaKUlL5c0.net
うちは自分の作業中にもメインブランチがどんどん進むからローカルでrebaseしまくりだな
266:デフォルトの名無しさん
22/11/15 19:44:34.40 5R6vrZIA0.net
>>259
普通そうだよね
定期的にrebaseしてないとマージが面倒になるし
267:デフォルトの名無しさん
22/11/15 19:55:16.46 aKa6LP36a.net
長文さん、あぼ～んしたいからコテ入れてくれ
268:デフォルトの名無しさん
22/11/15 20:22:00.46 tWQzaYQC0.net
rebase 使わないとか git の利点半分くらい捨ててるぞ。
上で言われてるパッチ1個当てるくらいなら cherry-pick で済むけど
ブランチを再構成したり、コミットの順番を入れ替えたり、コミットを統合したり、分離したり、コミットメッセージを修正したり、使わない日がないくらいの万能ツール。
269:デフォルトの名無しさん
22/11/15 20:37:46.10 5r8tW8Xc0.net
>>261 今週のうちには専用スレに引っ越してくれるらしいよ。 >>166
> スレは立てるが、肝心のアプリ名を今考え直してるところだから、来週まで待ってくれ。
まぁまた言うだけでやらない理由を長々と説明（）しはじめそうな気はしてるけど。
270:デフォルトの名無しさん
22/11/15 22:12:13.74 u2Y2Sh/m0.net
>>257
言っている意味が分からんｗ
checkout -bした時点のbranchが間違ってましたって話？ｗ
どっちにしてもrebaseなんていらんよｗ
271:デフォルトの名無しさん
22/11/15 22:19:29.03 26oE0jcj0.net
>>263
後からどうとでもつけられるアプリ名を理由に挙げるくらいだからね
「アプリ名が気にいらないから他のを考える」とか言いそう
272:デフォルトの名無しさん
22/11/15 23:41:22.91 xjjxhqm80.net
rebaseに関しては
履歴を戻ってでもコミットとその流れを綺麗にしたい派
と
戻るの面倒だし汚くてもいいじゃん派
がいるから話が噛み合わない
273:デフォルトの名無しさん
22/11/16 00:06:32.65 cpWhvvM10.net
コミットも含めて作品
ゴミを作ってる人には rebase は不要
そもそも git 不要だな
274:デフォルトの名無しさん
22/11/16 02:10:40.58 cpGIBcGj0.net
>>264
だからコミットが複数に分割されてしまうから
rebaseして意味のある単位に整えるんだろうが
いちいちパッチ当てるときに、
あれとこれとそれとどれを当ててくださいって
10個ぐらい持ってこられても困るぞ
275:デフォルトの名無しさん
22/11/16 02:12:08.75 cpGIBcGj0.net
>>266
コミットをパッチと考えて
後で再利用することを考えてる人
vs
後で見返すことなんてない人
の違いだな
結局一人プロジェクトなんよ
rebaseを価値を理解してないのは
276:デフォルトの名無しさん
22/11/16 02:52:08.03 cpWhvvM10.net
作りながら、やっぱりこのパッチは不要だから外そうとか、このパッチとこのパッチを両方適用して試そうとか、別の人の作業を取り込んで影響を調べようとか、お手軽自由自在にできるのが rebase の真髄
あと昨日の作業でタイポしちゃったとかでも直すのには rebase を使うのが基本
branch と rebase 無しでやれって言われたら気が狂いそう。もう昔には戻れない
277:デフォルトの名無しさん
22/11/16 04:26:00.99 WlnXLGJV0.net
パッチ適用 ←ここでコミット
↓
やっぱやめた ←ここでコミット
↓
２つのパッチ適応 ←ここでコミット
↓
別の人の作業を取り込んでみよう ←ここでコミット
↓
タイポ発見修整 ←ここでコミット
何がいけないの？これでいいじゃん
278:デフォルトの名無しさん
22/11/16 04:42:56.11 cpGIBcGj0.net
>>271
そんな都合よく行くかよｗ
実際の開発したことないのか？
パッチ適用 ←ここでコミット
タイポ発見修整 ←ここでコミット
バグ発見修整 ←ここでコミット
やっぱやめた ←ここでコミット
タイポ発見修整 ←ここでコミット
２つのパッチ適応 ←ここでコミット
やっぱやめた ←ここでコミット
タイポ発見修整 ←ここでコミット
別の人の作業を取り込んでみよう ←ここでコミット
バグ発見修整 ←ここでコミット
3つのパッチ適応 ←ここでコミット
バグ発見修整 ←ここでコミット
タイポ発見修整 ←ここでコミット
タイポ発見修整 ←ここでコミット
こんな大量のゴミコミットの中から、必要な部分だけ取り出すとかできるかよ
普段から整頓しておけって、子供の頃に教わらなかったか？
279:デフォルトの名無しさん
22/11/16 07:24:52.25 4to+8mNM0.net
>>251
Gitのコンセプトはなかなかチャレンジングだぞ。
全世界で唯一の履歴、完全平行作業(各自が任意のファイルを自由に同時に編集)ってのは、上手く行けば確かに面白い。
思考に階層がまるでない君らには通じないと思うが、
ソフトウェアは本来、実装階層ではなくて、コンセプト階層で勝負すべきなんだよ。
280:デフォルトの名無しさん
22/11/16 07:27:07.12 4to+8mNM0.net
>>253
(俺が言うとろくな展開にならなそうだが)
rebaseは清書用だからな。コードを実際に書く人向けではない。
mergeだけでも問題なく行ける。というかrebase自体がほぼmergeだし。
ここはGitのコンセプトがずれてて、
> リベースかマージか
> URLﾘﾝｸ(www.git-scm.com)リベースかマージか
二者択一ではなく、共存が正しいのだが、機能的に欠けてるからおかしな事になってる。
共存させる為には経路情報が必要で、俺はそれが当然保存されてると思ってて探したのに無い！で始まったのが前スレ814-
この辺、Gitに欠けてる機能を補完するとしたら第二弾以降になる。まあ全く予定無しだが。
rebaseを常用するのは、少なくとも従来スタイル(>>127)だとマネジメントが機能してない証拠でしかなく不味い。
Gitが開発の手法を変えた！とか言われてるのはこの辺ぶち壊して、
従来型の(やってる感だけの)マネジメントなんて要りません！としたからだろうけど、
(まあ実際の所ろくにマネジメント出来てないし、
仮に問題が分かったとしても後からでは余計に邪魔でしかないので手当も出来ず、
なら最初から何もやりません！ってのも分からなくもないが)
Gitの場合はついでにアナログ的努力、具体的には176内
・regressionテスト
・レビュー
・コーディングルール
もイラネ！って全部捨ててるのはさずがに駄目だと思うが、これで回ってきてるのも事実だからな。
まあこれはさておき、多分rebaseの馬鹿らしさを実感出来る状況にあること自体がマトモであり、幸せなんだろうよ。
そしてそれは知らない人には通じない。これもよくある状況だよ。
ドタバタしか知らない連中は、ドタバタするものだと思っちゃってる、ってこと。朝の支度と同じ。
Gitは力業(ちからわざ：パワープレイ)が出来るだけに、全部力業に持ち込んでて、力業に頼らない方策を無視してる。
これも勝つ為の戦略だ！はありだけど、例えばサッカーで力業しか無かったら色々言われるでしょ。
281:デフォルトの名無しさん
22/11/16 07:27:38.13 4to+8mNM0.net
>>262
あ～ cherry pick ってそういう意味か。意味不明な機能だなとしか思ってなかったわ。
ただそれって多分、三角マージの指定方法を洗練すればmergeに統合出来た話で、
別機能にするのは仕様の練り方が全然足りない気がするが。(まあその気すらないようだが)
282:デフォルトの名無しさん
22/11/16 07:29:33.99 iIuOsXs40.net
> ただそれって多分、三角マージの指定方法を洗練すればmergeに統合出来た話で、
できねーよ
頭悪いのか
283:デフォルトの名無しさん
22/11/16 07:31:39.07 iIuOsXs40.net
>>276
> rebaseを常用するのは、少なくとも従来スタイル(>>127)だとマネジメントが機能してない証拠でしかなく不味い。
rebaseを管理の機能だと思ってるから
アホなんだよなぁｗ
284:デフォルトの名無しさん
22/11/16 07:33:21.02 iIuOsXs40.net
> rebaseは清書用だからな。コードを実際に書く人向けではない。
これも理解してないやつのセリフ
適切なタイミングでコミットするから
rebaseが必要なんだが
ああ、コミットをpushと勘違いしてそうだなこいつｗ