[過去ログ]
Git 19 (1002レス)
Git 19 http://mevius.5ch.net/test/read.cgi/tech/1667720427/
上
下
前
次
1-
新
通常表示
512バイト分割
レス栞
抽出解除
必死チェッカー(本家)
(べ)
自ID
レス栞
あぼーん
このスレッドは過去ログ倉庫に格納されています。
次スレ検索
歴削→次スレ
栞削→次スレ
過去ログメニュー
98: デフォルトの名無しさん (ワッチョイ b57b-3eqv) [sage] 2022/11/12(土) 06:42:22.57 ID:h41UD2lS0 >>88 バグにはすぐに引っかかるものと、そうでないものがあるんだよ。 お前らが理解出来るとは思ってないけど。 Gitはパッチ適用ツールであって、本当に、パッチ書く側のサポートが全くない。 Git作ってる連中も、コミッタ?は結局パッチ適用側に回ってしまって、自分でパッチ書かなくなるから気づけない。 ありがちな展開だけどさ。 そして使う側は(目的外使用ではあるが)書く側として使うからずれる。 だから、求められてるのは「書く側」向けの「全自動完全履歴保持バケツ」。 http://mevius.5ch.net/test/read.cgi/tech/1667720427/98
99: デフォルトの名無しさん (ワッチョイ b57b-3eqv) [sage] 2022/11/12(土) 06:43:34.00 ID:h41UD2lS0 >>90 Gitが提供しているもの: 1000ページの取扱説明書を読まないとまともに使えない、超高性能電動ドリル ユーザーが欲しかったもの: 引き金を引けば回るだけ、簡単で今すぐ使える、ホビー用電動ドリル http://mevius.5ch.net/test/read.cgi/tech/1667720427/99
100: デフォルトの名無しさん (ワッチョイ b57b-3eqv) [sage] 2022/11/12(土) 06:46:43.39 ID:h41UD2lS0 ちな、CodeOfConduct読んで、あいつら中の人か!ってのが分かったので俺的査定。 Avar Arnfjord Bjarmason: 今なんとか方向修正を試みてるように見える。上手く導ければ有能だが、果たして? Christian Couder: 出てきてないので不明 Junio C Hamano: 休暇中?らしい (40) Taylor Blau: 無能。ってか閻魔大王が全スルーするならいないのと同じ。ちゃんと門番やれ。 そういえばGitのコーディングルールはどこにあるのだ? 今回ほどの糞コードは、コーディングルールで引っかけて落とせるはずだが。 http://mevius.5ch.net/test/read.cgi/tech/1667720427/100
101: デフォルトの名無しさん (ワッチョイ b57b-3eqv) [sage] 2022/11/12(土) 06:52:44.85 ID:h41UD2lS0 >>89,94,95 全部読んだ。なかなか面白かった。(89はコメントも全部読んだ) 君が冷やかしかマジかは分からないが、マジで要るんなら作ってみてもいい。 ただし今すぐ取りかかれるわけでもないし、全般的に考えて本年度末(3月末)位が現実的な目標になる。 今考えている構成をざっくり言うと以下 ・Gitをゴミ箱/バケツ化するラッパ(フロントエンドのみ。バックエンドはGitで、Gitは別インストール必須) ・electronで作ってwindowsストアに配置(広告付き無料アプリ) 十分売れてる限り保守してやんよ(その必要すらないほど単純なアプリだが) ・プロプライエタリで伽藍開発。バザールなんてとても無理。コードは俺が書くから、お前らは使い勝手をフィードバックしろ。 ・GitBucket(仮称)、Gitと付けたら不味いのなら考え直す ・コンセプトは、「何も知らなくても使える『全自動完全履歴保持バケツ』」 よって仕様は限りなく簡素化し、それ以上やりたければDBはgitだからgitアプリ使え、とする ・diffは取れるがmergeは直感的GUIがないので無理。が、主にバイナリを保存する連中には全く関係ないし。 ・branchはディレクトリに割り当てて手動で。というより、git内にcommit履歴が保持されてないのでbranchの識別が出来ない。 http://mevius.5ch.net/test/read.cgi/tech/1667720427/101
102: デフォルトの名無しさん (ワッチョイ b57b-3eqv) [sage] 2022/11/12(土) 06:54:37.10 ID:h41UD2lS0 実装するだけなら2週間程度で十分だが、 ・electron使ったこと無いので調査に2週間ほどかかる ・アプリストアも広告付きのアプリも作ったことないので、これも2週間ほど調査必要 ・仕様を練らないとろくな事にならない、 Linusが2週間と言ってるのは実装であって、それ以前にずっといろいろVCS使ってきてるから仕様が熟成済みだっただけ。 ・そもそも顧客がいるかどうか ・一応は他WindowsGitアプリを全部確認する必要がある。今tortoiseGit試しにインストールしてみたところ。 があるので、冷やかしでないのなら新しくスレ立てて様子見する。 スレタイには GitBucket(仮称)と、何か「Gitはもう諦めた系」「頑張らない系」の連中を集められる文言を入れたいが、何がいいか。 板はここかソフトウェア板だと思うが、他に候補があるか。 ただ対象ユーザーはここに来る連中ではなくガチのど素人なので、もっと全然違うところの方がいいかも? スレタイ案: A. もうGitBucket(仮称)でええやん。 B. GitBucket(仮称)使ってるからって、Gitが分からなかった訳じゃないんだからねっ!!! C. GitBucket(仮称)計画中、Gitに疲れた奴集まれ D. 日常のバックアップツールGitBucket(仮称) 冷やかしじゃない奴からの投票を受け付ける。 http://mevius.5ch.net/test/read.cgi/tech/1667720427/102
103: デフォルトの名無しさん (ワッチョイ b57b-3eqv) [sage] 2022/11/12(土) 06:57:39.26 ID:h41UD2lS0 >>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を使う人も使わない人も問題ない) http://mevius.5ch.net/test/read.cgi/tech/1667720427/103
109: デフォルトの名無しさん (ワッチョイ b57b-3eqv) [sage] 2022/11/12(土) 10:59:50.02 ID:h41UD2lS0 >>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は出す) http://mevius.5ch.net/test/read.cgi/tech/1667720427/109
110: デフォルトの名無しさん (ワッチョイ b57b-3eqv) [sage] 2022/11/12(土) 11:00:10.29 ID:h41UD2lS0 てな話を仕様として詰める必要があって、つまり、 1. どういう機能が欲しいか 2. それはこの仕様(実装)でいけるか みたいなこと。 ちょこちょこやるのはさておき、本格的にやるならスレ分けるべきだな、という話。 http://mevius.5ch.net/test/read.cgi/tech/1667720427/110
111: デフォルトの名無しさん (ワッチョイ b57b-3eqv) [sage] 2022/11/12(土) 11:11:14.80 ID:h41UD2lS0 >>105 commit/rebase履歴の全保持と、commitのフィルタ機能だね。 記録側からみればゴミなcommitも、プログラマからみれば重要なんだよ。だからそれを見えなくする機能だね。 CSSでいうdisplay:noneの機能。 今は、「綺麗に清書して=プログラマには必要だったコミットも全部消して」提出しろ、になってるだろ。 これが無駄だし、プログラマ的には不快だ。 それは悪戦苦闘の記録であって、デグレードした場合に参照したい時もあるんだよ。消してるのは不味い。 ローカルだけにしろ、はその通りだが、今はローカルだけにも出来ない仕様だろ。(無駄にブロックチェーンしてるので) http://mevius.5ch.net/test/read.cgi/tech/1667720427/111
112: デフォルトの名無しさん (ワッチョイ b57b-3eqv) [sage] 2022/11/12(土) 11:11:41.80 ID:h41UD2lS0 >>106 世界規模で勝手に開発してるLinuxならそうだろう。 しかし、ローカルファイルシステム、或いは共有ファイルシステムに於いては、当たり前だが「同じディレクトリ名」=「同一」なんだよ。 だからディレクトリ名が被って困る、なんて事はない。 そして、バックアップ的には、branchはパスが伸びた程度の意味しかないから、これで問題ない。 (git流のbranchの使い方をしてても、これで問題ない。 通常のファイルシステムでは、パス+ファイル名が同じなら同一と見なすが、 ここがgitではパス+ファイル名+ブランチ名になってるだけ。 branch自体の参照先も変えられる!と思うかもしれんが、それはユーザーがそうしたのであって、 確か○月○日頃の○○ブランチ内にそのファイルがあるはず、と思い出すのはユーザー責任だ。 いずれにしても何処かに記録はされてるから、あとは頑張って探せという仕様) http://mevius.5ch.net/test/read.cgi/tech/1667720427/112
114: デフォルトの名無しさん (ワッチョイ b57b-3eqv) [sage] 2022/11/12(土) 11:13:17.79 ID:h41UD2lS0 >>108 知ってるぞ。 ただ、切り替わらなくてもいい共通ファイル類はその場合には .git 階層に置くんだよ。 というかね、gitが何故か「カレント主義」になってて、とにかく「カレントディレクトリ」なんだよな。 これは本当によく分からない。 俺がGitGUIで最初にやったのは、「Open repository ...」を探すこと、だからな。 無いから、「え?まさか?カレントで起動しないと駄目なのか?」でわざわざショートカット作り直して起動し直した。 普通そんなアプリ無い。この辺は、「いつも通りのアプリ」じゃないと駄目なんだよ。 http://mevius.5ch.net/test/read.cgi/tech/1667720427/114
118: デフォルトの名無しさん (ワッチョイ b57b-3eqv) [sage] 2022/11/12(土) 11:45:13.42 ID:h41UD2lS0 >>115 車輪の再開発はしないんだよ。 どこまで使えるか判断して、その範囲は使うし、それを超えた範囲は使わない。 (今の実態だと、git add 絶対パス、はほぼ確実にバグを踏むから使わない) 自分で作ればバグがない物が簡単に出来るわけでもないし。 > mergeのことは考えてないんだな GUIでmerge、例えばドラッグアンドドロップでmergeは怖いだろ。 コピーするつもりがmergeされたら悲惨なことになる。 (コピーや移動と同じGUIにmergeをアサインしてはいけない) だからmerge自体はgitアプリで明示的にやれ、という仕様。その方が安心だ。 そもそもバイナリはmerge出来ないし、 GitBucket使うような連中にはmergeなんてほぼ要らん。 てゆうかね、そもそもmergeが主な仕事ならgit使うべき。あれは完全にmerge特化型だから。 GitBucketのユーザーは、そのmergeのネタを作る側、つまりプログラマとかクリエーターとかだ。 管理側じゃなくて、管理される側。 http://mevius.5ch.net/test/read.cgi/tech/1667720427/118
121: デフォルトの名無しさん (ワッチョイ b57b-3eqv) [sage] 2022/11/12(土) 12:01:03.49 ID:h41UD2lS0 >>117 ああその失敗情報は有り難い。 ただ、そこは理論的に問題ない。 技術的には、Gitでもカレントを「上書き」するのだからコピーと同じだけのI/Oが必要であり、 I/Oバウンドの場合、GitでもSubversionでもその部分の処理時間は同じになる。 (Gitのbranch切換とSubversionのブランチ作成が同じI/O負荷) そこで速度差が出るのだから、実際は、86で既に言ったとおり、Subversionが各ソースを「展開」するのが遅くて、 それはおそらく順方向履歴しか持ってないからだ。 (逆方向履歴持ってれば、commitは早くならないかもしれないが、branch切り出しはコピーと同速に出来る) ここら辺はSubversionの基本アーキが腐ってるからだが、 この点GitBucketは中身Gitだから、コピーするだけで、結果的には本家Git(上書きするだけ)と同速だよ。 そのコピーが重い? だったらbranch切換セレクタだけは付けるから、それで勝手に自前で管理しろ。 バックアップツールとしては、branchはパスが伸びただけの意味しかないからそうする、というのは112の通り。 コピーオンライトのファイルシステム、つまりハードリンクにする手もあるけど、これはユーザーが付いて来れないだろ。 ならコピー時間待たせた方がいい。 http://mevius.5ch.net/test/read.cgi/tech/1667720427/121
122: デフォルトの名無しさん (ワッチョイ b57b-3eqv) [sage] 2022/11/12(土) 12:09:47.00 ID:h41UD2lS0 >>119 > rebase する前に新しいブランチ切ってやれば そこはbranchではなくてタグだとは思うが、要はそれ、gcされないようにポインタ残してるだけだろ。 しかし開発しなくなったbranchは刈り取れ、というのが一般の使い方だろ。(それが推奨されてるように見える) そもそもgcされないようにxxする、というのが間違ってるんだよ。 そんなところまでユーザーが密結合すべきではない。 普通にオススメ通りやったら、探せば何処かに履歴はあるよ、程度じゃないと。 まあ--keep-baseについては見てみるよ。 Bookの方が断然良かったのでman の方読むの止めてたから、知らなかった。 http://mevius.5ch.net/test/read.cgi/tech/1667720427/122
127: デフォルトの名無しさん (ワッチョイ b57b-3eqv) [sage] 2022/11/12(土) 12:54:11.71 ID:h41UD2lS0 >>120 多分な、開発現場において「ファイル内の」mergeが日常ってのはあまりないと思うぞ。 それは各自が勝手にどのファイルをどういじってもいい、ということだから。 gitによって開発フローが変わった!ってのがこの辺かもしれんが、 普通は担当を振り分けて、結果的に 「この期間にこのファイルを触るのは○○だけ」 と交通整理される。 同時に変更する必要があれば、同じ奴に同時にやらせるだけ。(注文が増えるだけ) そして各自が変更したファイルをかき集めて、くっつけて終わりだ。 お前らはこれもmergeと言ってる気がするが、 これは「更新日時が新しければ上書きする」だけの話で、手動でも楽勝だし、 プログラマはこれをmergeとは言わない。 プログラマが言う「ファイル内」のmergeが日常的に発生するかどうかはその部署のオペレーションによる。 (が、会社とか統制取れる場所でこれをする意味はないから、OSS以外ではほぼないと思うが) http://mevius.5ch.net/test/read.cgi/tech/1667720427/127
128: デフォルトの名無しさん (ワッチョイ b57b-3eqv) [sage] 2022/11/12(土) 12:57:01.77 ID:h41UD2lS0 >>126 了解。考え直すよ。一度位ググるべきだったわ。 http://mevius.5ch.net/test/read.cgi/tech/1667720427/128
131: デフォルトの名無しさん (ワッチョイ b57b-3eqv) [sage] 2022/11/12(土) 13:18:34.58 ID:h41UD2lS0 >>130 つまりお前らGit屋の要求仕様は、 ファイル内のmerge:要らん ディレクトリ内のmerge(=新しい方を取るだけ):要る ってのか?これなら手動でやった方が楽だよ。 普通にゴミ箱=エクスプローラ的GUIになんだから、日付でソートして纏めて選択して持ってくだけ。 いちいち「オレオレアプリ的merge」とか用意するから余計混乱する。 使い慣れたエクスプローラで苦も無く出来るのだから、それで十分なんだよ。 http://mevius.5ch.net/test/read.cgi/tech/1667720427/131
135: デフォルトの名無しさん (ワッチョイ b57b-3eqv) [sage] 2022/11/12(土) 13:47:01.20 ID:h41UD2lS0 >>132-133 最初に言っておくべきだったが、俺が作るアプリはお前らGit屋向けではないよ。 プログラマ、或いはクリエイター向けで、 Gitなんか勉強したくない、何でもいいからバックアップと履歴が取れてればいい、という人向けだ。 だから内部DBには都合がいい物を使うだけで、SQLiteもあり得るし、途中での変更もあり得る。 Git屋はGitを使うべきだよ。そもそもGitがGit屋向けフルチューンだし、 だからこそ文句言われてるわけだが、目的外使用なのだからLinusから見れば完全に筋違いだ。 なら、俺が「プログラマ/クリエイター向け」のツールを提供しよう、というだけ。 http://mevius.5ch.net/test/read.cgi/tech/1667720427/135
137: デフォルトの名無しさん (ワッチョイ b57b-3eqv) [sage] 2022/11/12(土) 13:51:09.55 ID:h41UD2lS0 >>134 それなら、お前にはフィットしないだろうし、お前の周りはGitを引き続き使えばいいだけ。 俺は127方式やもっと小規模(個人)レベルでの開発を想定したツールを提供するだけ。 目論見が外れてたら、思ったより売れなくて、俺の骨折り損なだけ。 これで何の問題もないだろ。 http://mevius.5ch.net/test/read.cgi/tech/1667720427/137
139: デフォルトの名無しさん (ワッチョイ b57b-3eqv) [sage] 2022/11/12(土) 14:55:15.80 ID:h41UD2lS0 >>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でいい) http://mevius.5ch.net/test/read.cgi/tech/1667720427/139
140: デフォルトの名無しさん (ワッチョイ b57b-3eqv) [sage] 2022/11/12(土) 14:56:22.97 ID:h41UD2lS0 >>138 プログラマ: 主にソースコードを書いてる連中 クリエイター: 例えば主にフォトショで絵を描いてる連中 Git屋: Gitを操作することが主な仕事(>>83内のGit用員)、ソースコードは書けないし、絵も描けない http://mevius.5ch.net/test/read.cgi/tech/1667720427/140
142: デフォルトの名無しさん (ワッチョイ b57b-3eqv) [sage] 2022/11/12(土) 15:24:26.31 ID:h41UD2lS0 >>141 × Gitの良いところ ○ Gitと被るところ バックアップツールで必須な ・更新されたファイルを保存しておく ・変更されてないファイルは改めては取得しない ・変更履歴も保持し、必要なら古いファイルも取り出せる ・可能なら定期的に圧縮する をGitが持ってるから、目的外使用されてるだけだな。 まあ基本アーキがいいから目的外使用でも本来ツールと戦えるということではあるけど。 ただ変更を酷く許してないところは頂けない。ここは俺はぶち壊す予定。 (間違ったファイルをコミットして大騒ぎ、結局全部作り直し、みたいのを無くして、ファイルを普通に消せるようにする。 ハッシュがずれたところで、ツリーには関係ない) Gitのバックエンドは出来がいいんだと思うよ。多分。(俺が問題に遭遇してないだけかもだが) Gitが糞なのは、フロントエンドと、仕様だね。ドキュメントは多すぎるが、よく書かれているし、少ないよりは断然いい。 http://mevius.5ch.net/test/read.cgi/tech/1667720427/142
146: デフォルトの名無しさん (ワッチョイ b57b-3eqv) [sage] 2022/11/12(土) 17:57:20.46 ID:h41UD2lS0 >>143 いや5%(=24分)も十分多すぎだけどな。 まあそれはさておき、コードと開発体制も糞だったのを忘れてたから、 Gitの良い所: 基本アーキ、バックエンド、ドキュメント Gitの糞な所: フロントエンド、仕様、コード、開発体制、(ドキュメント多すぎ) となる。ここで、駄目なところは全部マネジメントに起因してる。 一般の会社なら課長/係長クラスで締める部分が締まってない。 これは指揮系統を持たない「バザール」の宿命で、他知らんけどこんなもんなのかもしれないが、 OSSという意味ではchromeとかもっとガッツリやってる(ように見える)し、少なくともregressionテストは流しまくってる。 あっちはGoogleが締めてるのかもしれないが、Gitは見た目1本もregressionテスト流してないのは駄目だろ。 Subversion(58内記事)ではregressionテストに落ちたらcommit禁止だったらしいし。これが普通。 CVSはこの辺ガッツリやりすぎて、テスト用の3万行超のシェルスクリプトに (自分がcommitする部分の為の)新規テストを追加しなければcommitしちゃ駄目、とかで問題だったとも書いてあったが。 >>144 料理の味で勝負をしたいのに、冷蔵庫の使い方を100時間かけて勉強して、 冷蔵庫のご機嫌を取らないといけない事に、みんな文句言ってるんだよ。 ただこれはテクノロジーが達してないだけではある。 昔は航空機関士が同乗してたように。(乗ってて何とかなったとはとても思えないが、それはそれ) 今はGit屋が必要なレベルで、じきにもっと簡単な物が出てきてお役ご免になるはず。 出てこないようなら俺が作るよ、ということ。 http://mevius.5ch.net/test/read.cgi/tech/1667720427/146
150: デフォルトの名無しさん (ワッチョイ b57b-3eqv) [sage] 2022/11/12(土) 18:42:32.33 ID:h41UD2lS0 >>147 料理人: 冷蔵庫なんてブッ込んでおけば冷える、で十分 Git: 正しいブッ込み方じゃないから直せ、いやそもそもブッ込み方を知らない奴が使うな!と文句を言う冷蔵庫 http://mevius.5ch.net/test/read.cgi/tech/1667720427/150
151: デフォルトの名無しさん (ワッチョイ b57b-3eqv) [sage] 2022/11/12(土) 18:55:39.59 ID: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単位での同期で十分だったはず。 http://mevius.5ch.net/test/read.cgi/tech/1667720427/151
メモ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
スレ情報
赤レス抽出
画像レス抽出
歴の未読スレ
AAサムネイル
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.042s