[過去ﾛｸﾞ] Git 19 (1002ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
98(1): (ﾜｯﾁｮｲ b57b-3eqv) 2022/11/12(土)06:42 ID:h41UD2lS0(1/29) AAS
>>88
バグにはすぐに引っかかるものと、そうでないものがあるんだよ。
お前らが理解出来るとは思ってないけど。
Gitはパッチ適用ツールであって、本当に、パッチ書く側のサポートが全くない。
Git作ってる連中も、コミッタ？は結局パッチ適用側に回ってしまって、自分でパッチ書かなくなるから気づけない。
ありがちな展開だけどさ。
そして使う側は（目的外使用ではあるが）書く側として使うからずれる。
省1
99: (ﾜｯﾁｮｲ b57b-3eqv) 2022/11/12(土)06:43 ID:h41UD2lS0(2/29) AAS
>>90
Gitが提供しているもの： 1000ページの取扱説明書を読まないとまともに使えない、超高性能電動ドリル
ユーザーが欲しかったもの： 引き金を引けば回るだけ、簡単で今すぐ使える、ホビー用電動ドリル
100: (ﾜｯﾁｮｲ b57b-3eqv) 2022/11/12(土)06:46 ID:h41UD2lS0(3/29) AAS
ちな、CodeOfConduct読んで、あいつら中の人か！ってのが分かったので俺的査定。
Avar Arnfjord Bjarmason: 今なんとか方向修正を試みてるように見える。上手く導ければ有能だが、果たして？
Christian Couder: 出てきてないので不明
Junio C Hamano: 休暇中？らしい (40)
Taylor Blau: 無能。ってか閻魔大王が全スルーするならいないのと同じ。ちゃんと門番やれ。
そういえばGitのコーディングルールはどこにあるのだ？
今回ほどの糞コードは、コーディングルールで引っかけて落とせるはずだが。
101(5): (ﾜｯﾁｮｲ b57b-3eqv) 2022/11/12(土)06:52 ID:h41UD2lS0(4/29) AAS
>>89,94,95
全部読んだ。なかなか面白かった。(89はコメントも全部読んだ)
君が冷やかしかマジかは分からないが、マジで要るんなら作ってみてもいい。
ただし今すぐ取りかかれるわけでもないし、全般的に考えて本年度末(3月末)位が現実的な目標になる。
今考えている構成をざっくり言うと以下
・Gitをゴミ箱/バケツ化するラッパ(フロントエンドのみ。バックエンドはGitで、Gitは別インストール必須)
・electronで作ってwindowsストアに配置(広告付き無料アプリ)
省7
102(3): (ﾜｯﾁｮｲ b57b-3eqv) 2022/11/12(土)06:54 ID:h41UD2lS0(5/29) AAS
実装するだけなら2週間程度で十分だが、
・electron使ったこと無いので調査に2週間ほどかかる
・アプリストアも広告付きのアプリも作ったことないので、これも2週間ほど調査必要
・仕様を練らないとろくな事にならない、
Linusが2週間と言ってるのは実装であって、それ以前にずっといろいろVCS使ってきてるから仕様が熟成済みだっただけ。
・そもそも顧客がいるかどうか
・一応は他WindowsGitアプリを全部確認する必要がある。今tortoiseGit試しにインストールしてみたところ。
省11
103(5): (ﾜｯﾁｮｲ b57b-3eqv) 2022/11/12(土)06:57 ID:h41UD2lS0(6/29) AAS
>>97
(わざわざ色々考えてくれたのなら手間かけてすまんが)
正直全く分からんし、俺はstashも糞仕様と思うから使う気ない。
というか、Gitの連中、「仕様は小さくあるべき」という感覚がそもそも無いと思う。
俺だったら、branchなんて、各ディレクトリにそのままマッピングする。
つまり、sample.txtの開発なら、
.git
省18
109: (ﾜｯﾁｮｲ b57b-3eqv) 2022/11/12(土)10:59 ID:h41UD2lS0(7/29) AAS
>>104
> デスクトップに置いて管理されている事になっているファイルをコントロールできるようにして欲しい。
それはやる。というか、今考えている動作モードは2つで、
A. ある階層以下全部の履歴を記録
B. 明示的に指定したファイルまたはディレクトリの履歴を記録
で、Aがgit的、Bがゴミ箱的な使い方になる。
ライトユーザーにはBの方が直感的だろう。
省21
110: (ﾜｯﾁｮｲ b57b-3eqv) 2022/11/12(土)11:00 ID:h41UD2lS0(8/29) AAS
てな話を仕様として詰める必要があって、つまり、
1. どういう機能が欲しいか
2. それはこの仕様(実装)でいけるか
みたいなこと。
ちょこちょこやるのはさておき、本格的にやるならスレ分けるべきだな、という話。
111(1): (ﾜｯﾁｮｲ b57b-3eqv) 2022/11/12(土)11:11 ID:h41UD2lS0(9/29) AAS
>>105
commit/rebase履歴の全保持と、commitのフィルタ機能だね。
記録側からみればゴミなcommitも、プログラマからみれば重要なんだよ。だからそれを見えなくする機能だね。
CSSでいうdisplay:noneの機能。
今は、「綺麗に清書して＝プログラマには必要だったコミットも全部消して」提出しろ、になってるだろ。
これが無駄だし、プログラマ的には不快だ。
それは悪戦苦闘の記録であって、デグレードした場合に参照したい時もあるんだよ。消してるのは不味い。
省1
112: (ﾜｯﾁｮｲ b57b-3eqv) 2022/11/12(土)11:11 ID:h41UD2lS0(10/29) AAS
>>106
世界規模で勝手に開発してるLinuxならそうだろう。
しかし、ローカルファイルシステム、或いは共有ファイルシステムに於いては、当たり前だが「同じディレクトリ名」＝「同一」なんだよ。
だからディレクトリ名が被って困る、なんて事はない。
そして、バックアップ的には、branchはパスが伸びた程度の意味しかないから、これで問題ない。
(git流のbranchの使い方をしてても、これで問題ない。
通常のファイルシステムでは、パス+ファイル名が同じなら同一と見なすが、
省4
114(1): (ﾜｯﾁｮｲ b57b-3eqv) 2022/11/12(土)11:13 ID:h41UD2lS0(11/29) AAS
>>108
知ってるぞ。
ただ、切り替わらなくてもいい共通ファイル類はその場合には .git 階層に置くんだよ。
というかね、gitが何故か「カレント主義」になってて、とにかく「カレントディレクトリ」なんだよな。
これは本当によく分からない。
俺がGitGUIで最初にやったのは、「Open repository ...」を探すこと、だからな。
無いから、「え？まさか？カレントで起動しないと駄目なのか？」でわざわざショートカット作り直して起動し直した。
省1
118(2): (ﾜｯﾁｮｲ b57b-3eqv) 2022/11/12(土)11:45 ID:h41UD2lS0(12/29) AAS
>>115
車輪の再開発はしないんだよ。
どこまで使えるか判断して、その範囲は使うし、それを超えた範囲は使わない。
(今の実態だと、git add 絶対パス、はほぼ確実にバグを踏むから使わない)
自分で作ればバグがない物が簡単に出来るわけでもないし。
> mergeのことは考えてないんだな
GUIでmerge、例えばドラッグアンドドロップでmergeは怖いだろ。
省8
121(1): (ﾜｯﾁｮｲ b57b-3eqv) 2022/11/12(土)12:01 ID:h41UD2lS0(13/29) AAS
>>117
ああその失敗情報は有り難い。
ただ、そこは理論的に問題ない。
技術的には、Gitでもカレントを「上書き」するのだからコピーと同じだけのI/Oが必要であり、
I/Oバウンドの場合、GitでもSubversionでもその部分の処理時間は同じになる。
(Gitのbranch切換とSubversionのブランチ作成が同じI/O負荷）
そこで速度差が出るのだから、実際は、86で既に言ったとおり、Subversionが各ソースを「展開」するのが遅くて、
省9
122(1): (ﾜｯﾁｮｲ b57b-3eqv) 2022/11/12(土)12:09 ID:h41UD2lS0(14/29) AAS
>>119
> rebase する前に新しいブランチ切ってやれば
そこはbranchではなくてタグだとは思うが、要はそれ、gcされないようにポインタ残してるだけだろ。
しかし開発しなくなったbranchは刈り取れ、というのが一般の使い方だろ。（それが推奨されてるように見える）
そもそもgcされないようにxxする、というのが間違ってるんだよ。
そんなところまでユーザーが密結合すべきではない。
普通にオススメ通りやったら、探せば何処かに履歴はあるよ、程度じゃないと。
省2
127(4): (ﾜｯﾁｮｲ b57b-3eqv) 2022/11/12(土)12:54 ID:h41UD2lS0(15/29) AAS
>>120
多分な、開発現場において「ファイル内の」mergeが日常ってのはあまりないと思うぞ。
それは各自が勝手にどのファイルをどういじってもいい、ということだから。
gitによって開発フローが変わった！ってのがこの辺かもしれんが、
普通は担当を振り分けて、結果的に
「この期間にこのファイルを触るのは○○だけ」
と交通整理される。
省7
128: (ﾜｯﾁｮｲ b57b-3eqv) 2022/11/12(土)12:57 ID:h41UD2lS0(16/29) AAS
>>126
了解。考え直すよ。一度位ググるべきだったわ。
131(2): (ﾜｯﾁｮｲ b57b-3eqv) 2022/11/12(土)13:18 ID:h41UD2lS0(17/29) AAS
>>130
つまりお前らGit屋の要求仕様は、
ファイル内のmerge：要らん
ディレクトリ内のmerge(=新しい方を取るだけ）：要る
ってのか？これなら手動でやった方が楽だよ。
普通にゴミ箱＝エクスプローラ的GUIになんだから、日付でソートして纏めて選択して持ってくだけ。
いちいち「オレオレアプリ的merge」とか用意するから余計混乱する。
省1
135(2): (ﾜｯﾁｮｲ b57b-3eqv) 2022/11/12(土)13:47 ID:h41UD2lS0(18/29) AAS
>>132-133
最初に言っておくべきだったが、俺が作るアプリはお前らGit屋向けではないよ。
プログラマ、或いはクリエイター向けで、
Gitなんか勉強したくない、何でもいいからバックアップと履歴が取れてればいい、という人向けだ。
だから内部DBには都合がいい物を使うだけで、SQLiteもあり得るし、途中での変更もあり得る。
Git屋はGitを使うべきだよ。そもそもGitがGit屋向けフルチューンだし、
だからこそ文句言われてるわけだが、目的外使用なのだからLinusから見れば完全に筋違いだ。
省1
137(2): (ﾜｯﾁｮｲ b57b-3eqv) 2022/11/12(土)13:51 ID:h41UD2lS0(19/29) AAS
>>134
それなら、お前にはフィットしないだろうし、お前の周りはGitを引き続き使えばいいだけ。
俺は127方式やもっと小規模(個人)レベルでの開発を想定したツールを提供するだけ。
目論見が外れてたら、思ったより売れなくて、俺の骨折り損なだけ。
これで何の問題もないだろ。
139: (ﾜｯﾁｮｲ b57b-3eqv) 2022/11/12(土)14:55 ID:h41UD2lS0(20/29) AAS
>>119,124
--keep-base見たが、これ仕様が欠けてるんだよ。
だから君みたいな「あらかじめポインタ(branchまたはtag)を確保しておく」使い方しか出来ない。
rebaseが成功したらbranchは新しい方を指すので、古い方は名無しになってしまう。（放置したらgc対象)
だから本来の仕様は、 --keep-base "AsThisBranch" とかで、新しいbranch名かタグ名を指定出来ないとおかしい。
これ --keep-base だけしても名無しのままだから即削除されないだけで、じきにgcされるから、意味ないと思うぞ。
こういうところがGitは仕様が雑なんだよ。仕様の重要さをまるで理解してない。これただの落とし穴だよ。
省6
140(1): (ﾜｯﾁｮｲ b57b-3eqv) 2022/11/12(土)14:56 ID:h41UD2lS0(21/29) AAS
>>138
プログラマ： 主にソースコードを書いてる連中
クリエイター： 例えば主にフォトショで絵を描いてる連中
Git屋： Gitを操作することが主な仕事(>>83内のGit用員)、ソースコードは書けないし、絵も描けない
142(2): (ﾜｯﾁｮｲ b57b-3eqv) 2022/11/12(土)15:24 ID:h41UD2lS0(22/29) AAS
>>141
× Gitの良いところ
○ Gitと被るところ
バックアップツールで必須な
・更新されたファイルを保存しておく
・変更されてないファイルは改めては取得しない
・変更履歴も保持し、必要なら古いファイルも取り出せる
省8
146(2): (ﾜｯﾁｮｲ b57b-3eqv) 2022/11/12(土)17:57 ID:h41UD2lS0(23/29) AAS
>>143
いや5%(=24分)も十分多すぎだけどな。
まあそれはさておき、コードと開発体制も糞だったのを忘れてたから、
Gitの良い所： 基本アーキ、バックエンド、ドキュメント
Gitの糞な所： フロントエンド、仕様、コード、開発体制、(ドキュメント多すぎ)
となる。ここで、駄目なところは全部マネジメントに起因してる。
一般の会社なら課長/係長クラスで締める部分が締まってない。
省13
150(1): (ﾜｯﾁｮｲ b57b-3eqv) 2022/11/12(土)18:42 ID:h41UD2lS0(24/29) AAS
>>147
料理人： 冷蔵庫なんてブッ込んでおけば冷える、で十分
Git： 正しいブッ込み方じゃないから直せ、いやそもそもブッ込み方を知らない奴が使うな！と文句を言う冷蔵庫
151(1): (ﾜｯﾁｮｲ b57b-3eqv) 2022/11/12(土)18:55 ID:h41UD2lS0(25/29) AAS
>>149
> 公開リポジトリにプッシュしたコミットをリベースしてはいけない
> 外部ﾘﾝｸ:www.git-scm.com
これは既知の問題だけど、これが既知とされるまでにだいぶ大騒ぎしてるはずだよ。
プルリクして、公開リポジトリの操作自体は分かってる奴がやる、
(その時点でおかしい構造ならまずローカルを修正させる）
というのがセオリーなんだろうけど、それをやるのがGit係＝「Git屋」だよ。
省3
155(1): (ﾜｯﾁｮｲ b57b-3eqv) 2022/11/12(土)20:11 ID:h41UD2lS0(26/29) AAS
>>154
> gitのためにディレクト構造を作らないといけなくなる
ここら辺がGit信者が勘違いしまくってる点だよ。
これは
× Gitの為に
○ branchの為に
であって、ツールを『何も使わずに』branchを用意する場合の構造と同じなんだ。
省14
160(2): (ﾜｯﾁｮｲ b57b-3eqv) 2022/11/12(土)20:40 ID:h41UD2lS0(27/29) AAS
まあとにかくだ、基本思想が違ってて、俺は「簡単は正義」だから、
Git： 使いこなせない馬鹿が悪い
俺： 難しい物を作る馬鹿が悪い
で、平行線なんだよ。
ただお前らからは普及機は出てこないのは分かったから、俺が作るよ。
（もっと調査してからだが）
俺は、難しくなる妥当な理由があるのなら仕方ないが、そうでなければ簡単にしろ、で
省5
162(1): (ﾜｯﾁｮｲ b57b-3eqv) 2022/11/12(土)21:26 ID:h41UD2lS0(28/29) AAS
>>161
いや101の仕様で手こずると思ってるお前もかなりヤバいけどな。
これも周りにプログラマが居たら聞いてみ。
ただ、自分で使う用に動けばいい物と、他人が(デタラメに)使う用に作るのはだいぶ違うんだ。
だからきちんと状況確認して仕様はしっかり詰めるべきなんだよ。
Gitにはこの辺の感覚がない。
まあLinusが個人的に必要だから作った、完全特定個人向けチューニングだからではあるが。
省1
166(3): (ﾜｯﾁｮｲ b57b-3eqv) 2022/11/12(土)22:19 ID:h41UD2lS0(29/29) AAS
>>163
いや結局>>137なんだよ。
お互いの見解は異なるし、同意する必要もない。ただフォークすればいい。
俺は売れそうだと思ったら作るだけ、欲しい奴は乗っかればいいだけ、要らない奴は使わなければいいだけ。
俺は(というよりプログラマ全般は）ツールだけ使えてコード書けない奴は死ねばいいとしか思ってないから、方向性もいい。
俺の目論見が外れればお前らの勝ち、お前らが食うのに困れば俺の勝ち、勝敗はフォークで、だ。
俺が想定してるのが時代遅れで馬鹿だらけの現場なのか、お前らが壮大に勘違いしてたのかも、それで分かるよ。
省5
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.039s