[過去ログ]
Git 18 (1002レス)
Git 18 http://mevius.5ch.net/test/read.cgi/tech/1650651945/
上
下
前
次
1-
新
通常表示
512バイト分割
レス栞
このスレッドは過去ログ倉庫に格納されています。
次スレ検索
歴削→次スレ
栞削→次スレ
過去ログメニュー
762: デフォルトの名無しさん (オッペケ Src5-8VyY) [sage] 2022/11/02(水) 22:26:03.48 ID:KtYxSAYnr 何でもかんでもシェルでやろうとするやつは病気 名前を呼んではいけないあの開発手法とか推してそう http://mevius.5ch.net/test/read.cgi/tech/1650651945/762
763: デフォルトの名無しさん (ワッチョイ 497b-vCJ4) [sage] 2022/11/03(木) 05:47:24.09 ID:AHw2USmo0 >>755 それはどのプラットフォームで問題になったの? 賢い選択とは思えないけどね。 具体的なデメリットは既に666で挙げたとおり。 俺はシェルの互換性問題なんて有ったとは思えないけど、 (昔からsh《bsh》は互換性は高かったし、今はその後継のbashで統一されてる。 ああ確かにcsh/tcsh/ksh/zshはゴミだったし死滅したよ) それが問題なら、GitのC化ではなく、直接シェルの互換性を上げるのが常策だよ。 互換性がC化で達成出来るのなら、 既にあるbash(多分C)ソースをコンパイルしただけのものを同梱し、 gsh(=gitsh)だ!これを使え!と強弁すれば済んだろ。 なんかやっぱり無能の働き者を地で行ってる気はする。 仕事を減らす努力をしてないよね。 http://mevius.5ch.net/test/read.cgi/tech/1650651945/763
764: デフォルトの名無しさん (ワッチョイ 497b-vCJ4) [sage] 2022/11/03(木) 05:49:10.00 ID:AHw2USmo0 >>758 その通りだ。だからアマチュアの樋口Pも正しく対応出来てた。 だからこそ、このスレのこれまでのやりとりに驚いている。 今時初心者でも、他言語スレでもあり得ない流れだ。 で、パッチ出てきたけど、あれでは駄目だね。 彼等はC流のメモリ管理の方法を知らず、Gitは完全に糞コードで出来てる。 あれでは他にもメモリリークだらけだよ。 (ただこれも想定内っぽいし、 リークしたところでアプリとしては大した問題でもないのも事実だが) 彼等は、バグを直す努力はしているが、 バグが出にくいコードにする努力は全くしてない。 OOPもやりすぎると問題だが、何故彼等はそうするのかを学んで、 美味しいところだけ貰えばいいのにとは思うよ。 OOP原理主義者も、Gitプロジェクトやこのスレ民みたいなOOP排除原理主義者も、同様に問題だよ。 http://mevius.5ch.net/test/read.cgi/tech/1650651945/764
765: デフォルトの名無しさん (ワッチョイ 497b-vCJ4) [sage] 2022/11/03(木) 06:07:03.27 ID:AHw2USmo0 ただ見る限りGit界隈は密結合主義のようだ。 つまり、Gitと知識的に密結合した、Gitに詳しい奴だけがGitを使うべきであり、 tutorial1が基本コマンドなら普通はtutorial2は応用コマンドのところ、 なんと内部データ構造の紹介になってるし、 (ただこれは俺には極めて有効に作用したが、普通はブーイングの嵐だろう) http://mevius.5ch.net/test/read.cgi/tech/1650651945/765
766: デフォルトの名無しさん (ワッチョイ 497b-vCJ4) [sage] 2022/11/03(木) 06:07:22.90 ID:AHw2USmo0 ソースコードも密結合、これは馬鹿除けだ!と言い放つ。 糞コードでもパッチの手数で勝負だ!カリスマLinusならモグラ叩き志願者は無限に募れる! とまあ、他の誰も出来ないアプローチだね。 ただまあ、ソースコードを清潔に保つ目的は長期的メンテの為であり、 それは実際出来てるしいいだろ、と言われれば、はーそうですねー(棒)だが。 http://mevius.5ch.net/test/read.cgi/tech/1650651945/766
767: デフォルトの名無しさん (ワッチョイ 497b-vCJ4) [sage] 2022/11/03(木) 06:07:59.96 ID:AHw2USmo0 これ見てたら、buggyな糞コードでもとりあえず動けば受け入れてどんどん改訂し、バグもパッチの手数で勝負するのと、 普通のプロジェクトがやってる、レビューして駄目なコードは最初からrejectするのと、 (つまり手間をかけてもrejectされる可能性があるからコードを投げるのを躊躇される) どっちが良いのだろう?とは考えさせられるよ。 リソースが無限にあるOSSでは、前者の方がいいのだろうか? LinusはBillJoyに対して「オープンソースを理解してない」と思ったらしいが、こういう事なのだろうか? (この発言はLinus著作本にあるらしいが、俺は読めてない) しかしこのアプローチでは、絶対に浄化はしない。 自分の糞を片づけるのは仕方ないとして、 他人の糞を片づけたがる奴はいないし、そもそもその界隈が掃除に価値を置いてない。 しかし糞コードならどんどん投げてもらえるし、それらを受け入れる限り、進化が止まることもない。 はーなんだかねー。なるほど研究者と色々衝突するのも分かる気はする。 そういや大昔「伽藍とバザール」読んだなーと思って今読み返してみたが、これがバザールなのか? (NGにかかったので分割した) http://mevius.5ch.net/test/read.cgi/tech/1650651945/767
768: デフォルトの名無しさん (ワッチョイ d9e4-Ojdt) [sage] 2022/11/03(木) 10:41:57.59 ID:NhDXzDSd0 それだけ文句あるなら本家MLで言うか自分で作り直してみろよ軍師様 これだけ大口叩いておいて英語のMLでコミュニケーションとれないとかだったら笑うが Git は世界中のプログラマが使ってる最重要プロジェクトで、これが改良されるとなれば世界中から絶賛される http://mevius.5ch.net/test/read.cgi/tech/1650651945/768
769: デフォルトの名無しさん (ワッチョイ 699f-1Eu/) [sage] 2022/11/03(木) 10:46:51.87 ID:odT0DHDr0 まだやってのか 暇そうだな http://mevius.5ch.net/test/read.cgi/tech/1650651945/769
770: デフォルトの名無しさん (ワッチョイ 497b-vCJ4) [sage] 2022/11/03(木) 13:22:38.17 ID:AHw2USmo0 >>768 それは無理だね。 仮に時間が十分にあったとしても、俺が改善出来るのはソースコードであって、アプリではない。 アプリの改善には良い仕様にする事が最も重要で、実装は実は大した問題ではない。 (使う分には十分に動けばなんでも良くて、それが糞コードで出来てたから何?でしかない) GitはLinus本人が当時のVCSの問題点を全て把握してたからいい仕様になった。 俺はそうじゃない。今の俺がやったら俺にとって都合がいいだけで、他にとっては糞な物にしかならない。 ただ実際はLinusもこれで、みんな乗り換えて来たから同じ問題を抱えていたんだろ、 という解釈らしいが、いずれにしても使い込んでる奴じゃないといい仕様には出来ないんだよ。 そして例のブランコ問題 > 顧客が本当に必要だったもの > https://dic.nicovideo.jp/a/%E9%A1%A7%E5%AE%A2%E3%81%8C%E6%9C%AC%E5%BD%93%E3%81%AB%E5%BF%85%E8%A6%81%E3%81%A0%E3%81%A3%E3%81%9F%E3%82%82%E3%81%AE もあり、顧客自身が実装してるんだから、そりゃ商用VCSでは絶望的に仕様的に太刀打ち出来ない。 そしてソースコード戦略も違う。Gitはコードレビューとか無い世界なんじゃないかな? それで回るってのがスゲエが、多分これは「伽藍とバザール」の衝撃を追体験しただけなのだろう。 ソースコードを綺麗にしたら、新機能の追加が断然早くはなるけど、それは同じ人数での話で、 ここも手数で勝負だ!と来られたら、為す術もない。 ソースコードなんて糞でいいんだ、人数さえ有れば!では、研究者とは対立するよ。 なるほどエンジニアリングの天才だというのも納得ではある。 だからまあ、Gitを根本的に覆すにはGitよりも良い仕様が必要で、これは本当に難しいんだろうさ。 ところで、やはり俺のワークフローではIndexが邪魔なので削除しようと思うんだけど、 そもそもあれはどう使う為に設計されたものなのだ? 多分Indexの存在が一番直感的でなく、『説明されてないと』間違える所だと思うんだが。 今のところadd直後にcommitしてて、邪魔でしかない状態で使ってる。 http://mevius.5ch.net/test/read.cgi/tech/1650651945/770
771: デフォルトの名無しさん (ワッチョイ 7997-uk66) [] 2022/11/03(木) 13:30:44.47 ID:9oLRzF140 index stageなかったら複数ファイルの変更を一度にcommitできないじゃん。コミット粒度の問題から、全部の変更をcommitしたいわけでもないし。 どのcommitを取ってきてもちゃんと動く状態にするのが普通だからどう考えてもいるでしょ。 http://mevius.5ch.net/test/read.cgi/tech/1650651945/771
772: デフォルトの名無しさん (ブーイモ MMeb-ntN1) [sage] 2022/11/03(木) 13:52:50.16 ID:/4IN/B1bM indexの意味がわかってない馬鹿が全然関係無いファイルをコミットしてリポジトリをブチ壊す http://mevius.5ch.net/test/read.cgi/tech/1650651945/772
773: デフォルトの名無しさん (ワッチョイ 497b-vCJ4) [sage] 2022/11/03(木) 14:35:27.11 ID:AHw2USmo0 >>771 > index stageなかったら複数ファイルの変更を一度にcommitできないじゃん。 いや普通に出来るよ。曖昧だったが、俺は git add -u; git commit -m "message"; で使ってる。 以降はワークフローの話だからどちらが正しいとかいう事ではないが、 > コミット粒度の問題から、全部の変更をcommitしたいわけでもないし。 これは若干邪道というか基本的に全部commitするものだろうし、commitしてから前に進めばいいだけで、 > どのcommitを取ってきてもちゃんと動く状態にするのが普通だから これは俺の場合はちょっと違ってて、動かないのもcommitしてるしそれでいいと思ってるんだよ。 master/developブランチでは全部動くべきだけど、 featureでは途中のは動く必要ないし、動くようになったらdevelopにマージして消滅するんだろ? なら特に問題ない気がする。 途中経過を記録してないことの方が問題で、記録しすぎてたら出力から間引けばいいだろ、というノリ。 だからdiffが画面1枚に収まらないようならcommitする感じ。 実際はbanchを使うのはこれからで、git flow を真似して上記のようにするつもりだが、何かまずいかな? http://mevius.5ch.net/test/read.cgi/tech/1650651945/773
774: デフォルトの名無しさん (ワッチョイ 8b8f-5UCg) [sage] 2022/11/03(木) 14:40:47.35 ID:5PP47Osh0 git分からない思想も理解できないならSVN使えば? http://mevius.5ch.net/test/read.cgi/tech/1650651945/774
775: デフォルトの名無しさん (ワッチョイ 7997-uk66) [] 2022/11/03(木) 14:46:46.91 ID:9oLRzF140 >>773 そりゃgitの設計思想で想定されたコミットの仕方をしていないからindex stageがいらないと感じるだけでしょ。 大多数は設計思想通りに使っているので、index stageが必要だと理解していると思うよ。 だから、「どう使うために設計された」かと聞かれれば、gitの思想通りにコミット粒度を適度に保つためだとしか言いようがない。 「俺は違うから俺はいらない」はそれはそうだろうが、だから何?って話になる。 http://mevius.5ch.net/test/read.cgi/tech/1650651945/775
776: デフォルトの名無しさん (ブーイモ MMeb-ntN1) [sage] 2022/11/03(木) 15:04:33.12 ID:jVDh6EB5M 適当なタイミングで時系列に修正を記録していくものだと思ってる阿保には理解できないVCS http://mevius.5ch.net/test/read.cgi/tech/1650651945/776
777: デフォルトの名無しさん (ワッチョイ 497b-vCJ4) [sage] 2022/11/03(木) 15:05:56.85 ID:AHw2USmo0 >>775 git add -u を複数回して粒度を上げて動くものだけcommitしてもいいのだけど、 俺の場合は10回に1回程度は2-3回前の変更とdiff取った方が見やすいことがあって、 その場合にhash控えておくのが面倒だし、gcされてたらさらに面倒だし、gc切るのもまた邪道だろうしで、 動かないのもcommitしてfeatureの途中は動きませんと割り切るのが一番ましかと思ってる。 まあでもありがとう。 粒度調整の為ならこちらの予想の範囲内ではあった。 http://mevius.5ch.net/test/read.cgi/tech/1650651945/777
778: デフォルトの名無しさん (ワッチョイ a95f-Tk+f) [sage] 2022/11/03(木) 15:26:33.67 ID:O+O1uzzM0 >>777 > その場合にhash控えておくのが面倒だし、gcされてたらさらに面倒だし、gc切るのもまた邪道だろうしで、 N個前との diff は git diff HEAD~N でハッシュを控える必要もないし gc のくだりは何のこと言ってるのかわからない。 > 動かないのもcommitしてfeatureの途中は動きませんと割り切るのが一番ましかと思ってる。 ローカルブランチなら別に構わないけど、そのノリで作られたブランチをそのままレビューするのは効率悪い。 なのでマージ前のブランチをレビュー対象とする開発では push の際に整理することになるから、 都度整理の際にインデックスはとても有用。 他にも、作業中に全然関係ない typo 直したりするのにも使える。 http://mevius.5ch.net/test/read.cgi/tech/1650651945/778
779: デフォルトの名無しさん (ワッチョイ 8bbb-VzUj) [sage] 2022/11/03(木) 15:53:58.77 ID:HnXRQ5rf0 index の重要性が分からないやつが git 語ってて草。 素人向けに説明すると git の役目は他人に読んでもらうやすい分かり易いパッチを仕上げること。 個人で作る分にはそれほど関係ないが共同作業するには他人への分かり易さ、見た目は最重要といっていい。 料理に例えるならフライパンやまな板のまま出すんじゃなくて、皿に盛って食べ易くしてから出すのが基本。 ワークツリーがフライパンで、インデックスが皿。フライパンからでも直接食えるけど、綺麗に皿に盛って、そこで丁寧にチェックしてから提供すれば他人の作業効率が上がる。 http://mevius.5ch.net/test/read.cgi/tech/1650651945/779
780: デフォルトの名無しさん (ワッチョイ 497b-vCJ4) [sage] 2022/11/03(木) 16:18:44.28 ID:AHw2USmo0 >>778 > N個前との diff は git diff HEAD~N でハッシュを控える必要もないし gc のくだりは何のこと言ってるのかわからない。 (tutorial2を読んだだけの理解だから間違ってるかもしれんが、) 669で言ったように、Gitが分かりにくいのは業務プロセス名がコマンドに付いてるからだよ。 実際には、git add でスナップショットを取ってて、(←これが直感的に認識出来ない) git commit でツリーの頭にそれを付け加えてるだけ。 だからaddしてないと付け加えるべきスナップショットがないからコケる。 それで、>>103-107、stashしてたら何処かに存在してるし、 実はaddした時点で保存されてるから、こちらもgcが行われる以前ならhashさえ分かれば引っ張ってくることが可能。 ただし次のaddでindex先が切り替えられてダングリングになり、gc対象になるから、 存在してるかどうかはgcの動作具合による。 (だから初心者向けには、git add でスナップショットが取れてるなんて死んでも言えないし、余計に分かりにくくなってる) 俺が粒度を上げるのなら、commitせずに複数回addする事になり、 2回以上前のはツリーから外されてるのでHEADからでは辿れない。(git fsckなら探せるはずだが) だから動かない物もcommitしてHEADから辿れるようにしようとしている。 まあちょっと書き方が悪かったかもしれんが。 なので、実際の動作は git add 改め ss (take SnapShot)、git commit 改め relinkなのだけど、 ついでに relink もリストラして ss (git add -u; git commit) と ss -m "message" (git add -u; git commit -m "message")でいい。 これなら alias ss='git add -u; git commit' で済むし、 直感的になってアホでも使える。コミットメッセージが空なら動かない。 これが俺流の「勉強しなくていいGit」だよ。Indexよさらば。アホ向けGitこんにちは。 > マージ前のブランチをレビュー対象とする開発では push の際に整理することになるから 本体リポジトリとルールが違うと収まりが悪いのは了解した。 > 他にも、作業中に全然関係ない typo 直したりするのにも使える。 なるほどこれは微妙に便利かも。 (しかし俺流アホ向けgitでもこれは問題なく出来る。何せgitコマンドはスルーだからな) http://mevius.5ch.net/test/read.cgi/tech/1650651945/780
781: デフォルトの名無しさん (ワッチョイ 497b-vCJ4) [sage] 2022/11/03(木) 16:20:05.12 ID:AHw2USmo0 >>779 いやレビュー対象はcommit済みで、index上ではないだろ。 http://mevius.5ch.net/test/read.cgi/tech/1650651945/781
782: デフォルトの名無しさん (ワッチョイ 8b8f-5UCg) [sage] 2022/11/03(木) 16:22:38.83 ID:5PP47Osh0 うんうんわかった 大人しくSVN使え その方が君には向いている http://mevius.5ch.net/test/read.cgi/tech/1650651945/782
783: デフォルトの名無しさん (ワッチョイ d9e4-Ojdt) [sage] 2022/11/03(木) 17:18:17.27 ID:NhDXzDSd0 >>781 779はindex上でレビューするんじゃなくて、indexにいれた状態にしてからdiff --cachedでcommit前の確認をするってことじゃない?自分もそれやるよ http://mevius.5ch.net/test/read.cgi/tech/1650651945/783
784: デフォルトの名無しさん (ワッチョイ 8b14-Tk+f) [sage] 2022/11/03(木) 17:50:52.37 ID:e1pojM/n0 >>763 > (昔からsh《bsh》は互換性は高かったし、今はその後継のbashで統一されてる。 > ああ確かにcsh/tcsh/ksh/zshはゴミだったし死滅したよ) FreeBSDにはbash入っとらんぞ http://mevius.5ch.net/test/read.cgi/tech/1650651945/784
785: デフォルトの名無しさん (ワッチョイ 8b14-Tk+f) [sage] 2022/11/03(木) 17:52:28.68 ID:e1pojM/n0 >>763 > 既にあるbash(多分C)ソースをコンパイルしただけのものを同梱し、 > gsh(=gitsh)だ!これを使え!と強弁すれば済んだろ。 bashだけじゃ足らんだろ GNUコマンドも全部入れなきゃな! http://mevius.5ch.net/test/read.cgi/tech/1650651945/785
786: デフォルトの名無しさん (ワッチョイ 8b14-Tk+f) [sage] 2022/11/03(木) 17:53:10.48 ID:e1pojM/n0 >>770 > 仮に時間が十分にあったとしても、俺が改善出来るのはソースコードであって、アプリではない。 だからソースコードを改善しろってw http://mevius.5ch.net/test/read.cgi/tech/1650651945/786
787: デフォルトの名無しさん (ブーイモ MMeb-ntN1) [sage] 2022/11/03(木) 18:10:35.38 ID:3fLLADP3M >>784 macもbsahやめたんだよね GPLから逃げるために http://mevius.5ch.net/test/read.cgi/tech/1650651945/787
788: デフォルトの名無しさん (ワッチョイ 497b-vCJ4) [sage] 2022/11/03(木) 19:01:05.13 ID:AHw2USmo0 あと実は、masterの意義も分からないのだが。俺の場合は、 master: 今現在Web上で公開しているもの develop: 今現在ローカル上でテストしているもの feature: 今現在変更中のソースコード と3つポインタが必要なのは分かる。 しかし、masterは常にdevelopとfast-forwardマージするなら、developにタグ打てば済む。 途中からのbranchも可能だし、hotfixするにしても問題ない。 branchケチる意味もないのも分かるが、それにしても無駄に多い気もする。 と思ってたら、俺にはサル先生方式位が適切な気がしてきた。 > ここでは統合ブランチとトピックブランチという二種類のブランチを使った運用方法について紹介します。 > https://backlog.com/ja/git-tutorial/stepup/02/ サル先生方式の統合ブランチにタグ打つだけと比べて、 masterとdevelopとして別に持っておいたら何が嬉しいの? http://mevius.5ch.net/test/read.cgi/tech/1650651945/788
789: デフォルトの名無しさん (ワッチョイ 497b-vCJ4) [sage] 2022/11/03(木) 19:03:24.24 ID:AHw2USmo0 >>784 >>787 政治的案件をOSS側がフォローする必要ないと思うが… http://mevius.5ch.net/test/read.cgi/tech/1650651945/789
790: デフォルトの名無しさん (ワッチョイ 8b14-Tk+f) [sage] 2022/11/03(木) 20:29:42.55 ID:e1pojM/n0 >>789 なに政治的案件の話にすり替えようとしてるんだよ gitは環境依存が激しいシェルスクリプトに依存しないように C言語で書いてるって話をしていただろ http://mevius.5ch.net/test/read.cgi/tech/1650651945/790
791: デフォルトの名無しさん (ワッチョイ 8b14-Tk+f) [sage] 2022/11/03(木) 20:33:17.75 ID:e1pojM/n0 >>788 1系、2系の同時開発とかあるやろ http://mevius.5ch.net/test/read.cgi/tech/1650651945/791
メモ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 211 レスあります
スレ情報
赤レス抽出
画像レス抽出
歴の未読スレ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.016s