Git 19 ->画像>2枚

ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。

Git - Fast Version Control System
http://git-scm.com/

◆関連サイト
Pro Git - Table of Contents
http://git-scm.com/book/ja
Git入門
http://www8.atwiki.jp/git_jp/

◆前スレ
Git 17
http://2chb.net/r/tech/1599016710/
Git 18
http://2chb.net/r/tech/1650651945/

---

VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

乙

前スレの結論

- git はバージョン管理ソフト
- バージョン管理ソフトはバックアップソフトじゃない
- 管理するのはソースコードじゃなくて変更履歴
- お前の汚い試行錯誤の作業履歴をバージョン管理するな
- gitはお前の作業の管理ツールではない
- コミットメッセージはきちんとかけ

前スレ>>1000
どうぞ。ってか俺が答える訳じゃないけどな。

前スレ>>999
それが本質的に違うんだよ。
連中はいわゆるコードの「清潔さ」に価値を置いてないから（一般価値観からすると）デタラメなコードになってる。
そこに「綺麗な」コードを持って行っても、

え？なに？綺麗なだけ？バグは直ってないの？なら要らないよ

になるんだよ。「綺麗な」コードは汚いコードと同じ動作をする、綺麗なだけのコードだから。
そして「汚い」コードの方が簡単に書ける（＝設計を必要としない）から、手数では負ける。
だからもう既に「汚い」コードのパッチが出てる時点で、
誰かが「綺麗な」コードを持ち寄っても連中の価値観では無視される。
（仮に採用されるとしても、今後とんでもない糞コードで上書きされる事になるので、コードを投げたくもない）

ただな、「綺麗な」コードの目的は、結局のところ長期的保守だから、
今も、今までも、この方法でずっと保守出来てる、
とする連中には、効かないし、確かに意味のないものかもしれないんだよ。

だけどこれは学術界からすると異端も異端、でもそれで確かに回っちゃってるんだから、
どうなのよこれ？なんだよ。どっちが正しいのか/適切なのかも俺にはよく分からん。

ただ俺は、綺麗なコードを書きたいし、それが良しとされる世界がいいから、とりあえず近づかずにいよう、って感じ。
多分一般Cの連中も同じじゃないかと思われる。だからあの状態なわけで。

まあこれはさておき、だからマージ回数とかも半端ないわけで、
> ブランチを切るのに大変時間がかかっていました。
> 大規模なプロジェクトになると数十秒かかったりすることもありました。
> Gitだとこの作業が一瞬でできます。（前スレ897)
で、Linusは「一日で480しかブランチ切れないようでは仕事にならない！」というわけだが、
そりゃあんただけで、世界の他の誰もそこに苦労してないから、そりゃそんなもん存在しないよ、でしかない。

だからもう、何もかもが根本的に違うんだよ。

え、何？まだ続けるつもりなの？
てか、優秀な入門書とか既に出てるし大人しくそれ読んでりゃいいのに

>>5
> 連中はいわゆるコードの「清潔さ」に価値を置いてない
これがきみの思い込みで間違いであることは、きみの報告に対して挙がった 3 つのパッチの最後
"[PATCH 3/3] diff.c: use diff_free_queue()" が何の挙動も変えないコードクリーンアップである
ことを見れば明らかだね。
https://public-inbox.org/git/20221102220142.574890-4-szeder.dev@gmail.com/

思い込みで無意味な長文を垂れ流してスレを汚すのは止めていただきたい。

>>7
それ、コード構造が根本的に違うんだよ。

で、君のむかつきは、Git連中のむかつきそのもので、
俺や普通のCプログラマがいわゆるCコード持って行ったら、その対応なんだと分かるんだよ。
だから多分距離を置かれてる。
そして本人達はそれに気づいてない。けど困ってもいない。なんだかねー。

まー良く言えば多様性だねー(棒)
まあいいや、この話は結局所堂々巡りだし、続ける意味もないし、終わりにしようよ。
俺の持論としては、
「お前は分かってない、ということを相手に分からせるのが一番難しくて、それが出来れば8割終わってる」
なんだけど、まあ君らも俺に対して思ってるでしょ。そんなもんだよ。

複数人の共同開発だと、綺麗なコード書くより、綺麗なパッチを書く方が生産性が高くなるんだよ。そして将来綺麗なパッチが書けるように予め備えておくこと。
変更の行数とかそんなのは誤差だよ。一番時間のかかるのは人間どうしの理解、コミュニケーションなので、そこの効率が良いのが良いコードで綺麗なパッチなんだよ。
コミットメッセージがむしろ本体。

すまんがついで。

だから、Gitのコードをよくしたければ、Linusにレクチャーして貰えばいいんだよ。
そもそも彼のプロジェクトだし、彼は世界一に近い達人だし、彼の話ならGitの連中は聞くだろうし。

ちなみにLinusのコードはマジで凄い。
kernelコードでマクロで抽象化してるのがあって、
ブログ記事にしてる奴がいたからググれば出てくるはずだが、マジで記事書きたくなる位凄い。
こんな使い方あるのかよー、ってちょっと驚く。
OOPをCでやると全部手動だから面倒なのだけど、出来ないわけではない。
ただ、抽象はちょっときつくて、やったら普通にバグりそうなので俺ならやりたくないのだが、
はえー、なるほどこうすればいいのですかー、みたいなコードになってる。

で、Linusは送られてきたパッチに対して、
「僕はこういうコードを見るたびに、ああこの人はポインタの使い方を知らないのだな、と悲しくなるんだ」
とか言ってたから、コードを一応はレビューしてたんだろう。
だけど多分そのまま通してしまってるところが普通ではない。
もっとも、Linus基準だと、世界中の殆ど全てが糞コードなんだろうけどさ。

>>9
> 綺麗なコード書くより、綺麗なパッチを書く方が生産性が高くなるんだよ。
それは根本的に違う。
綺麗なコードはバグを含みにくく、或いはバグだと見た瞬間分かるから、
将来的にパッチが要らない。だから、基本的戦略が

一般： バグが発生しないように綺麗なコードにしよう。(パッチを不要にする作戦）
Git： バグは直せばいい。目も手もある。だからコードは汚くても、パッチも汚くても、問題ない。
　パッチなんていくらでも当てられるし、世界最高のパッチ適用システムを全員が熟知している。
　(だから元のコードはボロボロでバグだらけでも大した問題にならない)

なんだよ。あのパッチも汚いよ。それが分からないのはお前の問題。
ただ、元のコードが汚いからパッチも汚いわけで、あの元コードで綺麗なパッチを書くのは無理だ。
だから本来はかなり大がかりな修正が必要なのだけど、誰も気づいてないし、指摘もしない。（ように見える）

ただ多分、その前の根本戦略も違ってて、
Gitが出来た2005頃は「動いているコードはいじるな」だったんだよ。
それが、2010頃からか？「動いているコードであっても、少しでも改善出来るならどんどん直せ」になってる。
これは前者だと本当にすさまじい勢いでコードが劣化するから、すぐに使い物にならなくなると分かったのと、
色々みんな隠蔽やリファクタに慣れてきて、「正しく構成していれば」割と安全に直せるようになったのがある。(多分)
Git見る限り、もしかするとまだ前者でやってるかもしれない。それだと多分この先いつか破綻する。
だからみんな危険を冒してリファクタしてるわけでさ。
（と言いたいところだが、普通の開発では完全に頓挫するレベルを既に明らかに越えているので、このまま行けるのかも？)

ただ9のコードについての見解は完全に間違いだし、釣りレベルだが、
人についてはまあその通りで、
バザール開発においては人を集められること＝目と手の数こそがパワーの源泉であるのは事実だ。
だからそれを取り持つGitシステムが重要なのも事実だ.。
でも、バグパッチのcommitメッセージがいくら綺麗でも、それで人は寄って来ないよ。やっぱたぶんLinusだと思うよ。

>>11
2005年4月に最初のコミットが行われて、そこから2006年4月ぐらいの差分見てみると物凄い変更されてて、
この段階で「動いているコードはいじるな」とかありえないと思うんだけど

>>12
初段階では関係ない。それは「動いていない」コードだから。
安定稼働した、もう追加機能もパッチもあまり必要ない、と思ってからの話になる。
俺の常識が通用する連中ではないが、普通は多分数年の安定稼働後だ。

ちょっと言い方が悪かった。
お前ら、Gitはもうインフラだ！ファイル形式も変えられない！とか、言ってたろ。
そう思えてから、の話。

>>14
お前ホント書き込み全部適当だよな
2010年から劣化してるとかも適当に言ってるだろ

一番最初のコミットe83c516331をcheckoutすると壮観だな7つの簡単なコマンドしかない
init-db update-cache show-diff write-tree read-tree commit-tree cat-file
makeが有る環境に持っていくのちょっと面倒だからやらないけど、これたぶん簡単にmakeできそうで、動きそう

Gitないともう仕事できない
おっちょこちょいだからpush前にDiff見れるの超助かるわ

>>15
ああ書き方が曖昧だったが、変わったのはソフトウェア工学/業界の戦略だよ。もっと大きい話。
Gitはどっちの戦略でいつ頃までやってて、なんて事は俺は全く知らん。

ただパッチ見る限り、何か制約でもあるのか？と思える位に不自然だというだけ。
直すところそこじゃねーだろ、みたいな。

>>18
お前の言うことは全部適当すぎて何も信用できないんだけど？
例えばその見たパッチのhash出せる？

>>19
>>7

>>20
いやいや最近のじゃなくてその2010年ごろから劣化してきたパッチのhashだよ
もしかして >>7 見ただけで、これは2010年ごろからの全体の劣化！とかわかっちゃうの？スゴイなお前エスパーか

ド素人目。
「綺麗なコードだとバグを生まない」とか机上の空論なんだよ。人間はミスをするし機械は壊れるんだよ。
バグを生まないコードよりも、誰もが問題の原因をすぐに発見できてすぐに修正できる方が優れてるんだよ。
多数のプロジェクトの長年の経験によるベストプラクティス。
だから git 使うし、コミットメッセージをきちんと書くんだよ。コミットメッセージの有り難さとか理解できないやつが、バージョン管理ツールのスレで偉そうに語んな。

>>22
そもそもバグを生むのが間違い。POSIX原理主義ならバグは生まれない。この本に書いてある。

初めてのPOSIX原理主義 超進化を遂げたシェルスクリプトを学ぶ15回の講義
https://richlab.org/coterie/lpf.html

そもそもPOSIX原理主義ではgitを禁止してる。バイナリでデータを保存しているから
何年かたってgitから別のソフトに変わったときに取り出せなくなる。
バージョン管理ならシェルスクリプトを使えばよい。コミットはcp -pRやrsyncで十分だ。
冒頭コメントにファイルの名前や最終更新者や更新日時をかけ
diffで差分も見れるしgrepで検索できる。さらにはsed やAWK などをパイプで繋ぎ
ワンライナーとして実行すれば様々な切り口で過去リビジョンの閲覧ができる
楽をするな。工夫しろ、悩んで自分で解決策を見つけ出せ

> 12.1.1　1 行書いては実行 - そもそもバグを生まない
>
> デバッグという作業は、そもそもやる必要を無くせるのであればそれに越したことはない。
> デバッグ作業そのものからは、何も新たなコードは生まれない。
> 何もコードを生まない作業に好き好んで時間を割きたくはないからな。
>
> そんなことできるのか、と思うかもしれんが、答えは「1 行書き足しては実行、書き足しては実行……を
> 繰り返す」である。このことは既に今まで何度か言ってきた。何十行何百行もあるプログラムを
> 書き終えた後でおかしな動きをすることがわかったら、どの行に問題が潜んでいるのかの特定には時間がかかる。
> あるいは、全部作った後で出来上がったコードを見ながらテスト項目を立案するのも骨の折れる作業だ。
>
> 一方、毎行1 行ずつ書き足しては実行というテストをしていて、ある1 行書き足した時点で
> おかしな動きになったと気づけば、今書いた1 行に原因がある可能性が高く、場所の特定に割く時間を抑えられる。
>
> 1 行書いては実行というのはべつにシェルスクリプトに限ったテクニックではない。
> コンパイル不要な言語ならどれでも気軽にできる。しかし、UNIX シェルやシェルスクリプトは
> これに向いた仕様になっている。それを見ていこう。

いつまでしょうもないレスバトル続けんの？

>>23
キャラ作りもあるのだろうけど、冒頭はクレイジーだな。
blob(ただのコンテナ)が取り出せなくなることはないし、最悪自分で書けば済む。

それ以外は思想には同意するが、実際のやり方にはあまり賛同しない。が、当たってはいる。
学生の授業としては面白いだろう。選択教科なら名物になる可能性はある。(必修でこれはまずい)

お前らに話が通じないのは、お前らがコードを書かない連中だからだ。
だからリアルで例えてみる。Gitに習ってplumbing(配管工事)、つまり水道管だ。

一般的には、住宅に水道管を敷設する際、
高低差や区画情報(私有地ではなく道路の下しか通せない)を考慮し、
最初から、こういうツリー形状にすると計画を立ててから、工事をする。(設計)
勿論分譲予定が決まらなければ区画情報がないので無理だし、
測量が終わってなければ高低差情報が無いので無理だ。
そしていざ工事する際は、道路を封鎖することになるので、事前に告知し、
当日は誘導員を配置し、周辺交通の妨げにならないようにする。(リリースの計画)
敷設する水道管は当然新品だ。30-40年使えるようにね。(綺麗なコード)
そしてもし水漏れしたら、それが凍結による偶発的な事故なのか、
或いは何らかの設計ミスや施工ミスに依るものなのか、
また経年劣化で交換が必要なのか、検討する。
同じ事故を繰り返さない為にね。(レビュー)
これが一般的なやり方。
工事は順番だから、待たされることもある。
家庭で水漏れしたら、周辺の水道屋さん(当たり前だが資格試験はある)を頼って、大体数日後に直してもらえる。

バザールでは、水道が出ないより出た方が便利だから、各自が勝手に水道管を引いてしまう。(設計をしない)
水漏れしたら？その時に考えればいいよ。
いや実際漏れてるんだけど？ならパッチ当てよう。塞げばいいだけでしょ。
水の出が悪いんだけど？うーん、ちょっと高低差に無理があったからね、ポンプでも足そうか。
そんなことしたら水圧が上がって水道管割れちゃうよ？まあ、やってみればいいでしょ。
あ～あ、割れちゃったよ、てか錆すぎだろこれ！うん、だって元々中古だし。(最初からボロボロのコード)
え？最初は新品使うのが常識でしょ？いや、すぐ交換出来るんだからボロボロのでも問題ないでしょ。
いや～、毎回業者呼ぶの大変じゃない？業者？僕が工事すればいいだけだから問題ないよ。
え？それじゃ素人工事で全然駄目じゃん？いや、水漏れする度に何度でも工事すればいいだけでしょ。(ボロボロのパッチ)
でもやっぱ業者呼んだ方が…。そこまで言うなら、まあすぐ呼べるんだけど。秒速で対応してくれるし。
え？秒速？うん、水漏れしたんだけど！って言えば、誰かがあり得ない速度でシャシャッてきて交換部品(パッチ)とアドバイスをくれるんだよ。
そんなのあり得るの？うん、だって僕がその、世界規模での交換部品流通システムを開発したんだから。(Git)
とまあ、素人によるデタラメ工事＆秒速のモグラ叩き的修復で、乗り切ろうというわけだ。

ってな感じ。これぐらいのギャップがある。
設計もしないし、一切のレビューもしないし、反省もしない。
だから事故りまくりだが、すぐに修復されるので、巨視的に見れば水道を使えてる時間は長い。
これが、従来型の工事と比べて、どっちがサービス提供時間が長いか、ということなんだと思う。
水道工事は物理的なので、どうしても道路を掘り返す手間がかかるから、従来型の方が普通はよいとされるはずだけど、
コードは、経年劣化はないし、(ただの情報なので)交換も極めて容易だから、このアプローチが出来てしまうのか？
って衝撃が「伽藍とバザール」だよ。
俺も今それをまざまざと見つけられてるわけだ。
しかし、この発想には付いていけないし、付いていきたくもない。
俺の家にはきちんと計画して新品の水道管を敷いて欲しいし、順当な範囲なら、工事の順番待ちもするよ。
それで、「お前が水道工事業者で、新品の水道管を持ってるのなら、寄越せ！」って言ってるのが今のお前らだ。
いやいやいや、そうだとしても、こいつらとは関わっちゃいけない、と思うのが普通でしょ。


ただ実際は、Linusが基本設計をしているので、LinuxもGitも、
「文系馬鹿だから管を繋げば水が出ると思ってて、水道が山を越えててまるで話にならない」
みたいなことはない。これが
> 9. 賢いデータ構造と間抜けなコードのほうが、その逆よりずっとまし。
で、Linusは基本設計を終えた上で、
末端の水道工事なら無資格業者でも全く問題ない、それより工事しない方が問題、としてるだけ。
実際、基本設計(水道ツリー)がきちんと出来てれば、各住宅付近の引き込みは、単に繋げるだけに近いのも事実。
バックエンドのGitデータ構造の出し入れだけきちっとしてれば、
フロントエンドの各コマンドなんてバグってたら交換すればいい程度なのも事実。
実際、今回のメモリリークなんてそのフロントエンド内でもさらにどうでもいい案件で、新品や資格業者を使うまでもない。
従来型は、工事である限り新品であり資格業者必須だが、これが問題だ！というわけ。

この辺は実はもっと長期スパンの戦略もあって、「わざと」ゴミパッチでもやらせてる可能性もある。
実は今プーチンがやろうとしてるのだけど、30万人動員だっけ？あれが適切か、について、
ウクライナの戦場だと、前線に動員された兵士が1年後に生き残ってる確率は10%位になってしまってるらしいのだが、
逆に言えば10%は生き残るわけで、30万人の素人を動員したら1年後にはその過酷な状況を生き残った3万人の精兵に化ける、
だから長期戦視野で、1年後に欲しい人数の10倍、素人でも構わないから動員してしまえ、そうすれば死にはするが供給は出来る、という話。
これはソフトウェアも同じで、保守人材が欲しいならそれなりに育てる必要はあって、
Git的なワークフローに慣れてもらう必要はある。
だから今はど素人のクソコードでも受け入れてれば、数年後には10%位は熟練者になって残ってくれるかも？という戦略だ。
今回は本当にどうでもいいバグではあるので、素人工事でも練習にはなるからやらせておけ、ということ。
だから意図的にレビューもせずにスルーしてる可能性もあるし、この戦略も一概に悪いとも言えない。
勿論こんなのではリークは止まらないが、元々バグを修復するのではなく、修復する練習が目的だから問題ない。
ただ一般的には、こういうのは資格取得時に技能含めて講習することであって、
いちいち水漏れ工事させてユーザーに迷惑かけつつ教育するもんじゃない！ではあるが、
言っちゃ悪いが新人のOJTでの飛び込み営業とか完全にこれだし、リアルでやってる連中もいる。(今はもう無いのかもしれんが)

だからまあ、俺は少なくともGitに対しては半年ROMるべきなんだよ。
連中の戦略がまるで見えない。そもそも何も考えてないっぽいが。
（いや待て、これは孔明の罠だ状態)

相手してしまってゴメン
もう見えないように設定した

長文の人、仕事したこととか共同作業したことあるんか？

やめろよまた長文レスが来るだろ。

>>32
草

>>16
それらのコマンドのレイヤーは、

init-db, show-diff
commit-tree
write-tree, read-tree
update-cache, cat-file

だろうよ。まあlinusだしちゃんとしてるよ。
最下位を差し替えれば最終形式(blog)を、
tree階層を差し替えれば記録先(ファイルシステム)を、
commit階層を差し替えれば鍵(SHA1)を変更出来る。
当たり前だがこんなのやってるに決まってるんだよ。OOPの基本中の基本だし。
プログラマではないお前らは理解出来なくてもいいが、それで噛みついてこられても困る。
そして逆に、今鍵の交換程度で手こずってるのなら、
馬鹿がこの階層をぶち壊して直接階層を跨いでアクセスしてしまってるんだろうさ。
パッチ見る限り全く階層の意識がないからね。
動けばいいとしか思ってない馬鹿が書いたコードだよあれは。
ただ、10人の普通の人より1,000,000人の馬鹿だ！という戦略だし、実際それで何とかなってるのも事実。

ちなみに故ジョブスは「優秀なプログラマと無能なプログラマの生産効率の差は200倍だ」と言ってたらしい。
これは俺の体感とも大体合う。
戦闘力(最大200)*10人=2,000では戦闘力1,000,000と喧嘩してもどうにもならないので、
全く納得いかないが、バザール方式はエンジニアリングとしては正しい。
単純には、社内10人でプロプライエタリするよりは、
オープンにして2,000人のプログラマ(サンデープログラマでも全く問題ない)を集められれば、勝てる事になる。

あと誰か、初期実装の時と現時点で、フォーマットが同じか知らないか？
上位互換か？(＝初期実装版で書いた.gitは最新版で問題なく読める)
それとも完全互換？(＝現最新版で書いた.gitは初期実装版でも問題なく読める)


P.S. bookのURLを何度か貼ってくれた人達ありがとう。
今読み進めてるが、俺にはbookの方が断然よかった。

もう勘弁してつかあさい

>>31にノータッチな時点でもう答え出てたね

10月の終わりから、What's cooking in git.git　を浜野氏以外の人がＭＬに投稿している。
浜野氏は不調なんかな？

bisect-in-c の一連のパッチが17回も修正して、浜野氏がいろいろ言って、
現在[Stalled] になってる。
作者のjs ってwindows 版作っている人で以前も浜野氏にパッチをrejectされまくりで
険悪な雰囲気になっていた記憶がある。

>>38
https://public-inbox.org/git/xmqqwn8mh1di.fsf@gitster.g/
> Starting from next week (week #4---see ...),
> we'll try a mini "bus factor" exercise, where I will disappear from
> the list for a few weeks. ...
メンテナ不在に耐えられるかのテスト中らしいよ。おもしろいことするね。

>>40
なるほど

>>37
それは最初から答え出て太郎。
少人数でも共同開発したことあるやつがコミットメッセージ不要とか言うわけはない。

>>42
まあお前らがGit屋だってのはよく分かったよ

ついでだからソースを読めない君達にも分かるように、あのパッチのヤバさを説明してみよう。
バグ＝ゴキブリ出現と例える。
嫌悪感がある人はここで読むのを止めてくれ。

俺「あ、ゴキブリっぽい何か見つけました」
Git「はいゴキブリですね。ゴキブリホイホイを設置しました！」
Git「１箇所では足りないようなので、複数箇所にゴキブリホイホイを設置しました！」
Git「木目調のゴキブリホイホイに変更しました！」

いや違うだろぉぉぉぉぉぉぉ！そうじゃねえだろぉぉぉ！
ゴキブリの侵入経路を確認して塞ぐとか、
冷蔵庫や戸棚どかして一切全部掃除し直してさらにバルサン炊くとかだろぉぉぉぉ！
(言ってないけど)

Git「え？でもゴキブリが出る所全部にゴキブリホイホイを設置すれば、ゴキブリには遭遇しなくなりますよ？
　見た目？そのための木目調のゴキブリホイホイですよ？なんなら好きなキャラ描いて書いて貰ってもいいですよ？
　それでは無限にゴキブリが出る？なら無限にゴキブリホイホイ設置するだけですよ？」

こりゃ駄目だ、話が通じねえ、と思うだろ。
Gitの連中はバグの表面的なところだけを繕ってて、そのバグが発生した根本の原因、
つまり今回は壁がボロボロで穴が空きまくっててゴキブリが侵入してきてるんだけど、そこを見ようともしてないんだ。
というより、壁がボロボロだからゴキブリが侵入して来る、という感覚そのものがない。(因果関係を考えてない)
だから壁を直そうとかいう話に繋がらないんだよ。
そしていくらでもゴキブリホイホイを設置すれば、遭遇しなくなると思ってる。
(そりゃそうかもしれないが、そうじゃねえだろぉぉぉ！と叫びたくもなるだろ)

だから今回のパッチ、明らかに方向性が違うから、
俺だったら、というより従来型のCプログラマなら、見た瞬間rejectするんだよ。
それが分からない連中が、大まじめにゴキブリホイホイ設置して喜んでるんだから、こりゃ関わっちゃいけない、と思うだろ。
しかしこれで回ってる。
Gitにやられた連中は、アニメや映画の悪役ばりに、「く、、っこんな奴に！！！」と思ってるだろうさ。

正しい対応： 壁の塗り直し/補修
まだ許せる対応： バルサン
Gitで行われる対応： ゴキブリホイホイの多数設置

口先乙
長文書いてる暇があったらお前のいう正しいコードを書いて公開して見ろよ。
別に採用されなくても長文でグダグダ書くよりコードで見せた方が早いだろ。
言ってることが事実ならコードで見せれるだろ。お前ならどうするか具体的に見せろよ。
それが今すぐできないんなら、お前の主張は無価値な机上の空論ってことになる。

やめろよまた長文でやらない理由レスがくるだろ。

https://github.com/Byron/gitoxide
誰かやるかなあと思ったらやっぱりいた

>>45
なんの例えにもなってない
具体的に書けばいいのに

>>49
git の人気が悔しくて悪口書きにきてるだけだから具体例とか出るわけないよ。

>>48
トップページだけ見る限り、そのeinが俺が欲しいものに近い。(のだろう）
ただRustだからな～。今Rustって原理主義者が集まってて面倒な感じなんだよ。

>>49,50
一対一対応してて、割と具体的だぞ。
興味あるなら見比べてみ。

>>46
そうやって無駄に煽ってネット上の善意を吸収/浪費してきたのだろうよ。
コードクレクレ君は死ね。
(ただ本当に、誰でも書けるレベルのコードすら書けてないことをGit陣営は自覚した方がいい。
というか、書けない、ではなく、書かない、に近くて、
美しいコードに価値なんて無い、だからデタラメでもいいからさっさと書け、という価値観が見える。今の君にもね）


しかし俺としては「美しいコードは素晴らしい」という価値観の世界にしたいので、
Gitの状況を知った現在、Gitには肩入れしたくないんだな。
むしろ反Gitに肩入れして、Gitを殲滅したくなってきてる。
こんな価値観の連中をのさばらせておくのは、よろしくない。

多分今後はバグ報告も送らない。
だってあれに俺は3-6時間かかってるけど、まるで生かせてないし、見る限り無駄だったよ。
ただここで色々君らに情報を貰ったのは感謝してる。前スレ最後で数時間相手してくれた人には特に。
あと、大昔にさっぱり意味が分からなかった(事すら認識出来てなかった)「伽藍とバザール」を理解出来たのはよかったけど。

お前らのオススメのGit以外のOSSのVCSって、SubVersionなのか？
バケツに構ってる場合じゃないんだけど、いつか見てみるよ。

ただ飲食店が衛生的/不衛生なのと、美味い/不味いは別の軸だからな～。
VCSの根本の問題は、「管理側」が作ってることなんだろう。
Gitは「使う側」が作ったから、プログラマにとっては既存のVCSより断然仕様がいい。
ただLinusは「mergeしかしない側」だから、merge特化で、
俺みたいに日々の業務の履歴保持やバックアップ用には出来て無く、使い心地が悪い。
なら今後、「使う側」が「日々の業務用」のVCSを作れば決定版になるのだろう。
ただ、Gitに問題を感じないのだから、
Linusのコードの書き方はかなり最初期からアジャイルで、一般とは違うのか？とも思ってる。
(究極のアジャイルが>>23)
この辺も後日確認する予定。

あとさらについで。既に書いたように俺は君達には感謝してるから、
君達の成長の糧になるネタを残しておこう。俺なりの返礼だ。


Git陣営も、君達も、チームで働く意味を理解出来ていない。


チームを上手く機能させるには、「自分」ではなく「相手」の仕事を減らさないといけない。
そしてお互いに「相手」の仕事を減らす事により、チーム全体の仕事量が減り、生産効率が上がる。
これの古典的手法がドキュメントで、まあGitはこの点は十分出来てるよ。
(前言った解像度の不一致の件、あれは直しておいてくれ。ただ全般的にはかなりよく出来てる類だ)

だけど今回の顛末、俺は3-6時間かけて、丁寧にバグレポートを上げた。
再現コードをわざわざ作り直し、途中で出てきた回避策も入れて、最終チェックもした。
雑なレポートなら1-2時間で出来るところ、3時間ほど余分にかけて精度を上げてる。
一発で分かりやすく再現しなければ、余分に1-2時間ほど確認作業が必要になってしまう。
仮に5人で対応してくれた場合、そんなことで「チームとして」5-10時間消費するより、
俺があらかじめ3時間消費して精度を上げた方が、「チームとして」2-7時間得する、という戦略なんだよ。

Gitの連中は、俺のレポートで、「同種のバグの存在」を全く気にしていない。
それが彼等の技術的問題か、人格的問題かは分からないけど、
壁に穴が空いてることを気にせず、ゴキブリホイホイを多数設置して済ませようとしてる。
これだと、今回のではバグは収まらず、「同種のバグレポート」が、多分あと10通位必要だ。
そりゃ確かにあと10通来てその都度対応すれば全経路にゴキブリホイホイを設置出来るかもしれない。
だけどこれは、俺と同様の通報者だけで30-60時間消費、さらに対応する連中も数時間ずつ、
まあ単純に3時間として、5人なら3時間*5人*10回＝150時間消費するから、合計180-210時間消費することになる。
なら、最初のパッチを作る奴が10時間ほどかけて精査し、
「う～ん、これは壁の大規模補修が必要で、あと30時間ほどかかりますのでお待ち下さい」でも40時間の消費で、
140-170時間の黒字になるんだよ。だから本来はこれを目指さないといけない。
これが「バザール」で出来る事かどうかは俺には分からないけれども、
リソースが限られているプロプライエタリだとこうするしかないから、これがド定番で、
むしろGitの対応に怒りすら感じてるし、
まともに機能してるチームで働いたことのある奴は同様だろうよ。
相手の時間をすさまじく雑に扱ってて、しかも当人達はそれを自覚出来てない。
まともな奴ほど、次からはもう送らない、という選択になる。俺もそう。
(と、ふと思ったが、そもそも俺が既に5番目とか7番目の気がしてきた…orz)

だからさ、Gitの連中がデタラメやってるのも、
共同開発()してる君達が、俺が何を問題視してるかを全く理解出来ないのも、
チームで働く意味を理解出来てないからなんだよ。
それは機能してるチームで活動した経験がないから。
共同開発()は、Gitを使えば、或いは人数がいれば、達成出来ることではない。もっと上のレイヤーの戦略だ。
(俺が上記で指摘した点なんて、完全にアナログだし)
それは君達がGitで「管理」出来ると勘違いしてたのと同様、レイヤーを間違ってる。
Gitは「適用」「記録」ツールであって、管理ツールではない。
(記録＝台帳管理だから、それが管理だ！のレベルで君達は止まってる)
道具は所詮道具であって、○○使ってれば大丈夫！なんて事にはならないし、
世間はそのレベルで戦ってないんだよ。もっと上位の戦略で優劣を競ってる。



で、この辺でいいかな？
余計なお世話だったかもしれないが、
俺は君達やGit陣営の問題点を分かりやすく示すことにより、俺なりの返礼にしたつもりだ。
(ただGit陣営はこういう諫言を無視してきたから今がああなのだとは断言出来る。
同じ事を思った奴が世界でこれまで誰もいなかったなんてあり得ないから。
だから書くだけ無駄だったかもだが、まあ、受け取る受け取らないは君らの自由だ）

もう借りを返したつもりなので、今後は君達に問題点を見つけても無視する。
出来てるつもりの共同開発()ごっこを引き続き楽しむ自由も、君達にはある。

こんな人がPLだったら話長い人だなあと思って敬遠するわ。PMには向いて無さそうな人に思う

https://producingoss.com/ja/setting-tone.html#avoid-private-discussions
> 公開されている場所で議論することによるさまざまな損失があなたの頭の中に浮かぶことでしょう。...
> 本当は何もわかっていないのに 「自分はすべてわかっている」と勘違いしているボランティアへの
> 対応 (どんなプロジェクトでもこの手の人がいます。彼らのうち何人かは将来すばらしい貢献をしてくれる
> ことになるでしょうが、 中にはずっと勘違いしたままの人だっています)、ある問題 X が
> より大きい問題 Y の一部であるときに、 なぜ問題 Y ではなく問題 X だけを解決したいのかを
> 理解してくれない人たち、 などなど。...

長文君にはゴミ箱がお似合い

ごみ箱でバージョン管理する手法が提案される
https://srad.jp/submission/54492/
Windowsのゴミ箱を「作業フォルダ」として使っている人は意外といるらしい→驚愕の声続々
https://togetter.com/li/892609

https://twitpic.com/dtqxgo
画像貼れるかわからないけど、なかなかいい提案

長文くんは空想と現実の区別がついてなさそう
レポートも本当に送ってるんだか

日々の作業のバックアップだけしたいならそもそもVCS使う必要ないしな

>>58
その切り取り方はだいぶ酷い。続き読んだら正反対の結論だし。
ちなみに本編のその部分の内容には同意。リンク先は俺にはまあまあ面白い。ありがとう。


切り取り方に悪意がないとして、それが君の意見なら、
回答は、上位戦略、
「動いているコードはいじるな」「動いているコードであっても、改善出来るのならどんどん改善しろ」(11)
による。前者の場合はXの修正に留め、後者の場合はYを修正する。
ただこれはソフトウェア界では既に結論が出てて、「後者(Y)じゃないと無理」だ。(よって疎結合化は必須)
だから『今は』余程の事がない限り後者で、
その本が前者なのは、上梓が2005.10で、おそらく2003頃の常識で書かれてるから。
その頃は前者が主流だったのは11に書いたとおり。
そしてGitももしかして？なのは18に書いた通り。修正が『今の常識からすると』普通ではないから。

ただ、Gitの場合はおそらく技術的問題だと思う。
Xの修正に留めるのは、変に壊さない為だが、Git陣営は今壊れているところすらも「きちんと」直そうとしてない。
だから、そこで言われてるXでもないんだ。
ちなみに、「正しいXの修正」が45における「バルサン」だ。
壁の補修が必要なのは分かるが、それは今とても出来ないから(或いは賃貸等でそもそも出来ないから)、
せめて今出来る最善手で、ということ。
Gitは今打てる最善手すら打とうとしてない。
(コードの修正範囲を絞られたとしても、もっとましな解決方法がある)
だから多分技術的にも足りてなくて、それは本人達の慢心だよ。
傲慢でつけあがってるから、他人がどういう解決をしているか調べたこと無いんだよ。
Cの基本的手法を見たこと無いはずがないし、よくよく考えれば、見た目違うだけで、
C++も、C#も、Rustも、本質的には同じ解決方法を採ってる。
だから、C以外の言語であっても「きちんと掘り下げて」勉強してたら、こうはならないんだよ。
多分連中は、Cを書けるだけで満足してて、しかもCの基本的(=伝統的)手法を馬鹿にしてる。だからこんな事になってる。
(スクリプト系も全く使えないから仕様もおかしな事になってるし)
だから不勉強の根っこは人格的問題で、結果、技術不足が発生してる。

というところまで見えてしまうから、まともな奴は近づかないよ。
俺もこりゃ駄目だ、大体こんな奴等に構ってられる状況でもないし、って感じ。
そもそもLinusがいるんだから任せときゃ問題ない。

ちなリンク先
> "綺麗で、読みやすくバグのないコードを書きましょう。" といったことをガイドラインに書いても意味がありません。
> もちろん、これらは望ましいことではありますが、 これらが望ましくないと思われる世界は存在しないので、言及する価値がないのです。
> https://producingoss.com/ja/written-rules.html
なおGitとこのスレ

>>59,60
それを揶揄するのがお前らの傲慢なところだ。(60は賛同かもだが)
それは、「ユーザーが実際に求めてる機能はその程度で十分」ということなんだよ。
まさに、例のブランコ状態。Gitなんて超超超超オーバースペックだ。
たださすがに「ゴミ箱」は怖いから、
「バケツ」アプリで、GUIは完全にゴミ箱と同じ、ただし消せないし消えない、で一般には十分なんだよ。

従来VCSが提供したもの： 管理者に都合がいいだけの、すさまじく使いにくいVCS
Gitが提供したもの： 超超超超オーバースペックで、確かに何でも出来るが、すさまじく分かりにくいVCS
ユーザーが本当に欲しかったもの： 消えないゴミ箱

> Gitなんて超超超超オーバースペックだ。
誰が困るんだ？
必要ない機能なら使わなければいいだろ

>>66
×ユーザーが本当に欲しかったもの： 消えないゴミ箱
○バージョン管理を理解してないバカ（お前）が理解できるギリギリの機能：消えないゴミ箱

こうやで、間違えんな

管理者の為の仕様部分がオーバースペックって言ってるんかな。
管理の都合で記録残したりが嫌かな。
言いたいことが分からんでもないが、みんな人間的に欠陥持って仕事しているので、数人で仕事する時にはその機能があって良かった時も出てくるで。

世の中にはバージョン管理が理解できなくて、必要性を全く感じない人もいるのだな。
git の機能は実際に必要な人が多数いたから実装されたものがほとんどなんだけど。
自分が不要な機能は他の人も不要と思っちゃうところが素人の限界なんだろうな。
そういう馬鹿ユーザー層にも git の知名度が上がったんだろうけど、今頃ようやく勉強始めてスレを長文で荒らすのは勘弁して欲しい。
git は既にかなり長い歴史のあるソフトウェアなんで長期間便利に使い続けている人が多数いるんだぜ。
何が気に入らないか知らんけど、このスレを荒らしても git には勝てないぞ。

このスレを荒らすことでgitに勝った気になりたい人なんじゃないかな多分

長文君は「傲慢でつけあがっている」人たちがつくっているgitを使わずに「バケツ」アプリを使えばいいのに。
みんなの望んでいるのがgitでなく「バケツ」アプリというのが本当なら、実際にそういうアプリがつくられて
改良を続けられているはずだから。それこそgitよりもずっとね

>Xの修正に留めるのは、変に壊さない為だが、Git陣営は今壊れているところすらも「きちんと」直そうとしてない。
>Gitは今打てる最善手すら打とうとしてない。
>だから多分技術的にも足りてなくて、それは本人達の慢心だよ。
>傲慢でつけあがってるから、他人がどういう解決をしているか調べたこと無いんだよ。

>まさに、例のブランコ状態。Gitなんて超超超超オーバースペックだ。
>ユーザーが本当に欲しかったもの： 消えないゴミ箱
>「バケツ」アプリで、GUIは完全にゴミ箱と同じ、ただし消せないし消えない、で一般には十分なんだよ。

今時のOSはバケツ機能が標準搭載されてるから
Gitを理解できない長文君でも安心(笑)

Time Machine で Mac をバックアップする
https://support.apple.com/ja-jp/HT201250
Windows のファイル履歴
https://support.microsoft.com/ja-jp/windows/17128

それこそ電動ドリルのスレに来て、「メーカーは釘打ちユーザーのことを何もわかってない。オーバースペック」とわめいてるレベルなんだよな。
メーカーに直接クレームいてれ迷惑かけてないだけまだマシという考え方もあるが、恥というものを知らないらしい。

「今後は君達に問題点を見つけても無視する」とか書いてあってちょっと期待したのに１日も我慢できないじゃねーの。ほんとこいつ

初心者の中には以下の違いの区別ついてないやつがいる
1）バックアップ…ハードウェアなどの故障に備えてデータの保全を図るシステム
2）作業記録…作業ミスなどに備えてデータの更新を記録するシステム。セキュリティ目的の場合もある
3）バージョン管理…作業の成果物を効率的に管理して情報共有や意思決定を支援するシステム
git はこのうちの3)のために特化したツールなので1)や2)の目的で使おうとしても無理がある。ちゃんとやりたいなら他の仕組を併用しなければならない

バージョン管理で意思決定とかちょっと何言ってんのかよく分かんないがman gitしても意思の決定を支援してくれそーなコマンドは出てこなかったよ
Siriみたいのがあーしろこーしろ答えてくれるコマンドがあんのか?

>>77
たぶんgitとGitHubの区別が付いてないと思う

これは GitHub のAI は賢いよ、という御告げかな。
使ったことないのだけど。

バージョン管理でいう「意思決定の支援」は、適切な情報を保存し提供することで変更方法や戦略などの取捨選択を素早くできるようにするというやつだな。必要な情報を必要な時に参照できるのがバージョン管理の必須要素だよ。

バックアップしたデータや作業ログを見てもバグ修正の方法とか機能追加の方針とかは決めれないけど、git のコミット履歴があると決定の助けになるだろ。
機械が勝手に判断してくれる魔法みたいな話じゃないので期待すんな。
git log, git blame, git bisect などで素早く目的の情報を探し出せるというのは重要機能。

>>67-72
GitはGitで良いんだよ。Linusが必要だから作ったのだし、
確かに全世界で同時開発してて、既に安定版もリリース済みなLinuxには最適だろう。

ただ、今Gitが一般人や職場で使われてる領域では、世界規模な同時開発なんてやってない。
日々の進捗を記録し、履歴を保持し、バックアップが簡単に取れれば十分なんだよ。
これにGitが使われてるだけ。実際欲しがられてるのは「全自動履歴保持バケツ」。
だからGitが悪いのではなくて、他のアプリがしょぼすぎてGitを滅ぼせないのが問題なんだが。

なお散々言ってるが、俺はGit自体が気に入らないのではなく
・Gitの仕様がグダグダ過ぎて、余計な学習コストがかかりまくるのと
・Gitの開発がグダグダ過ぎ。
俺達はGitを使ってるから世界一の開発出来てる！とでも勘違いしてるからあんなことになるんだよ。
Gitはツールでしかない。上手く使えてるかはまた別だ。
肝心の本家がグダグダ過ぎ。
本家はGitとはこう使う！という広告塔でもあるのだから、もうちょっと真面目にやれよ。
これにソースを読み書き出来ない君達は気づけないだけ。
君達もゴキブリ駆除業者呼んで「ゴキブリホイホイの多数設置」されたらブチ切れるだろ？
割とこれ、当たってる例えだからな。(身近にCを「きちんと」書ける奴がいたら聞いてみるといい)

じゃあ自分で作れ？なら、確かに作れるが、我慢してGitを勉強した方が早い。(再開発が面倒なだけ)
だから誰も作らないわけで、Gitが日々の業務にフィットしているわけではまるでない。

あと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用員」の需要を世界規模で消滅させ、路頭に迷わせるのが正しい解だね。

具体的に言うなら、「学習コスト高すぎ」問題だ。
見る限り50-100時間程度か？少なくともチームの一員として
「リポジトリを破壊せず、普段のコード提出は問題なくでき、チームに『Git用員』が不要」なレベルに到達するまでに。
ただこれは本当に酷い話で、「ゴミ箱」アプリなら完全に把握するまでに5分だろ。なら、50-100時間丸々開発に使える。
あと今回俺が言ってるクソソース問題、
実はCの場合は言語機能がほぼ無いので、ソリューションはどれも馬鹿げているほど単純で、
見れば分かるものしかない。(他言語では文法でサポートされてるので各々2-3時間の勉強が必須)
そしてあまりに馬鹿げてるから「イケてない」扱いされ、傲慢な若者には無視され、結果、メモリリークしてるわけだ。
これは「何故みんなこうするのか」をレクチャーすれば済む話で、
技術的には10分あれば十分なんだよ。(パッチ送ってくるレベルの奴には)
ただ、絶対人の話を聞かない連中だから、Linusがやるしかないけど、
これを省いてGitに学習時間50-100時間かけてクソコードを量産してるんだから、完全に本末転倒だろ。
ここで同種のバグを一掃しないと余計に時間がかかる、という感覚がないのもどうかしてるし。
gitが難しくて、結果的に「『頑張って』勉強するんだ！」みたいな奴が集まってるのはいいのかもしれんが、
頑張る方向を完全に間違ってる。
「ゴキブリホイホイの無限設置だ！」と頑張られても、そりゃ違う、と思うだろ。
(頑張る連中なんだから、正しい方向に導けば上手く流れるだけなのに、そうしないのは上部の怠慢だよ。つまりLinusだな。
頑張らない連中のケツを蹴飛ばして何とかするのとはだいぶ訳が違う)

とはいえGitは大体把握した。
俺が使いたい範囲で何が出来て何が足りないかも分かったし、聞いてた話とも整合性が取れた。
色々情報をくれた人はありがとう。
「バケツ」アプリ、割とマジでゴミ箱仕様で作ってもいいんだが、需要あるかね？
(まあこのスレに来ない連中に聞かないと駄目だが)
今すぐ、というわけではないが、アプリ製作も一回やってみようと思ってはいるから。

あと勘違いしてる奴がいるが、俺が今回Gitを使うのは既定路線だ。
その際にバグに遭遇していろいろ内実が見えて、クソだなと感想を漏らしてるだけ。

あとこれ、rebase履歴も保持されないよな？
commit履歴は基本的に整理用だが、
rebase履歴が保持されないのは仕様としてかなり不味い。
そりゃお前らGit屋は完成したパッチしか興味ないのだろうが、
実際のプログラマは各ブランチで平行作業してパッチを製作し、マージする段になって、一本鎖で済むようにrebaseするのだろ？
その際、rebaseでの競合は「手動」で解決するだろ。だからそこでバグを組み込む可能性があって、
パッチを作る側としては、rebase前に「いつでも」「どのポイントにも」戻れないと不味いんだよ。
だからここら辺も本来はViewを分離したアーキにして、
rebaseは「見た目」一本鎖になりますが、内部DBはそこでマージされてるだけで、rebase前の状態も全部残ってます、が正しい。
(まあrebaseしなければいいだけだ！といういかにもC的な馬鹿っぽいソリューションはあるが、それでは管理側に許してもらえないんだろ？)
LinusはGUI全く作ったことがない？のか知らんが、アーキにMVC感がまるでない。
ただMVCも、きちんとやった方が後々色々楽なんだけどね。

ついでにSubVersionの糞っぷりも見えてきてるぞ。
> r13222, r13223, r13232
> libsvn_fs_fs の自動マージアルゴリズムを書き直した
> 変更する理由:
> 30万リビジョンが格納されたリポジトリのパフォーマンスが許容できない
> (小さなコミットをしても50分以上かかる)
> https://producingoss.com/ja/stabilizing-a-release.html
勿論もう直ってるんだろうけど、これはそもそも基本アーキがゴミだからこんな事になる。
順方向履歴しか持ってないのだろうよ。最低限逆方向履歴も持たないと駄目だ。
(持ってても整合性取れるまでcommitさせない仕様なら意味無いが)

あと俺がGitに批判的なのは、今の「PC不要論」と同じだ。
スマホで十分な連中には、PCはもう要らないのと同様、バケツで十分な連中には、Gitは要らない。
今はバケツがないからそう感じられないだけ。

>>73
それは知ってるが、余計に使いにくいのと、
実際は空き領域を使う(SSDでいうウェアレベリング)でしかないので、
満タンになると自動的に消されるので使えない。
手動でディレクトリごとzipして名前に日付付けて並べた方がまだマシ。

>>85
ちゃんとテストするから問題ない
お前とは違う

これを思い出した。

Linus曰く「Subversionは史上最も無意味なプロジェクト」
https://m.srad.jp/story/07/12/03/1024220

>>82
電動ドリルのスレで、釘を打つにはコツがいる。学習コストが高いって子供が文句言ってるだけだな
電動ドリルはお子様には向いてない危険な道具なのでどっか行け

>>82
グダグダと思うのを使わずに「全自動履歴保持バケツ」を使えばいい
皆が欲しがっているのが「全自動履歴保持バケツ」というのが本当なら誰かがそれをつくるはずだからな
誰もつくらないのなら「皆が欲しがっているのは『全自動履歴保持バケツ』」は間違いということ

gitはそれを欲しがっている人たちによってつくられてきたわけだが、その人たちに
「俺が欲しいのはそれじゃない。俺が欲しいものをつくれ」と言うだけで自分ではやらない
口だけ番長の長文君

>>83
へえー君の言うバケツ方式なら猿並みの脳みそでもリポジトリ破壊しないのかーすごいなー是非作って欲しいわー

>>92
バックアップするだけだからな
誰でも出来る

バックアップを取り出したり比較したり
そこからパッチ作ったりマージするのが難しいだけ
猿にそんなものは必要ない

長文の人頑張れ。君ならできる(かもしれん)。
Linusが2週間でgitを作った話。 を検索するとgitの初期の話が出てくるよ。

追加で
https://gihyo.jp/dev/serial/01/alpha-geek/0040

>>94
絶対無理じゃよ。
今までの文章見ててもまともなコード(動くコードって意味じゃなくて長期間メンテするような有意義なコード)を書いたことは無いのは明らかだ。
本とかウェブで読んだことを理解できずに超解釈して受け売りするだけの転売ヤー。

長文君にぴったりの 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も不要な長文君はこの五つの手順だけ覚えとけばいいぞ
コマンド長くて覚えられなかったらエイリアスにでもしとけな

>>88
バグにはすぐに引っかかるものと、そうでないものがあるんだよ。
お前らが理解出来るとは思ってないけど。

Gitはパッチ適用ツールであって、本当に、パッチ書く側のサポートが全くない。
Git作ってる連中も、コミッタ？は結局パッチ適用側に回ってしまって、自分でパッチ書かなくなるから気づけない。
ありがちな展開だけどさ。
そして使う側は（目的外使用ではあるが）書く側として使うからずれる。

だから、求められてるのは「書く側」向けの「全自動完全履歴保持バケツ」。

>>90
Gitが提供しているもの： 1000ページの取扱説明書を読まないとまともに使えない、超高性能電動ドリル
ユーザーが欲しかったもの： 引き金を引けば回るだけ、簡単で今すぐ使える、ホビー用電動ドリル

ちな、CodeOfConduct読んで、あいつら中の人か！ってのが分かったので俺的査定。

Avar Arnfjord Bjarmason: 今なんとか方向修正を試みてるように見える。上手く導ければ有能だが、果たして？
Christian Couder: 出てきてないので不明
Junio C Hamano: 休暇中？らしい (40)
Taylor Blau: 無能。ってか閻魔大王が全スルーするならいないのと同じ。ちゃんと門番やれ。

そういえばGitのコーディングルールはどこにあるのだ？
今回ほどの糞コードは、コーディングルールで引っかけて落とせるはずだが。

>>89,94,95
全部読んだ。なかなか面白かった。(89はコメントも全部読んだ)
君が冷やかしかマジかは分からないが、マジで要るんなら作ってみてもいい。
ただし今すぐ取りかかれるわけでもないし、全般的に考えて本年度末(3月末)位が現実的な目標になる。

今考えている構成をざっくり言うと以下

・Gitをゴミ箱/バケツ化するラッパ(フロントエンドのみ。バックエンドはGitで、Gitは別インストール必須)
・electronで作ってwindowsストアに配置(広告付き無料アプリ)
　十分売れてる限り保守してやんよ(その必要すらないほど単純なアプリだが)
・プロプライエタリで伽藍開発。バザールなんてとても無理。コードは俺が書くから、お前らは使い勝手をフィードバックしろ。
・GitBucket(仮称)、Gitと付けたら不味いのなら考え直す
・コンセプトは、「何も知らなくても使える『全自動完全履歴保持バケツ』」
　よって仕様は限りなく簡素化し、それ以上やりたければDBはgitだからgitアプリ使え、とする
・diffは取れるがmergeは直感的GUIがないので無理。が、主にバイナリを保存する連中には全く関係ないし。
・branchはディレクトリに割り当てて手動で。というより、git内にcommit履歴が保持されてないのでbranchの識別が出来ない。

実装するだけなら2週間程度で十分だが、

・electron使ったこと無いので調査に2週間ほどかかる
・アプリストアも広告付きのアプリも作ったことないので、これも2週間ほど調査必要
・仕様を練らないとろくな事にならない、
　Linusが2週間と言ってるのは実装であって、それ以前にずっといろいろVCS使ってきてるから仕様が熟成済みだっただけ。
・そもそも顧客がいるかどうか
・一応は他WindowsGitアプリを全部確認する必要がある。今tortoiseGit試しにインストールしてみたところ。

があるので、冷やかしでないのなら新しくスレ立てて様子見する。
スレタイには GitBucket(仮称)と、何か「Gitはもう諦めた系」「頑張らない系」の連中を集められる文言を入れたいが、何がいいか。
板はここかソフトウェア板だと思うが、他に候補があるか。
ただ対象ユーザーはここに来る連中ではなくガチのど素人なので、もっと全然違うところの方がいいかも？
　
スレタイ案：
A. もうGitBucket(仮称)でええやん。
B. GitBucket(仮称)使ってるからって、Gitが分からなかった訳じゃないんだからねっ！！！
C. GitBucket(仮称)計画中、Gitに疲れた奴集まれ
D. 日常のバックアップツールGitBucket(仮称)

冷やかしじゃない奴からの投票を受け付ける。

>>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を使う人も使わない人も問題ない)

electron 使うなら、ブラウザ上にOSのデスクトップ画面を再現するのと同じ事ができるだろう。
ゴミ箱/バケツのところでなくて、デスクトップに置いて管理されている事になっているファイルをコントロールできるようにして欲しい。

>>98
> Gitはパッチ適用ツールであって、本当に、パッチ書く側のサポートが全くない。
パッチ適用ツールはpatchコマンドっていうんだよ
gitはそれ以上のサポートがたくさんある
これ以上何がほしいいっていうんだよｗ

>>103
> 俺だったら、branchなんて、各ディレクトリにそのままマッピングする。
同じ名前のブランチが複数あることを想定してないね
ちょっと失格かな。

>>103
> というわけでGitBucketは基本この方針でmasterに全ての履歴を数珠繋ぎ、
ああ、GitとGitHubの区別もついてなさそうだね

>>103
> branch切換で全部上書きで入れ替わるのは、頻繁に過去と現在を往復するにはいい仕様だが、普通の人には要らん。
branch切り替えで入れ替わるのはコミットしたものだけだよ
これは便利でコミットしてない設定ファイルやデータファイルなどは
そのまま残る

こういうことまで考えつかなかったでしょ？ｗ

>>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は出す)

てな話を仕様として詰める必要があって、つまり、

1. どういう機能が欲しいか
2. それはこの仕様(実装)でいけるか

みたいなこと。
ちょこちょこやるのはさておき、本格的にやるならスレ分けるべきだな、という話。

>>105
commit/rebase履歴の全保持と、commitのフィルタ機能だね。
記録側からみればゴミなcommitも、プログラマからみれば重要なんだよ。だからそれを見えなくする機能だね。
CSSでいうdisplay:noneの機能。
今は、「綺麗に清書して＝プログラマには必要だったコミットも全部消して」提出しろ、になってるだろ。
これが無駄だし、プログラマ的には不快だ。
それは悪戦苦闘の記録であって、デグレードした場合に参照したい時もあるんだよ。消してるのは不味い。
ローカルだけにしろ、はその通りだが、今はローカルだけにも出来ない仕様だろ。(無駄にブロックチェーンしてるので)

>>106
世界規模で勝手に開発してるLinuxならそうだろう。
しかし、ローカルファイルシステム、或いは共有ファイルシステムに於いては、当たり前だが「同じディレクトリ名」＝「同一」なんだよ。
だからディレクトリ名が被って困る、なんて事はない。
そして、バックアップ的には、branchはパスが伸びた程度の意味しかないから、これで問題ない。
(git流のbranchの使い方をしてても、これで問題ない。
通常のファイルシステムでは、パス+ファイル名が同じなら同一と見なすが、
ここがgitではパス+ファイル名+ブランチ名になってるだけ。
branch自体の参照先も変えられる！と思うかもしれんが、それはユーザーがそうしたのであって、
確か○月○日頃の○○ブランチ内にそのファイルがあるはず、と思い出すのはユーザー責任だ。
いずれにしても何処かに記録はされてるから、あとは頑張って探せという仕様)

git関係ないけどWindows10 1607以降はMAX_PATH制限なくなってるんだな

>>108
知ってるぞ。
ただ、切り替わらなくてもいい共通ファイル類はその場合には .git 階層に置くんだよ。

というかね、gitが何故か「カレント主義」になってて、とにかく「カレントディレクトリ」なんだよな。
これは本当によく分からない。
俺がGitGUIで最初にやったのは、「Open repository ...」を探すこと、だからな。
無いから、「え？まさか？カレントで起動しないと駄目なのか？」でわざわざショートカット作り直して起動し直した。
普通そんなアプリ無い。この辺は、「いつも通りのアプリ」じゃないと駄目なんだよ。

>>101
仕様や開発グループがグダグダだと思っているものをバックエンドにするのか
「gitがグダグダだからできなかった」と言い訳して終わりそう

>>103
mergeのことは考えてないんだな

>>102
投票とかどうでもいいから早く別スレ行け
馬鹿向けのアプリは馬鹿だけが多数寄ってきて繁盛するからそっちで頑張れ
git は馬鹿には使えないことが理解できたんだろ

>>103
ブランチにディレクトリを使うのは既に subversion がやって失敗した道だぞ
ファイル数やファイルサイズが大きくなるとブランチ切るのに時間とディスク容量がかかり過ぎる
過去話読んでも何も学ばないやつはゴミを再発明するよな
とはいえ、お前やお前が想定しているユーザー層はたいした規模のプログラム組まないだろうからゴミでも十分かもな、知らんけど

>>115
車輪の再開発はしないんだよ。
どこまで使えるか判断して、その範囲は使うし、それを超えた範囲は使わない。
(今の実態だと、git add 絶対パス、はほぼ確実にバグを踏むから使わない)
自分で作ればバグがない物が簡単に出来るわけでもないし。

> mergeのことは考えてないんだな
GUIでmerge、例えばドラッグアンドドロップでmergeは怖いだろ。
コピーするつもりがmergeされたら悲惨なことになる。
(コピーや移動と同じGUIにmergeをアサインしてはいけない）
だからmerge自体はgitアプリで明示的にやれ、という仕様。その方が安心だ。

そもそもバイナリはmerge出来ないし、
GitBucket使うような連中にはmergeなんてほぼ要らん。

てゆうかね、そもそもmergeが主な仕事ならgit使うべき。あれは完全にmerge特化型だから。
GitBucketのユーザーは、そのmergeのネタを作る側、つまりプログラマとかクリエーターとかだ。
管理側じゃなくて、管理される側。

>>111
アホでやんの。マニュアル斜め読みしただけで実際に使用してないので本質が見えてないな
rebase する前に新しいブランチ切ってやれば
rebase前とrebase後の両方残せるという基礎の基礎すら理解できてないのか
普通はそうやって使うんだよ。マージも一緒。
ブランチが軽量で好きなだけ切れるので情報残したい数だけブランチを切ればいいだけだよ
rebase --keep-base みたいな使い方もあるけど基本が理解できてないやつは混乱するだけだろうな

>>118
× mergeが主な仕事ならgit使うべき。
○ mergeを使う可能性があるならgitを使うべき

長文君ソフト(仮)ではmergeのことを考えてないんだから

すでに書かれてるけど他のスレに行ってくれ
仕様の検討も含めてそっちでやればいいんだから

>>117
ああその失敗情報は有り難い。
ただ、そこは理論的に問題ない。

技術的には、Gitでもカレントを「上書き」するのだからコピーと同じだけのI/Oが必要であり、
I/Oバウンドの場合、GitでもSubversionでもその部分の処理時間は同じになる。
(Gitのbranch切換とSubversionのブランチ作成が同じI/O負荷）
そこで速度差が出るのだから、実際は、86で既に言ったとおり、Subversionが各ソースを「展開」するのが遅くて、
それはおそらく順方向履歴しか持ってないからだ。
(逆方向履歴持ってれば、commitは早くならないかもしれないが、branch切り出しはコピーと同速に出来る）

ここら辺はSubversionの基本アーキが腐ってるからだが、
この点GitBucketは中身Gitだから、コピーするだけで、結果的には本家Git（上書きするだけ）と同速だよ。

そのコピーが重い？
だったらbranch切換セレクタだけは付けるから、それで勝手に自前で管理しろ。
バックアップツールとしては、branchはパスが伸びただけの意味しかないからそうする、というのは112の通り。

コピーオンライトのファイルシステム、つまりハードリンクにする手もあるけど、これはユーザーが付いて来れないだろ。
ならコピー時間待たせた方がいい。

>>119
> rebase する前に新しいブランチ切ってやれば
そこはbranchではなくてタグだとは思うが、要はそれ、gcされないようにポインタ残してるだけだろ。
しかし開発しなくなったbranchは刈り取れ、というのが一般の使い方だろ。（それが推奨されてるように見える）

そもそもgcされないようにxxする、というのが間違ってるんだよ。
そんなところまでユーザーが密結合すべきではない。
普通にオススメ通りやったら、探せば何処かに履歴はあるよ、程度じゃないと。

まあ--keep-baseについては見てみるよ。
Bookの方が断然良かったのでman の方読むの止めてたから、知らなかった。

>>121
お前、作成の負荷と切り替えの負荷の区別ついてないだろ
実用上で問題になるのは作成の負荷、切り替えはディレクトリ方式の方が軽いけどそこは重要じゃない

>>122
必要なものには後で探せるように名前をつけておく。
名前のないものはいらないものなので掃除の時に捨てる。
基本中の基本すら理解できないの？

Subversion のブランチ作成がファイル数やサイズで重くなるとか・・・
てきとうなこと言うやつが二人になってカオス。二人とも早く別スレに行くか黙るかしてくれ。

GitBucket をdisってんのかと思った。
その名前はもう使われてるから変えろバカ。

>>120
多分な、開発現場において「ファイル内の」mergeが日常ってのはあまりないと思うぞ。
それは各自が勝手にどのファイルをどういじってもいい、ということだから。

gitによって開発フローが変わった！ってのがこの辺かもしれんが、
普通は担当を振り分けて、結果的に
「この期間にこのファイルを触るのは○○だけ」
と交通整理される。
同時に変更する必要があれば、同じ奴に同時にやらせるだけ。（注文が増えるだけ)
そして各自が変更したファイルをかき集めて、くっつけて終わりだ。
お前らはこれもmergeと言ってる気がするが、
これは「更新日時が新しければ上書きする」だけの話で、手動でも楽勝だし、
プログラマはこれをmergeとは言わない。

プログラマが言う「ファイル内」のmergeが日常的に発生するかどうかはその部署のオペレーションによる。
(が、会社とか統制取れる場所でこれをする意味はないから、OSS以外ではほぼないと思うが）

>>126
了解。考え直すよ。一度位ググるべきだったわ。

>>125
お前的には svn copy だけがブランチの作成で svn checkout は不要という主張したいの？
svn 的には checkout までが作成で、ブランチの切り替えは cd じゃないか。
オフトピなので svn の思想の話を続ける気はないけど、気になった。

>>127
結局これだろ

mergeを使う可能性があるなら長文君ソフトでなくgitを使うべき

gitのスレなのにmergeの意味が違うとか言い出すし…

>>130
つまりお前らGit屋の要求仕様は、

ファイル内のmerge：要らん
ディレクトリ内のmerge(=新しい方を取るだけ）：要る

ってのか？これなら手動でやった方が楽だよ。
普通にゴミ箱＝エクスプローラ的GUIになんだから、日付でソートして纏めて選択して持ってくだけ。
いちいち「オレオレアプリ的merge」とか用意するから余計混乱する。
使い慣れたエクスプローラで苦も無く出来るのだから、それで十分なんだよ。

>>131
訳のわからないこと言ってないで、とっとと長文君ソフト(仮)スレ立てて移動しろ

>>131
そんな低レベルの話してるのはお前だけだぞ

>>127

> 普通は担当を振り分けて、結果的に
> 「この期間にこのファイルを触るのは○○だけ」
> と交通整理される。
いつの時代のこと言ってんの？待ちが発生すること自体問題とは考えないの？

> 同時に変更する必要があれば、同じ奴に同時にやらせるだけ。（注文が増えるだけ)
> そして各自が変更したファイルをかき集めて、くっつけて終わりだ。
> お前らはこれもmergeと言ってる気がするが、
> これは「更新日時が新しければ上書きする」だけの話で、手動でも楽勝だし、
> プログラマはこれをmergeとは言わない。
更新日時見てマージとか、複数の人が並行開発した場合を考えてないよね

>>132-133
最初に言っておくべきだったが、俺が作るアプリはお前らGit屋向けではないよ。

プログラマ、或いはクリエイター向けで、
Gitなんか勉強したくない、何でもいいからバックアップと履歴が取れてればいい、という人向けだ。
だから内部DBには都合がいい物を使うだけで、SQLiteもあり得るし、途中での変更もあり得る。

Git屋はGitを使うべきだよ。そもそもGitがGit屋向けフルチューンだし、
だからこそ文句言われてるわけだが、目的外使用なのだからLinusから見れば完全に筋違いだ。
なら、俺が「プログラマ/クリエイター向け」のツールを提供しよう、というだけ。

>>135
だから、このスレでやるな。
自分のスレ作って引き籠もれ。

>>134
それなら、お前にはフィットしないだろうし、お前の周りはGitを引き続き使えばいいだけ。

俺は127方式やもっと小規模(個人)レベルでの開発を想定したツールを提供するだけ。
目論見が外れてたら、思ったより売れなくて、俺の骨折り損なだけ。
これで何の問題もないだろ。

>>135>>137
長文君ソフト(仮)ではmergeのことを考えてないから
mergeを使う可能性があるなら長文君ソフト(仮)ではなくgitを使うべき

ってことだろ。なんなんだよGit屋って。
とっとと長文君ソフト(仮)スレ立てて移動しろ

>>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でいい)

>>138
プログラマ： 主にソースコードを書いてる連中
クリエイター： 例えば主にフォトショで絵を描いてる連中
Git屋： Gitを操作することが主な仕事(>>83内のGit用員)、ソースコードは書けないし、絵も描けない

まあ、こうやって素人考えをぶつけてみることでgitの良いところを再認識できるのであれば
まったくの無駄ではないのかもしれまい。

>>141
× Gitの良いところ
○ Gitと被るところ

バックアップツールで必須な

・更新されたファイルを保存しておく
・変更されてないファイルは改めては取得しない
・変更履歴も保持し、必要なら古いファイルも取り出せる
・可能なら定期的に圧縮する

をGitが持ってるから、目的外使用されてるだけだな。
まあ基本アーキがいいから目的外使用でも本来ツールと戦えるということではあるけど。
ただ変更を酷く許してないところは頂けない。ここは俺はぶち壊す予定。
(間違ったファイルをコミットして大騒ぎ、結局全部作り直し、みたいのを無くして、ファイルを普通に消せるようにする。
ハッシュがずれたところで、ツリーには関係ない)

Gitのバックエンドは出来がいいんだと思うよ。多分。（俺が問題に遭遇してないだけかもだが）
Gitが糞なのは、フロントエンドと、仕様だね。ドキュメントは多すぎるが、よく書かれているし、少ないよりは断然いい。

どうでもいいが95%はコード書いて検証してる時間で、複数人でレビューしながら開発とかでない限りGitに使う時間って5%くらいだろ。
皆プログラム書きつつGit触れて普通だと思うんだけど。それこそWeb業界では。難しいことになるときがないとは言わないけどたまーにでしょ。
グラフィックの感性で勝負とか、そういう特殊な世界のプログラマー以外でWeb系でGitも使えないんじゃ普通仕事にならないけどな。

>>142
git はバックアップツールじゃないぞ。
料理に例えるならお前が欲しがってるのは出来た料理を保管するための冷凍庫。
git が提供してるのは料理を作ったりアレンジするためのレシピ本(とその編集機能)
あとお前の言う「プログラマ」って、単なるコーダーで、本物のプログラマじゃないだろ。工場で刺し身にタンポポ載せてるやつは料理研究家じゃないからな間違えんなよ。

>>140
長文君はgitをバックアップツールとしか見てないのに、Git屋というそのためだけの要員を
わざわざ雇っている会社があるという妄想に取り憑かれているんだな

>>143
いや5%(=24分)も十分多すぎだけどな。
まあそれはさておき、コードと開発体制も糞だったのを忘れてたから、

Gitの良い所： 基本アーキ、バックエンド、ドキュメント
Gitの糞な所： フロントエンド、仕様、コード、開発体制、(ドキュメント多すぎ)

となる。ここで、駄目なところは全部マネジメントに起因してる。
一般の会社なら課長/係長クラスで締める部分が締まってない。
これは指揮系統を持たない「バザール」の宿命で、他知らんけどこんなもんなのかもしれないが、
OSSという意味ではchromeとかもっとガッツリやってる（ように見える）し、少なくともregressionテストは流しまくってる。
あっちはGoogleが締めてるのかもしれないが、Gitは見た目1本もregressionテスト流してないのは駄目だろ。
Subversion(58内記事)ではregressionテストに落ちたらcommit禁止だったらしいし。これが普通。
CVSはこの辺ガッツリやりすぎて、テスト用の3万行超のシェルスクリプトに
(自分がcommitする部分の為の)新規テストを追加しなければcommitしちゃ駄目、とかで問題だったとも書いてあったが。


>>144
料理の味で勝負をしたいのに、冷蔵庫の使い方を100時間かけて勉強して、
冷蔵庫のご機嫌を取らないといけない事に、みんな文句言ってるんだよ。

ただこれはテクノロジーが達してないだけではある。
昔は航空機関士が同乗してたように。（乗ってて何とかなったとはとても思えないが、それはそれ)
今はGit屋が必要なレベルで、じきにもっと簡単な物が出てきてお役ご免になるはず。
出てこないようなら俺が作るよ、ということ。

>>146
だから料理の「レシピ本の作り方」をどんなに読み込んでも冷凍庫の使い方は載ってないぞ。少しなら冷凍庫の使い方のヒントになる部分もあるので勘違いしてるんだろうけど。
冷凍庫欲しかったた冷凍庫買え。レシピ本に冷蔵庫の代わりを求めるな。

>>146
俺が作ると言うだけなら簡単だ
スレ立ててそっちに移ることすらできない奴でも
俺が作ると言うことはできる

うちの会社にも取引先にもgit使えないプログラマーなんていないけど
git屋わざわざ雇ってる会社のプログラマーてアホばっかりなん

>>147
料理人： 冷蔵庫なんてブッ込んでおけば冷える、で十分
Git： 正しいブッ込み方じゃないから直せ、いやそもそもブッ込み方を知らない奴が使うな！と文句を言う冷蔵庫

>>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単位での同期で十分だったはず。

>>150
git: レシピを他の人と共有したりアレンジ料理のアイディア出しに使うツール。
そもそも冷凍庫が欲しい人はお呼びじゃない。どっか行け

>>151
既知も大騒ぎもない。最初からだよ。
理由が分からない時点でおっさし案件

>>114
> ただ、切り替わらなくてもいい共通ファイル類はその場合には .git 階層に置くんだよ。

複雑な仕組みを入れるな。
gitは、gitを使わない場合と全く同じ形のディレクトリ構造に保たれている
バージョン管理をしない通常の開発フェーズでは、gitを使わないのと全く同じ

お前が言うやり方では、gitのためにディレクト構造を作らないといけなくなる
あ～ほらし

まあね、この程度なんだよ

>>154
> gitのためにディレクト構造を作らないといけなくなる
ここら辺がGit信者が勘違いしまくってる点だよ。
これは

× Gitの為に
○ branchの為に

であって、ツールを『何も使わずに』branchを用意する場合の構造と同じなんだ。
本来ツールは「使えば便利」で十分なんだよ。
例えば何度も言われてる「電動ドリル」なら、

ユーザーが求めていたもの： 手動ドリルだと手が疲れるので、
　手が疲れないだけで、使い勝手や小回りの良さは手動ドリルと同じ程度の電動ドリル

であって、

Git： 世界中どんな物にも穴が開けられる据え付け型超高性能電動ドリル、
　ただし取り扱い要注意なので1000ページの説明書を読め、

なんて要らないんだよ。可能であれば、それ以前のユーザーがやっていた方式と
出来るだけシームレスに接続出来た方がいい。
だからこの点は、Subversionの方が仕様として正しい。
上書き切換方式がよければ、Opt-inにすべき。

ただ高級機は必要ではあるので、ここら辺はGitが悪いと言うよりは、
普及機がないからそのまま高級機を使ってて愚痴ってる奴が悪い。
だから俺が普及機を用意してやる、ということ。

> であって、ツールを『何も使わずに』branchを用意する場合の構造と同じなんだ。
> 本来ツールは「使えば便利」で十分なんだよ。

その発想が根本的に間違っている
本来ツールは「なければ不便過ぎて苦痛」だから作られた

× ユーザーが求めていたもの： 手動ドリルだと手が疲れるので、
　手が疲れないだけで、使い勝手や小回りの良さは手動ドリルと同じ程度の電動ドリル

○ ユーザーが求めていたもの： 手動ドリルだと作業が面倒すぎて時間がかかり過ぎで
　現実時間で解決することができない。人間には不可能な問題を解決するためものが電動ドリル

Git： 短時間で遠くまで移動できる自動車
　ただし取り扱い要注意なので免許を取れ

force pushでもされない限り復旧不能なリポジトリ破壊なんてされないけどな
サーバー側でforce禁止にすればいいし

まあとにかくだ、基本思想が違ってて、俺は「簡単は正義」だから、

Git： 使いこなせない馬鹿が悪い
俺： 難しい物を作る馬鹿が悪い

で、平行線なんだよ。
ただお前らからは普及機は出てこないのは分かったから、俺が作るよ。
（もっと調査してからだが）
俺は、難しくなる妥当な理由があるのなら仕方ないが、そうでなければ簡単にしろ、で
ジョブスの「ボタンは一個にしろ！！！」は肯定派。(Apple使う気ないけどさ)

つかよ、Gitの勉強じゃなくて、お前らコードの勉強しろよ、だからな。
あのパッチの顛末、マジで酷いぞ。C読める奴が居たら本当に聞いてみ。
Git等のツールは、最終的にはソフトウェアのコードの品質を上げる為であって、
Gitに習熟したけど糞コードしか書けません、では完全に本末転倒だ。

>>160
俺が作ると言うだけなら簡単
実際に作って公開しなければ口だけ番長と思われてお終い

>>161
いや101の仕様で手こずると思ってるお前もかなりヤバいけどな。
これも周りにプログラマが居たら聞いてみ。

ただ、自分で使う用に動けばいい物と、他人が(デタラメに)使う用に作るのはだいぶ違うんだ。
だからきちんと状況確認して仕様はしっかり詰めるべきなんだよ。
Gitにはこの辺の感覚がない。
まあLinusが個人的に必要だから作った、完全特定個人向けチューニングだからではあるが。
この辺がGit(を使わされる側)の不幸なところだよ。

>>160
> Git： 使いこなせない馬鹿が悪い
> 俺： 難しい物を作る馬鹿が悪い

でも、難しいと思ってるはお前だけなんだ

お前が馬鹿というだけじゃね？
それとも完全自動運転車が登場するまで
ずっと無能呼ばわりされたいということかね？

>>163
流石にそれは言い過ぎ。
git は難しいよ。
環境の準備やチーム内のルールも知らないと仕事始められないので。

>環境の準備やチーム内のルールも知らないと仕事始められないので。

その点に関してはsubversionの方が難しい気がする。

>>163
いや結局>>137なんだよ。
お互いの見解は異なるし、同意する必要もない。ただフォークすればいい。

俺は売れそうだと思ったら作るだけ、欲しい奴は乗っかればいいだけ、要らない奴は使わなければいいだけ。
俺は(というよりプログラマ全般は）ツールだけ使えてコード書けない奴は死ねばいいとしか思ってないから、方向性もいい。
俺の目論見が外れればお前らの勝ち、お前らが食うのに困れば俺の勝ち、勝敗はフォークで、だ。
俺が想定してるのが時代遅れで馬鹿だらけの現場なのか、お前らが壮大に勘違いしてたのかも、それで分かるよ。

ただ当たり前だがこのスレはGitを理解してるか、最低限理解しようとしてる連中の場所であって、
俺が相手にしようとしてる、理解する気もない連中の溜まり場ではないから、
壮絶アウェイになって然るべきで、散発でも賛同者や擁護が出てくる時点でヤバイと気づける位の方がいいと思うが。


スレは立てるが、肝心のアプリ名を今考え直してるところだから、来週まで待ってくれ。
GitBucket気に入ってたのにちくしょ～。

難しいなら入門書熟読すればいいし、わからないなら素直に聞けばいいんだよ
それすらやらず、ドキュメント読みたくないとか自分の思想に合わないからgitはクソだとか、小学生並みのわがまま言ってるから無能と言われる

>>166
git は馬鹿に売るために作った製品じゃないのでフールプルーフじゃないんだぜ。無料のオープンソースだからな。
作った人自身が使い易くて余計な時間を消費しないのが最優先。
文句あったらこれより良い製品をオープンソースで公開してみろ。ソース読んで良ければ尊敬するかもしれない。

この手のツールは機能や使い勝手の多少の違いよりも信頼性や将来性が重要なものだからな。
コミュニティの立ち上げどころか協力者を一人集めることすら難しそうなこの人が何を夢見ているんだろうか。

長文君や長文君が利用者と考える馬鹿ユーザーは、信頼できるチームでメンテナンスが継続的なされるかとか、ツールに透明性があるかとか一切気にしないのかもしれない。

沢山語る事かある人達楽しそうだな。
VCS はエディタの補助機能で世代交代する事もあるけど、なんとなく使えてたらOK! って思ってた。

>>162
作ると言ってるだけで作らず、皆が興味をなくすのを待つと思っている
ここで偉そうにするだけならそれで十分だからな

本当に作ると言うなら進捗状況を週に一度くらい公表すればいい
そのためにスレを立ててトリップを付けてでもいいしツイッターとかでもいい
実際にプログラムを書きはじめたらそれもどこかで公開する
進捗状況が分かるようにな
来年3月末目標ということで >>101

どうせやるならgithubにあげて欲しいものだ

git にフォークなんて無いんだが。
git のあいうえおも分からないやつが
git の批判してても何も響かないんだよ。
いい加減去って欲しいわ。

これのソフト？は内容は世界中の人と共有されるの？分散型ってどういうこと？

考えてみたが、やっぱGitは根本的に思想が俺とは違うんだな。
俺はツールはあくまでアプリの品質を上げる手段だと思ってる。
ここまではおそらく共通なのだが、問題はこの先で、俺は重要な順に、

A. アプリそのものの品質。つまり必要な機能に深刻なバグがないこと。コードの品質がこれに直結する。(コードが本体)
B. 使いやすさ。簡単は正義。使えない機能は存在してないのと同じ。直感的に使えればドキュメントすら必要ない。
C. 持続性。つまり自分が使いたい期間(未来)中ずっと使えるか。

なんだが、Git陣営は全く逆でC>>B>>Aの順に見える。
それはこのスレ内でも散見され、俺は釣りだと思っていたが、マジっぽい。つまり、

C. コミュニティに人を集めれば自然と持続性は確保出来る。つまり人数が一番重要。これを取り持つのがツール(ツールやcommitメッセージが本体)
B. ドキュメントを整備しまくれば、後はがんばって読めばいいだけ。
A. コードの品質なんて後から付いてくる。バグも誰かが勝手に直してくれる。

Git陣営はマジでコードの品質を上げる努力を何一つしてない。具体的には、

・regressionテストを1本も流してない。
・レビューも全くしてない。(マジで、見た瞬間落とされるコードを素通し)
・CodeOfCoductは重要だが、CodingRuleは要らない。

CodeOfConductは最近のポリコレで生まれた、「人の」振る舞いを規定するものだ。
これに対してCodingRuleは「コードの」振る舞いを規定するもので、
CodingRuleなしでCodeOfConductだけってのは、コードはどうでもいい、問題は人だ！と言ってるわけだ。
『人さえいれば、全て何とかなるんだ！』という思想だ。

ただ俺からすると、見る限り完全に「善意のただ乗り」であって、
少なくともコードの品質を上げる努力してないと協力する気にならないよ。
(ITがいくら自動化しても、最終的には人なのは事実としても、コードの質を直接的に改善する努力を全くしないのは不味いだろ)

俺はコードの品質/アプリの仕様そのものが一番重要で、それさえあれば全てが上手く行く、と思ってる。つまり、
仕様が簡単で直感的なら、ドキュメントを整備するまでもないし、
バグがなければ、後は「十分動く」程度のメンテで済む。だから最初から出来る限り品質の高いアプリを投入すべきだ。
ここら辺は「伽藍」では共通認識のはず。『コード/仕様さえよければ、全て何とかなるんだ！』的な思想だ。

ただここら辺を「バザール」でひっくり返したから話題になったわけだが、やっぱこれは違うよな～とは思うよ。
これって「善意のただ乗り」の仕方が世界一上手かっただけで、みんながこれをやり出したら回らないよ。

>>176
> 考えてみたが、やっぱGitは根本的に思想が俺とは違うんだな。

思想じゃなくて、お前が単純にバージョン管理というものを知らんだけやで
自分が無知であることを知るのが成長の第一歩や

> 俺はコードの品質/アプリの仕様そのものが一番重要で、それさえあれば全てが上手く行く、と思ってる。

うん。やっぱり間違ってるね。
そんなんだから、POSIX原理主義者みたいに、一行書いてデバッグしていれば
バグなんか入らない！とかあり得ない主張をすることになるんだよ。

>>177
伽藍とバザールの話を知っているのであれば、
伽藍方式は間違っていたっていう結論だって知ってるよね？

>>179,180
(内容が違うが答えは同じで)
いやあれはそういう意味ではない。どう読むかも自由ではあるが。


ただやっぱり、ここら辺はフォークで決着すべきで、それが正しいんだよ。
各自が思う方向に、突っ走ってみればいい。
アプリの品質も、最終的にはユーザー数*満足度の総和だから、Gitのやり方が間違ってる訳でもないんだろうさ。
でも俺は違うと思うから、違う方向を試す。

>>176>>177
御託はいいから長文君ソフト(仮)作りにさっさと取りかかれ >>172
御託を並べるのは長文君ソフト(仮)を完成させ、それがgitよりも
使われるソフトになってからにしろ

gitを作っている人たちを皆が望んでいる物を知らないクソと罵っていたんだから
皆が望んでいるソフトを長文君が作れなければ長文君は皆に笑われる
さんざん偉そうなことを言っておきながらその程度かってね

気に入らないなら自分で作ればいいだけの話
gitも元はそういう思想から生まれているんだし
それが出来なくて文句言うだけなのは恥ずかしい

gi自体tの開発の流れってLinuxカーネル開発とほぼ変わらないと思ってるけど違うのかな
1回もレビュー通してないとかいい加減なこと言う人がいるので気になった

>>184
全通しならレビューの意味がない。よく分からん所でなあなあでウェットなんだよ。

例えば>>58の中盤以降、「どうやってOSSを飼い慣らすか」になっててすさまじく気持ち悪い。
これはタイトル「オープンソースソフトウェアの育て方」からしてそうではあるけども。
しかも書いた奴がCVSにも相当関わってて、Subversionも率いてた奴だってのがかなりキテる。
そして同様の雰囲気をGitからも感じる。

俺は「自分が使ってるツールにバグがあるのは自分も困るので、協力したい」とか、
「自分もそれが欲しいから」という、
個人の利益の追求の方向が偶々揃った程度で連携すべきで、それで十分だと思ってるんだよ。
だから「売れそうなら作るし、欲しければ乗ればいいし、要らないなら無視でいい」になる。(166)
勿論解消も各自の自由で、売れなさそうなら作らないし、ゴミなら使わない、でいい。
極めてドライな連携だ。
そして一般的に匿名掲示板はこの程度だから、俺は気に入ってる。

対して上記本やGit、いかにcontributerを手なずけてコードをタダで貰うか、みたいになってて、本当に気持ち悪い。
それがLinusが世界一上手かったことではあるし、それが成立するという驚きが「伽藍とバザール」だけども。
>>95の内容も若干キモイ。
Linusの個人崇拝になってて、Linus自身はそれにちょっと困ってる、ってのは分かる気がするよ。

コードはコードの内容だけで評価するべきで、
誰が送ってきたとか、これまで彼がどれほど貢献したとか、そういうの、勘案すべきではない。
落とすべきコードはドライに落とすべき。
CodeOfConductでポリコレ宣言せずとも、こんな事はみんな普通にやってきたことだよ。

が、まあ何か思惑はあるのだろうよ。
究極のコードクレクレ君を見せてやるぜ！！！と言われてる状態なので、とりあえず見物だ。

世間一般のgitユーザーって Sourcetree 使ってるんかな。
わかばちゃん、サルでもわかる、おもしろいほどわかる、あたりは GUI の使い方書いているみたいだし。
コマンドライン使う説明の本は中級に分類されてそう。

Linux で使っているので Win/Mac に Sourcetree 導入しようとも思わないけど。

>>186
vscode + GitLens + Git Graph おすすめ
Linux/Win/Mac 同じように使える

>>187
ありがとう。
git は VSCode のサポートツールにしか見えないね。

>>185
長文君の「ただ乗り」批判
長文君ソフト(仮)はその「気持ち悪い」やりかたで作られたgitにただ乗りするんだろ

>>176
無学な長文君らしい発言だなあ。
理解は経験に裏付けられている必要がある。俺には非常に直感的で分かり易い仕様だよ。
他人のソース(自分の過去のソースとかでも良いけど)を頻繁に読まないやつにはとっつき難いんだろうけど。
共同開発の初心者が git 難しいというのは分かる。でも彼らは自分の共同開発の経験が足りないことを理解している。
長文君は自分の経験が足りないことを棚上げして共同開発を全否定することに全力を傾けてる。伽藍とバザールとかいつの時代の話だ、2周くらい周回遅れ。

他人(や過去の自分)と共同開発しないやつに git はいらないよ。そのための専用ツールだからな。

>>190
俺の価値観からすると、ツール使えるだけで、
肝心の、あのソースコードと開発体制と仕様のヤバさに気づけないのは、本末転倒だと思うけどな。

まあ平行線だからいいよ。決着はforkで、だ。
俺が作るツールは、君ら向けではないし、実際君らには無価値だよ。
そもそもGitを使ってるだけで、Gitを使う為のアプリではないからね。
(これが誤解の元だったから、Gitと冠するのは止めようかと思案中)
だから第一弾で君らが死ぬことはない。
Gitを殺せるとしたら第二弾以降だが、まあ、これも無理だろうよ。これが目的でもないし。
むしろ、Gitを目的外使用してる連中を引き受けるので、お前らは居心地がよくなるかもしれん。
Gitはmerge専用機としてはよく出来てるよ。
しかし一般開発には、通常commit(親が一つのcommit)の方が断然多くて、今使ってる連中の大半もそうだと俺は思うけど。


それはさておき、多分Gitや他気持ち悪い系OSSが維持出来てるのは、
初音ミクの時に言われた、「ヘタウマ」じゃないかと。
日清カップヌードルでも言われてるが、要は「チョイ足し」したくなる絶妙な「ヘタウマ」ならソースコードも集まりやすい。
Linusが書いた完全無欠のコードでは、誰も手が出せないからね。
だからソースコードがある程度ゴミなのは、成功してるOSSの宿命なのかもしれん。
界隈よく知らないけど、例の鳥の詩(国歌)、完成してる感があって2次が少ない(ほぼ無い)と聞くし。

まるで「描かないマンガ家」

>>191
無能は口を閉じろ

Gitと競ってたDVCSは他にもいくつもあったが全部消えた

>>191
その「気持ち悪い」開発方法でしっかりしたソフトが開発できてるから
それをベースにするってことだろ
gitその他の開発方法にケチつけるならそれで開発されたものをベースにするなよ

始めてもいないうちから「第二弾」とかバカ過ぎる
大口叩いてないでさっさと作れ
検討したことや結果を公表する場所を決めて発表するくらいはすぐできるだろ
>>172 >>182

最強のバージョン管理ツールを
伽藍方式で今考えてるからちょっと待て
最初から完璧な設計でバグもまったくない
100年ぐらいかかる予定だ

>>195
> その「気持ち悪い」開発方法でしっかりしたソフトが開発できてるから
> それをベースにするってことだろ
違うぞ。既に書いたが>>118,142
というかね、俺はその辺お前らGit勢とは違ってポリコレはしない。
コードに政治は持ち込まない。使えれば使う、程度だ。

SQLiteだとGitの再開発が必要になるのが無駄だ。SVNの方が良ければ乗り換えるかもだが。
(というかバケツ的使用感をSVNが提供してたらそれで終わり、俺がアプリ作るまでもない。
これって今無いのか？
逆にSVNもGitと同様政治的で、バケツなんて提供してヤラネ、学習して使え！
なら俺がバケツアプリSVN版も売れそうなら作るかもだが)

>>197
俺もお前が書いたものが使えれば使う
使えないから、使ってない。
で、いつになったら使えるようになるの？
使えないなお前

>>198
>>101,102

>>196
彼が作ろうとしてるのは、バージョン管理ツールですらないから(多分わかっていて言ってると思うけど)…
まあバケツ方式でstashしていくやり方でどうやってバージョン順序保証していくか見ものだね

以前彼が言ったように更新日時でとか回答するのであれば失笑ものだがw

本屋でわかばちゃんを少し読んだけど、おじさんが読む本ではなかった。

>>200
> バージョン管理ツールですらない
Git屋からみればその通りだが、一般人にはこれで十分だ。

というかこの辺も既に書きまくってるが、
普及型で、>>155の様に、これまで手動でやってきた人が使用感そのままでただ楽が出来る程度を目指す。
(だから学習時間ゼロで済む。一番確実なのは既に知ってるGUI=ゴミ箱に合わせること。
意識高い系には馬鹿にされるだろうが、いいんだよこれで）

stashはしない。commitだけだ。
というか、実体はほぼビュワーだから、俺みたいに簡単を正義とするなら既にあるはずなので、妙だなあとは思ってる。
いずれにしてもWindows版のGUIは全部確認しないといけない。これにも時間がかかる。
今のところGitGUIとgitkは違う。tortoiseは、多分違う。
他はまあ、1～2月中位には全部見るかも、程度。
実装着手出来るとしたら3月だから、それまでに、程度で。勿論仕様も練らないといけないし。
でも、これもただの予定であって、予定通り行くかは分からんし、それ以前に売れそうにもなければ作らんし。


まあとにかく、根本的にアプリに対する思想が違うんだよ。
だから君達にはイメージ出来ない。
でも、ゴミ箱で管理する！と聞いて、ああなるほど、と思った人には、納得の出来だろうよ。
どっちが正しいかはforkで勝負だ。

次のカキコはβ版が出たらにしてね

>>201
それ、前にも少し気になったのだけど、
Git屋はまだ本が主流なのかい？

Web系だと本ではどうにもならないから、ここで初心者が「いい本はありませんか」と聞いてきても
「本なんて全部ゴミ。MDN読め」と返すし、同じノリの奴も多い気がするが。
俺自身、もう本屋に何年も行ってない、に近い。

だからサル先生とか馬鹿にしてるのも、よく分からない。
紙かWebかなんて、どっちに書くかでしかないだろ。
紙媒体なら信用出来るなんて時代はとうに過ぎてる。
そもそも紙媒体の編集者はその選別眼を持ってない。
お前らがあれが糞コードだと理解出来ないように、本職以外の奴が本職の専門家向けに情報を選別するのは無理なんだ。
そして連中はただの印刷業だから、ある意味売れそうなら印刷するだけなんだよ。
だから本当に酷い内容でも本になってたりする。
ただ問題は、初心者にはそれが酷いとは分からないんだよ。

だから俺は適当にググって評判が良さそうなところを読むだけ。
Gitの場合は確かにBook読めではあるが、別にサル先生を馬鹿にする必要はあるまい。

>>197
>どこまで使えるか判断して、その範囲は使う

わざわざそんなことをしてでも使いたいくらい
gitのコードはしっかりしているということだろ
「気持ち悪い」とか何とか言っててもそんなもんだ

>>205

205： 連中がキモイとか言うなら、そいつらが作ったコードも使うべきではない
俺： コードにポリコレは持ち込まない。誰が(キモイ連中)が作ったかは関係なく、そのコードが正しく動く範囲なら使う。

お前らポリコレ過ぎる。コードはコード、作成者がキモかろうが関係ない。
というか、まあ、キモイとか言うなら使うな！というのがCodeOfConductだから、
205の姿勢はGit的には正しいのかもしれんが、とにかく俺はそうじゃない。
(この点も俺はGit勢には馴染まないから、やっぱ遠巻きに見守るべきだな。変に突っ込んでたら大騒ぎだったかもしれん)

しかしこの勢いだと、GPLv4にはポリコレが入って、「キモイとか言う奴には使わせない」とかになりそうだな。
笑えねえ。

>>204
gitについて書かれた本を本屋で見た人がいるというだけなのに

>Git屋はまだ本が主流なのかい？

と言い出す長文君
何を参考にするかは人それぞれだろ、普通に考えて。

>俺は適当にググって評判が良さそうなところを読む

適当にググって評判が良さそうな本を買って読む人もいるだろうな

>>207
いや本に噛みつかれないのがWeb系界隈とは明らかに違う。

>>204
1000ページも読みたくない～とか意味わからんわがまま言って読むの放棄してる奴が何言ってんだかw

> 「本なんて全部ゴミ。MDN読め」と返すし、同じノリの奴も多い気がするが。
> 俺自身、もう本屋に何年も行ってない、に近い。
じゃあ自分もこのノリで
「本なんて全部ゴミ。git-scm読め」

>>205
ちなみに技術的な話をすると、
> gitのコードはしっかりしているということだろ
これは根本的に違ってて、要するに俺が楽したいだけなんだよ。

内部DBを外部ソフトに委ねるのは、最大の目的は、そのソフトのツール群を使えるようにする為。
最悪ユーザー側で何とでもなるというのは、ユーザーにも安心で、これは重要なんだよ。(POSIX君はこの点を問題視してるわけ）
そして外部ソフト自体がバグってても勝手に直してもらえる。
寄っかかることに抵抗がなければ、寄っかかった方がユーザーにも制作側にもメリットがあるんだよ。
(勿論囲い込みは出来なくなるが、最初からそんなのする気ないし）

デメリットは、その外部ソフトのバグもユーザーには俺のバグにに見えるから、俺がバグ対応窓口にさせられる可能性があること。
俺のバグなら致し方ないが、外部ソフトのバグなんて対応してられない。だから安心出来る範囲でしか使わない、ということ。
要は全部楽する為の方策であって、お前らみたいにポリコレまみれではないんだよ。

>>206
ベースにしたくなるくらいしっかりしたソフトが開発された方法に
ケチつけるなって話だがな

>>211
寄りかかれば楽ができるくらいgitはしっかりしてるってことだろ

長文君はフォークフォークと言ってるだけで実際に何かを始めたわけではない >>195

Google driveに上書きしてくのじゃあかんの？

>>212
それはベースにしてるわけではないんだよ。（つか俺がそう言ったっけ？なら訂正だが)

多分OOPの基本すら理解してない君達には通じないが、繰り返すと、
そこは即交換可能なんだよ。
少なくともGitとSVNはほぼ自動的にそうなる。（一般的に普通に組めば自然とそうなる）
SQLiteだとGitやSVNに入っているコードまで自前で書く必要があるから面倒だが。(だからこれはやる気なし)

ベースではなく、外注なんだよ。必要とあればすぐ交換可能だ。

つっても、通じないだろうけどさ。

Git（MSのDevops）にゼロからプルしたらフォルダが40バイトのファイルになったんだが仕様かね

>>213
詳細仕様分からんが、割とマジでクラウドならデフォで入ってる程度かもな。
なるほど。

Git の本は、利用者の裾野が広いせいでバカ向けに書いた本が出回るようになっているのか。
昔だと、教わらなくても Windows95 使えるけど、教えても使えない人の為の本が沢山出ていたのと同じ。
良いことじゃないだろうか。

>>214
「外注」したものをベースにしてるってだけだろ
「すぐ交換可能」なら最初からgitをベースにせずに他のを使えばいいだけなのにできないんだから

昨日のことなのに忘れてるし

>>101
>Gitをゴミ箱/バケツ化するラッパ(フロントエンドのみ。バックエンドはGitで、Gitは別インストール必須)

>>199でアンカ貼ってたけど、読んでなかったのか読んだけど2時間ほどで忘れてしまったのか

>>218
ベースとは言ってないだろ。
フロントエンド/バックエンドとは言ってるが。
それらはまるで意味が違う。
（というのも通じないからもう終わりにするが）

ちなSVNで最初から組むことも問題なく可能だよ。それがOOPでもあるし。
ただSVN確認するのが面倒なので、とりあえずGitで行くってだけで。
(SVNみたいな集中型は鯖立てが必要な可能性があるのでとりあえず敬遠《未調査》)

よく分からんけど、もしGitがお前の持ち物なら、ライセンス変更すればいいんじゃね？
お前の持ち物でもないのに文句言ってるんだったら、お前だいぶ狂ってるよ。
俺からみたら、Gitのコードが糞なのも、Git陣営の動きがキモイのも、事実だよ。
そういう俺が狂ってる、とお前が思うのも自由だが、コードについては第三者に判断可能だから、
お前の周りでCを「きちんと」書ける奴が居たら、今回の顛末見てもらえ、と何度も言ってる。

>>219
お前のいうきちんと書かれたCのコードって例えばどれよ？ お前の妄想内にしかないんじゃね？

>>219
持ち物ではないけど、自分が普段使ってるものに馬鹿だのクソだのいちゃもん言われたら文句言うの当たり前だろうがw

どうでもいいが、バックアップ取りたいだけならrsnapshotとかあるけど知らないのかな

>>219
gitがなければ機能しないものを作るってことなんだからgitがベースってことだろ
糞と思うなら使わなければいいだけ
長文君ソフト(仮)のベースとして役に立つと思っているから使うんだろ

長文君は実際に何かを始めたわけではないけどな >>195

OOPでGitとSubversionを問題なく交換可能かは、それこそ実際に結合テストしてから言ってほしいものだ。
Git開発陣営は少なくとも動くものを作っているけれど、
「OOPの原則に則れば交換可能でなければおかしい」なんてのは机上の空論でしかないし、せいぜい工学的仮説といったところだろう
作れてないんだから仮説の域を出ない。ちゃんと工学的に明らかにしてくれ。

>>220
クレクレ君死ね。

ただ、Cのいわゆる伝統的手法は本当にみんなやってるから、そこら辺のCで見あたるよ。
そもそも大概それがCの糞な所とされてるので、見たこと無い奴はほぼ居ないはず。

これも何度も言ってるでしょ。
俺はもうお前らのフォローはしないと宣言したでしょ。
直接的には教えてやらないよ。

でも本当に、Cを「きちんと」書ける人なら全員知ってるから、周りにいる人に聞いてみなよ。
実際問題として、仮に俺がここで丁寧に教えても、お前ら絶対信用しないだろ。
だから、君ら自身が信用出来る人に、直接聞くしかないんだよ。
つまりLinusがベストなんだけどさ。

或いは、これも既に書いたが、結局のところC++/C#/Rustでも同じ解だから、
これらの言語をきちんと勉強しても、同じ所に到達出来る。
だから自分だけで解決したいんなら、これらをやってみるんだね。
新しい言語は、古い言語の駄目なところを改善してるので、彼等がどこを問題視して、どう解決したかが、簡単に見えやすい。

LinusはC++を滅茶苦茶嫌ってて、まあその理由も分かるし、正直同意もするけども、
当たり前だがC++はCのベストプラクティス集みたいな所はあるので。(少なくともC++89/98は。その後明後日の方向に暴走中ではあるが》

あとそもそも最初に言ったが、今回は一番取り扱いが簡単なケースなんだよ。
こんなのでリークするのは、最初から構造がおかしいからだよ。
出来ないのなら、基本に忠実にやれ、でしかない。

ただ君らは構造を議論出来るレベルじゃない。まずはOOPの基本から勉強すべきだよ。

>>224
完全に、じゃなくて、そりゃグルーは書くんだよ。
(まあオブジェクト内側にブチ込んでしまえば見た目完全にはなるが)
ただ、俺がやろうとしてることはVCSが普通に持ってる機能(のはず)だから、
VCS自体は何であれ多少の変更で動作するはずなんだよ。

てかお前らには構造の話は通じないから、ここら辺でいいか？

大体、ゴミ箱アプリの中身がGitかSVNかなんて、交換可能に決まってるじゃん。
むしろなんでそれが無理だと思うのかが俺には分からん。

>>222
知らんが、要らん。
これなら手動でディレクトリごとzipしとく、の方がマシだ。

>>225
例えばgithubに上げられてるCで書かれてるソフトのうち、「きちんと」書かれていると
思うのをいくつか挙げて、それはgitと比べてどのように「きちんと」しているか説明することは
できないということで、「きちんと」したのは長文君の妄想内にしかないと思われてもしかたないな

>>226
そう思うのならgitの代わりに「コードが糞ではなく開発グループがキモくない」と思うのを使えばいいだけ

>>224
交換可能なはずがないんだよね
そもそもSVNとgitでリポジトリの概念が違うんだから

あとgitは実行速度を重視した実装になっているけど、彼の言うOOPが取り込まれたら実行速度がどれくらい落ちるか、個人的には非常に興味があるね

>>227
またろくに仕様を調べもしないでzipのほうがマシとか言って、傷口を広げるだけですよ

人格攻撃ではないのだが、40代ぐらい、正しいCやOOPは出来るほどの技術力は実際にはあるんだが、
人格に難がありすぎてビッグマウスで信用されずWeb業界でやっと拾ってもらえて、
だがGitが使えずWeb業界でも疎まれていて、鬱憤を晴らしにここにきてるのかな。
Gitを使いこなせないレベルのHTML/CSS屋とかならまあ求められてるものが違うからGitわかんないってのもわかるんだけど、
正しいCとかOOPとか言ってるのにGit使えないというのは、SIerしか考えられない不思議。

>>229
まあ単なる経験則になっちゃうしgit-svnの実装の問題だと言われたら
コードを読んでない自分は反論できないので書かなかったけど、git-svnでどれだけ皆無理だと悟ったか知らないんだろうね

>>226
Gitのコミットはリモートリポジトリだったとしても必ず作業ディレクトリの.gitディレクトリに行われる一方で、Subversionのコミットはリモートリポジトリにする必要があるのに？
どのVCSも同じ機能があると思ったら大間違いだよ。CVSなんかかなり絶望的だと思うぞ(すまんCVSは流石に太古の昔しか使ってないので嘘かも)

「バージョン管理ソフトを利用したゴミ箱アプリの開発」

ただしSubversionを使うときはサーバーが必要です。
ファイルを削除するたびにリモートにファイルを保存したりします。


ってことやろ？

>>225
長文君、どんどんボロが出るなあ
きんちとしたCのコードなんて基準も何もない妄想って認めてるんだね

>>233
SVN全く調べてない俺が勝手に想像してるのはその形態。
鯖立てなんて出来ません！な連中に対応するつもりだから、鯖立て必須は厳しい。


ただ、どうもこのスレの連中は、本当に全くプログラミング出来ないらしい。
>>101,102読めば、ああなるほどね、と並のプログラマならぱっと分かる。
あまりにもトンチンカンな話が多すぎる。マジでお前ら、死ねとしか思われてないぞそれは。

ただ、いずれにしてもキモイよ。少なくとも俺には。


俺が想像してた世界：
「はい、バグっぽい何か」「ああバグだね」「直しといたぜ、確認よろしく」「とりあえずこちらでは動いた」

俺が思う本来Gitがあるべき姿：
「そのバグパッチ作ってみました」
「う～ん、君のコードはこの点が問題だから、ここをこう直してくれないかな。そうすれば、もっといいコードになる」
「マジか、このOSSではLinusから直接、技術指導を受けられるのか。なるほど勉強になったぜ」
「次も書くぜ！Linusには悪いが、どんどん教えて貰う！！！」

GitやSubversion：
「はい、バグっぽい何か」
「あらいいプログラマね、お茶してかない？」
「いや俺が欲しいのはバグが無くなったソフトウェアであって、
お茶したいわけでもないし、そもそもお前らと仲良くなりたいわけでもないんだが」（＝「SNSでやれ」)


って書いてて思ったが、
SNS未発達時代のOSSはSNSも兼ねてて、こんなものなのかもしれん。
しかし今もそうなのはやはりキモイ。
完全にドライに技術的なら、CodeOfConduct(=ポリコレ宣言)なんてそもそも要らんし。

ただこれは俺が匿名文化に馴染んでるからであって、
一般人には実名SNS的対応の方が受けるのかもしれんし、まあご自由にどうぞ、ではある。
俺にはキモ過ぎて無理だな、ってだけで。

>俺はもうお前らのフォローはしないと宣言したでしょ。

わかったから他所でやれよ。有言実行。

ごっみばけっつの人はさっさと専用スレ作って移動しろよ
いつまでめーわくかけ続けるんだよ

長文さんってgit とgithubの区別ついてなさそう

>>211
>内部DBを外部ソフトに委ねるのは、最大の目的は、そのソフトのツール群を使えるようにする為。
>最悪ユーザー側で何とでもなるというのは、ユーザーにも安心で、これは重要なんだよ。
>そして外部ソフト自体がバグってても勝手に直してもらえる。

長文君が「糞と思っている」gitをベースにしようとするのは、
コードの品質/アプリの仕様そのものが一番重要で、それさえあれば全てが上手く行く >>177
というのは間違いと思っていて、gitがこうなっているから、ということだな

>C. コミュニティに人を集めれば自然と持続性は確保出来る。つまり人数が一番重要。
>これを取り持つのがツール(ツールやcommitメッセージが本体)
>B. ドキュメントを整備しまくれば、後はがんばって読めばいいだけ。
>A. コードの品質なんて後から付いてくる。バグも誰かが勝手に直してくれる。

長文君は実際に何かを始めたわけではないけどな >>195

>>236
さっさと長文君ソフト(仮)作りを始めて自分の理想のコミュニティを作ればいいのに
検討したことや結果を公表する場所を決めて発表することすらできずに
グダグダ言い続けるだけの長文君

fork して branch した後なら
いくらでも rebase して
push -f しまくってる

やっとここまで読んだ
GitPail がふさわしい名前だと思う

git って一部でもつけんじゃねー、って思う。
勘違い君に文句言いにこられても困る。

git rebase --ontoを今更ながら知ったが便利だなこれ
今までgit rebase -iした後色々こねくり回してたけど楽になった

>>246
長文「バックアップしたいだけなのにそんな難しい機能はいらねーよ！」

>>246
欲しいって思った機能って調べるとだいたいあるよね。

OSSがコミュニティ的なら、例の「コミュニティの一生」も当てはまってしまうと思うんだよな。
> https://dic.nicovideo.jp/a/%E3%82%B3%E3%83%9F%E3%83%A5%E3%83%8B%E3%83%86%E3%82%A3%E3%81%AE%E4%B8%80%E7%94%9F


【Gitの一生】

Linusが面白いことをする
↓
面白いから凡人が集まってくる >>95
↓
住み着いた凡人が居場所を守るために主張し始める
↓
Linusが見切りをつけて居なくなる
↓
残った凡人が面白くないことをする
↓
面白くないので皆居なくなる


>>176に書いたとおり、人数こそ力の源泉で、「人数の維持」が目的になってるように見える。
だけどそれは本来は手段で、「アプリの品質」を上げるのが目的でしょ。
(まあ賛同されるとは思ってないし、完全に平行線だが)

そもそもGitって今完全にメンテナンス状態？
つまり、本質的な新規機能要求(バックエンドに追加が必要)は無く、View(フロントエンド)をいじってる状態か？
ならまあ、実際面白くもないだろうよ。勿論メンテナはご苦労さんだが。
ああそういえばSHA256対応だっけ？あれは単なる作業だよ、本来は。チャレンジングではないから、面白くもない。
(つかこれがチャレンジングになっちゃうのはコードが糞だからだ。これも何度も説明したけどさ)

>>244
Pailは確かにいい。
ただ問題なのは、バケツは全員通じるが、ペール？？？な連中向け(俺含めて)のソフトだということだ。

チャレンジングなことしたことないやつほどそういう言葉使うよねぇ
エンジニアに妙な憧れ持ってそう

だから「バケツ(仮)」で新スレつくってそっち行け。git って付けなければ誰も文句は言わん。

rebaseって使う機会無いんだけどなぁ
以前、どこかの職場で履歴は一直線がいいとか意味不明な理由でrebaseさせられていた時があったわｗ
force pushするしかないし気味悪いｗ

本探してたら、わかばちゃんの旧版の書評に
https://honto.jp/ebook/pd-review_0628444763.html

>実は現場では、SourceTreeは重要でありながら、きちんと使える人は意外と少ない。
本来はこの手の専門家であるはずのプログラマーは、コマンドでGitを使うため、SourceTreeには縁がないからである。

知らなかった。

>>253
あるパッチの中にtypoしているのが後で見つかった場合どうするの？
そのパッチを他のブランチに適用する時困るでしょ

>>255
別にまた修正すればいいだけじゃね？
前のブランチに戻って修正するの？ｗ

>>256
ブランチが3つあったら
3回同じ修正しろって言ってるの？
ちょっと問題外すぎ

rebaseいらない。だって3回修正すればいい
だめだこりゃｗ

多分最新のコードを見ながら必要な部分を
目視でより分けて修正しろって言ってるんだろうな

うちは自分の作業中にもメインブランチがどんどん進むからローカルでrebaseしまくりだな

>>259
普通そうだよね
定期的にrebaseしてないとマージが面倒になるし

長文さん、あぼ～んしたいからコテ入れてくれ

rebase 使わないとか git の利点半分くらい捨ててるぞ。
上で言われてるパッチ1個当てるくらいなら cherry-pick で済むけど
ブランチを再構成したり、コミットの順番を入れ替えたり、コミットを統合したり、分離したり、コミットメッセージを修正したり、使わない日がないくらいの万能ツール。

>>261 今週のうちには専用スレに引っ越してくれるらしいよ。 >>166
> スレは立てるが、肝心のアプリ名を今考え直してるところだから、来週まで待ってくれ。

まぁまた言うだけでやらない理由を長々と説明（）しはじめそうな気はしてるけど。

>>257
言っている意味が分からんｗ
checkout -bした時点のbranchが間違ってましたって話？ｗ

どっちにしてもrebaseなんていらんよｗ

>>263
後からどうとでもつけられるアプリ名を理由に挙げるくらいだからね
「アプリ名が気にいらないから他のを考える」とか言いそう

rebaseに関しては
履歴を戻ってでもコミットとその流れを綺麗にしたい派
と
戻るの面倒だし汚くてもいいじゃん派
がいるから話が噛み合わない

コミットも含めて作品
ゴミを作ってる人には rebase は不要
そもそも git 不要だな

>>264
だからコミットが複数に分割されてしまうから
rebaseして意味のある単位に整えるんだろうが

いちいちパッチ当てるときに、
あれとこれとそれとどれを当ててくださいって
10個ぐらい持ってこられても困るぞ

>>266
コミットをパッチと考えて
後で再利用することを考えてる人

vs

後で見返すことなんてない人

の違いだな
結局一人プロジェクトなんよ
rebaseを価値を理解してないのは

作りながら、やっぱりこのパッチは不要だから外そうとか、このパッチとこのパッチを両方適用して試そうとか、別の人の作業を取り込んで影響を調べようとか、お手軽自由自在にできるのが rebase の真髄
あと昨日の作業でタイポしちゃったとかでも直すのには rebase を使うのが基本
branch と rebase 無しでやれって言われたら気が狂いそう。もう昔には戻れない

パッチ適用 ←ここでコミット
↓
やっぱやめた ←ここでコミット
↓
２つのパッチ適応 ←ここでコミット
↓
別の人の作業を取り込んでみよう ←ここでコミット
↓
タイポ発見修整 ←ここでコミット

何がいけないの？これでいいじゃん

>>271
そんな都合よく行くかよｗ
実際の開発したことないのか？

パッチ適用 ←ここでコミット
タイポ発見修整 ←ここでコミット
バグ発見修整 ←ここでコミット
やっぱやめた ←ここでコミット
タイポ発見修整 ←ここでコミット
２つのパッチ適応 ←ここでコミット
やっぱやめた ←ここでコミット
タイポ発見修整 ←ここでコミット
別の人の作業を取り込んでみよう ←ここでコミット
バグ発見修整 ←ここでコミット
3つのパッチ適応 ←ここでコミット
バグ発見修整 ←ここでコミット
タイポ発見修整 ←ここでコミット
タイポ発見修整 ←ここでコミット

こんな大量のゴミコミットの中から、必要な部分だけ取り出すとかできるかよ
普段から整頓しておけって、子供の頃に教わらなかったか？

>>251
Gitのコンセプトはなかなかチャレンジングだぞ。
全世界で唯一の履歴、完全平行作業(各自が任意のファイルを自由に同時に編集)ってのは、上手く行けば確かに面白い。
思考に階層がまるでない君らには通じないと思うが、
ソフトウェアは本来、実装階層ではなくて、コンセプト階層で勝負すべきなんだよ。

>>253
(俺が言うとろくな展開にならなそうだが)
rebaseは清書用だからな。コードを実際に書く人向けではない。
mergeだけでも問題なく行ける。というかrebase自体がほぼmergeだし。
ここはGitのコンセプトがずれてて、
> リベースかマージか
> 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#_リベースかマージか
二者択一ではなく、共存が正しいのだが、機能的に欠けてるからおかしな事になってる。
共存させる為には経路情報が必要で、俺はそれが当然保存されてると思ってて探したのに無い！で始まったのが前スレ814-
この辺、Gitに欠けてる機能を補完するとしたら第二弾以降になる。まあ全く予定無しだが。

rebaseを常用するのは、少なくとも従来スタイル(>>127)だとマネジメントが機能してない証拠でしかなく不味い。
Gitが開発の手法を変えた！とか言われてるのはこの辺ぶち壊して、
従来型の(やってる感だけの)マネジメントなんて要りません！としたからだろうけど、
(まあ実際の所ろくにマネジメント出来てないし、
仮に問題が分かったとしても後からでは余計に邪魔でしかないので手当も出来ず、
なら最初から何もやりません！ってのも分からなくもないが)
Gitの場合はついでにアナログ的努力、具体的には176内
・regressionテスト
・レビュー
・コーディングルール
もイラネ！って全部捨ててるのはさずがに駄目だと思うが、これで回ってきてるのも事実だからな。

まあこれはさておき、多分rebaseの馬鹿らしさを実感出来る状況にあること自体がマトモであり、幸せなんだろうよ。
そしてそれは知らない人には通じない。これもよくある状況だよ。
ドタバタしか知らない連中は、ドタバタするものだと思っちゃってる、ってこと。朝の支度と同じ。
Gitは力業(ちからわざ：パワープレイ)が出来るだけに、全部力業に持ち込んでて、力業に頼らない方策を無視してる。
これも勝つ為の戦略だ！はありだけど、例えばサッカーで力業しか無かったら色々言われるでしょ。

>>262
あ～ cherry pick ってそういう意味か。意味不明な機能だなとしか思ってなかったわ。
ただそれって多分、三角マージの指定方法を洗練すればmergeに統合出来た話で、
別機能にするのは仕様の練り方が全然足りない気がするが。(まあその気すらないようだが)

> ただそれって多分、三角マージの指定方法を洗練すればmergeに統合出来た話で、
できねーよ
頭悪いのか

>>276
> rebaseを常用するのは、少なくとも従来スタイル(>>127)だとマネジメントが機能してない証拠でしかなく不味い。
rebaseを管理の機能だと思ってるから
アホなんだよなぁｗ

> rebaseは清書用だからな。コードを実際に書く人向けではない。
これも理解してないやつのセリフ

適切なタイミングでコミットするから
rebaseが必要なんだが

ああ、コミットをpushと勘違いしてそうだなこいつｗ

facebook(meta)がgit対抗ソフト出した！
https://engineering.fb.com/2022/11/15/open-source/sapling-source-control-scalable/
> 歴史的に、バージョン管理システムの使いやすさには多くの要望が残されてきました。開発者は、リポジトリの複雑なイメージを維持することが期待されており、一見単純な目標を達成するために難解なコマンドを使用することを余儀なくされることがよくあります。Saplingでそれを修正することを目指しました。

長文ガイジの言い分は正しかった！！

> 多くのソース管理システムでは、コミットのスタックを操作することは特に困難です。スタックの早い段階でコミットに 1 行を追加するには、git rebase -iのような複雑なステートフル コマンドが必要です。Sapling は、最新のエンジニアでもスタック内のコミットを編集、再配置、および理解できるようにするための明示的なコマンドとワークフローを提供することで、これを簡単にします。
>
> 最も基本的なことは、スタック内のコミットを編集する場合、そのコミットをsl goto COMMITでチェックアウトし、変更を加えてsl amendで修正するだけです。Sapling は、スタックの一番上を新しく修正されたコミットに自動的に移動またはリベースするため、競合をすぐに解決できます。競合を今すぐ修正しないことを選択した場合は、そのコミットの作業を続行し、後でsl restackを実行してスタックを再び元に戻すことができます。Mercurial の Evolve 拡張機能に着想を得た Sapling は、内部で各コミットのミューテーション履歴を追跡し、スタックを何度編集しても、後でアルゴリズムによってスタックを再構築できるようにします。

Sugeeeeee！！！

>>277
rebase自体がほぼmergeと言ってる時点でもうね…
OOPの話にしてもそうだけど、彼は点でしか物事捉えられないんだろうね

>>280
AI とか使って何とかするのか？

基本的なコマンドは一緒にしてあるんだね
Git Cheat Sheet
https://sapling-scm.com/docs/introduction/git-cheat-sheet

どうせ新しく作るならAndroidやiOSをサポートしてほしかった

Sapling is a new Git-compatible source control client.
だからgitリポジトリを操作するラッパーっていう感じか

>>282
コンフリクトが出てもその場で直さずに放置して後で直せばいい、という阿呆な仕様でステートレスにしてるだけなので気にするな。

>>286
凄くよく理解できました。
ありがとう。
Mercurial 使えはいいのかも。

sl は
git のサブコマンドは(一見では)実態を表してないように見える
git rebase は万能過ぎて、最初に覚えるのがつらいので複数のコマンドに分割
って問題意識でコマンドを整理したんだろうな。histedit とかの命名に苦笑
どのみち一緒に使うことになるので最終的には手間が増えるだけな気がするけど
＃ うちでは sl ってやると蒸気機関車が走るよ

🚂🚂🚂

https://github.com/mtoyoda/sl

でもお前ら正直Linusからの反撃（口撃）楽しみにしてるんだろ？

sl ってやると蒸気機関車

世代がばれるな

今WSLにaptでslインストールしてみたけど蒸気機関車走ったわ

Macでもbrewでインストールできて蒸気機関車走った

カレントブランチという概念が無くなって代わりにカレントコミットになるのね
カレントコミットはブランチのヘッドである必要が無くて、そのカレントコミットにamendとかcommitができる
amendするとカレントコミットからブランチヘッドまでを自動でリベースしてくれる

確かにひと手間減りそうだけど挙動を理解できてない奴が使うとリベースのコンフリクトが頻発して面倒なことになりそう
コンフリクト解決を後回しにできるみたいだけど溜めるとそれはそれで大変そう

みんなと共有済みのブランチでこの途中へのamendが出来ないようにしておかないと、amendした修正をマージするのが大変そうだけど、うまくやってくれる仕組みがあるのかな？

Git の最新アップデートから考える開発手法の潮流
https://speakerdeck.com/yuukiyo/trends-in-development-methodology-from-the-latest-git-updates

ワークツリーの状態はカレントコミットが属するブランチの状態に保たれる？として、カレントコミットが複数のブランチに属してるような状態(できるのか？)ではどうなるのかな？
カレントコミットとは別にワークツリーの位置を指定するようなのは >>283 見ても見当たらないが、goto NAME と goto COMMIT でうまいことやってくれるのか

>>279
> What will stand out, though, is how every command is designed for simplicity and ease of use.
> There is no staging area.
> Fixing mistakes with ease
うむ。アプリに対する哲学は俺と同じだ。
ただまあ、同様につらつら考えてたが、どうも根本の戦略が違うと感じる。

従来： 手戻りを最小化する
Git： 手戻りの手間を極限まで減らせば、手戻りがあっても問題ない

ここで言う「手戻り」は、最狭義の
> やっぱやめた (271,272)
から、
・regressionテストを省いたことで、一部機能を壊したことに気づけなかったことによる、再修正
・レビューをしなかったことにより、不十分な修正であることを見逃してしまった事による、再追加修正
・CodingRuleを規定しなかったことにより、潜在的にバグを発生させやすいコードが存在し、結果的にバグが発生したことによる、修正
・OOPの基本を遵守しなかったことによる、ハッシュ交換程度での、大手間
・そもそも基本アーキがゴミな事による、実装では回避しようのない、大手間(Gitはこれは問題ない)
みたいな、広義～広範囲の物も含めてだ。

ただこれをきっちり成功させる為には、リーダーポジションにそれなりに優秀な奴が必要なのと、
そいつにだけどうしても過重な負担がかかってしまうのが問題だ。
これは、相手の力量を見極めて仕事を配分していくので、手駒がない場合には自分でやらざるを得ない、というより、
無理に振ったところでどうせ後で全部やり直しになるところまで確定的に見えてしまうので、自分でやることを選択してしまうからだ。
例の「ブラック会社に勤めてるんだが、もう俺は限界かもしれない」の藤田がそれで、完全に過労死コースになる。
(俺はWebで無料公開してた漫画の所までしか知らないが、藤田の彼女がそうなってたような)

この構造をぶち壊そうというのだから、Gitは過労死ストッパーとしては素晴らしいのかもしれんが、
俺や従来Cプログラマから見たら、「そんなコードでバグが取りきれる訳ねえだろ馬鹿かよ」でしかない。
その後の手間を考えたら、一度に直した方が楽なのに、それを選択しないのだから一緒にはやってられんよ、というわけ。
この根底には「手戻りを最小化する」という従来型アプローチの肯定がある。

対してGit教的にはこれは禁忌であり、「手戻りのコストが０ならいくら手戻りしても問題ないはずだ！」で、
Gitの場合は基本アーキだけは締めて、後は放置というわけだ。
CodingRuleやレビューはどうしても主観的だから、政治/哲学/信条が入り込む余地があって面倒なことは分かるけども、
完全に客観的なregressionテストまでやらないのは、逆方向の哲学を持ってるように見える。
つまり、従来型へのアンチテーゼだ。
まあ、従来型のアプローチにどこまで意味があったのか、という実験としては面白いだろうよ。
つき合ってられんので俺は降りるが。やり直すのが確定してる工事なんて無駄でしかない。
Gitが目指しているのは結局のところ、「ネットを介した人海戦術」でしかない。
そりゃ学術界からは相当嫌われるよ。

そういえば禿曰く、「コーディングを開始する前にじっくりと設計した方が良いプログラムの規模に下限はない」で、
これが従来型での基本だよ。
「やっぱ止めた」ではなく、「やっぱ止めた、になる事は、最初からやらない」が正しいとされる。
ただ当たり前だがこれには仕様聞いたら実装をぱぱっと思いつく程度の技術レベルは必要で、
お前らには全然無理だ。
Gitは馬鹿が闇雲にやってもなんとか前進出来るようにはしたから、そりゃお前らには必要なんだろうよ。
だから従来は「プログラミングの勉強をしてない奴は、ろくにメンテできない」世界だった。
今はお前らが「Gitを勉強してない奴はGitを使うな！」と言ってて、ツールの勉強はしてるらしいが、
全くプログラミングの勉強をしてないから、糞コードを糞コードとも認識出来なくなってる。
これはGit陣営もだ。なんだかねー。
ネット人海戦術を成功させる為には、どんな馬鹿でも有効な人材として使う為のツールは重要だけども、
やっぱ本末転倒だと思うぜ。
本来の目的であるプログラミングの勉強をすべきで、ツールはあくまで補助的なものだろ。
世界一のクレクレ君には、そりゃいつか誰かがいいコードくれるのだろうけどさ。マジでなんだかねー。

コーディングを開始する前にじっくりと設計した方が良い
このやり方では大きなものは作れない

一応貼っておきます。
難解なコマンドって、何言ってるんだろ。

Metaの大規模ソースコード管理システム「Sapling」がオープンソース化
https://gigazine.net/news/20221116-meta-sapling/

>「一見すると単純なゴールに到達するためには、難解なコマンドを使わざるを得ない」といった点をSaplingは解決しており、さまざまな面でシンプルに仕上がっているとMetaは述べています。

Git終了のお知らせ

Metaの大規模ソースコード管理システム「Sapling」がオープンソース化 - GIGAZINE
https://gigazine.net/news/20221116-meta-sapling/

>>303
これは楽しみ

でもネーミングがダメだな
一般的な単語をそのまま使うのは検索性が劣るので普及しにくくなる

大抵の環境ではslって打つと汽車走るしなぁ

>>296
Git じゃなくて GitHub の話になるけど GitHub の fork はそこをうまく解決出来る手段だと思うわ

>>301
判ります

zuckerにしとけばよかったのに

zucker --clone

Gitオワタｗｗｗ

Meta、Git互換のソースコード管理クライアント「Sapling」をオープンソース化
https://codezine.jp/article/detail/16876
> なお、インタラクティブなsmartlog Web UIも用意されており、「sl web」を実行するだけでWebブラウザが起動され、スマートログ、コミット、修正、チェックアウトなどの表示が可能となる。ほかにも、sl undo、sl redo、sl uncommit、sl unamendといったさまざまな操作を元に戻せるコマンドも用意されている。

meta の人が首切られても twitter の人みたいにならないようにしてるんかな

>>310
お前何回同じリンク貼ってるの？
馬鹿なの？
>>303
>>304

gitおじさんイライラで草ｗ
codezineのリンクは初出だがｗ涙で字が見えないらしいｗｗｗ

200m四方までズームで追える仕様が、200cm四方までズームで追える仕様になってないと、置きかわりは無理やで。

gitを使っている人ならsaplingの方が良いと思ったら乗り換えるだろうが
gitが難しいとか言ってる人に使いこなせるんだろうか

>>315
どうだろうね？
逆にgitに慣れた人が乗る換える利点は全くなさそうだけど、rebase 使ったことないとかほざいてる人たちは、とっと乗り換えるのが吉かもしれない。
ま、ちゃんとソースとか公開されてから評価なので今の時点で考えても無駄だな。

gitよりもできることが制限されるとしたら乗り換えるメリット全くないな

ステージングがない時点で移行できる人は初心者とかに限られてる気がするんだけど……

ごくわずかしかいないhgユーザーなら移行もありなんじゃね
知らんけど

>>302
お前らではな。それがGit以前の「最低限」だったし、その状況でGNU/Linuxは完全に動作してた。
ただまあ、Gitが何でどういう連中に崇拝されてるのかは理解出来たよ。
最終目的の「長期的メンテナンス」を、「コードの品質」でやるか「スーパークレクレ君」でやるかの違いだ。
ん～、やはり全く納得できんが、まあ見物だ。
しかし「スーパークレクレ君」にしても、最低限の選別眼は必要だと思うがなあ。Git開発陣にはこれもない。

昔から「仕事は段取り8割」と言われていて、プログラミングにもこれは当てはまるが、
「それなりの経験を積まないと、何が起こるかまるで想定出来ないので、段取りしようにも出来ない」という本質的な問題があって、
Gitはここを破壊したのだろう。だから本質的に初心者ホイホイで、初心者こそGitの恩恵にあやかれる。
道路工事やビル建設とは違い、情報だけを相手にするプログラミングだから、成立するのかもしれん。
Git開発陣見てると「段取り？何それ美味しいの？」だからね。
対して従来型は結局のところ「段取り」良くやろうとしてるだけだ。
ただGit開発陣以外はGitをツールとして段取り良くする為に使ってるし、俺はそいつらの方が正しいと思うけど。
それから、

従来： 「将来の手間の最小化」を目指し、今手間をかけて疎結合化する。(これにはリソースが限られているという大前提がある)
Git： 「リソースは無限大」なのだから、今の手間を最小化し、とにかく人を集めれば、いつか誰かが良いコードを書いてくれる。

とまあ、これも正反対だ。
結局のところ、従来型における「自分達でやらねばならない」という、
当たり前すぎて前提条件とも言われない、プロジェクトに於ける潜在意識みたいな物を、
Gitはぶち壊し、「いつか誰かがやってくれるんだから良いじゃん」とまあ、
(見てないけど)ゆたぽんに対する嫌悪感と同質の物を俺は感じる。あれもネットがなければまるで成立しないのが同じ。
良く言えばネット社会に適応したとも言えるわけだが、なんだかねー。

まあそりゃプログラミングの勉強なんてキリがないし、10,000時間とか要求されるし、
これに比べれば50-100時間もすればツールの達人には成れるから、おまえらみたいな馬鹿には魅力的に映るんだろうが、
マジでプログラマってコード書けない奴はゴミとしか見てないから、そこだけは注意しておいた方がいいと思うぜ。
(個人的にはこれも行きすぎだとも思ってはいるが)
ちなみに個人的にはこういう正当な苦労はしないと意味ないと思ってる。
自分にとって獲得が楽な知識は、他人にとっても楽なんだよ。
先行すれば、一時的にはちやほやされるかもしれないが、すぐに取って代わられるし、使い捨てられる。
プログラマなら、正当に、プログラミングの勉強をするべきだと思うぜ。
お前にとって10,000時間かかることは、後輩にとっても10,000時間かかるんだよ。
ツール屋として生きる、ってのも俺はありだとは思うけどな。(ただ多くのプログラマはそうは見てない)

>>315
その感覚が既にズレてる。

×　使いこなす
○　コードを書くことに集中しろ

自動rebaseってのは、ユーザーがrebaseする必要なくしているわけで、つまり、
プログラマはコードを書くことに集中しろ、日々の業務フロー通りにやってれば、自動的に上手く記録されるようになってる、というだけ。
要は「本業に集中しろ」であり、至極真っ当な方策。
使いこなすのではなく、そもそも使ってる感覚すら無くすことを目指してる。これは正しい。

メールや名刺を放り投げておいたら自動的に完璧に整理されてて、「あん時のアレ！」で出てくる、みたいな話。
或いは卒アルと言えば分かりやすいか？
まあ今時の若者には逆に通じないかもしれないが、
俺らが高校生だった大昔は、今みたいに全員がカメラ持ってる状況ではなかったから、
提携業者が勝手に学校に出入りして日々の授業風景から学園祭まで色々写真を撮り溜めてた。
そして卒アルとして編集されて、勝手に出てきた。
俺らは生徒として活動してれば、そつなく記録されてた、というわけ。これを目指してる。
日々の業務フローを適切にこなしてれば、完璧に記録されてるから、本業に集中しろ、というわけ。
使いこなす必要なんて、最初から無いんだよ。業務フローを守れ、それだけ。

コミット・メッセージ不要とか言ってる長文君が、重要なのは将来の手間の最小化とか言ってて草
一人でしか開発したことないやつの戯言だね

>>322
自動rebaseはいわば自動的な記録改竄なわけで、全てを完璧に記録するのとは対極では？
今時のデータ収集と分析においては全てをありのまま記録した上でデータ利用時に工夫するのが正道で、むしろrebaseを廃した上で
rebase無しでも見づらくならないようにクライアントツール側で表示の仕方を工夫するのが筋かと

>>324
うむ。お前も長文君と同じレベルで何も分かってないな。
git は履歴管理ツールじゃないよ。なので履歴改竄とかもないよ。

長文君には一刻も早くゴミ箱アプリを開発して理論の正しさを証明する必要があるので、他所のアプリの話はそこそこにして新しいスレッドで作業して欲しい

①gitは情報共有ツール、他人や未来の自分に「効率良く」情報を提供し情報を利用するのに使う
②gitはパッチ管理ツール、上記①を実現するためにコミットを作成、検索、編集、再利用するのに使う
③gitは整理整頓ツール、上記①②の目的で日頃から不要な情報を削除し有益な情報のみを残すようにするのに使う
rebase は②のコミットの編集・再利用するためのコマンドで、主に③の目的で使用する

長文くんは毎回意味のわからない喩え(今回も卒アルがどうとか)使ってるけど、あれでわかりやすく説明できてると思ってんのかね

俺が例にするとしたら「実験ノート」と「科学論文」かな。
長文君とかが欲しがってるのは「実験ノート」を録るツール。
git とかが提供しているのは「科学論文」を共有する論文誌。

「実験ノート」はありのまま全ての情報を記録するのが目的で後から修正したりしたら改竄になる。

でも「実験ノート」をそのまま貼り付けただけでは「科学論文」にはならない。論文では必要な情報だけを抜き出し簡潔にまとめて他人に分かり易く説明する必要がある。
そのためには何度も推敲する必要があり、手元にある論文の原稿は何度修正しても良い。改竄とかじゃない。

あと一度出版された論文の内容は修正できない。訂正するには新しい論文を書いて指摘する必要があるあたりも同じ。

意外と長文になった。すまん

meta版のgitもどきが出たことで
終わったのはgitじゃなくて
長文おじさんの方だったというオチ

>>324
俺もそう思うがそこはモノレポの限界なんだろ。

全てをありのままに記録するとbranchが煩雑すぎて余計意味分からんから、
いっそのこと熊手形状(ある点までは幹は一本でその先は一斉に分岐)に強制した上で、適用順に幹に追加、ということだろ。
幹は縞々模様になるが、一本鎖にはなるし、拡大すれば子細も得られ、縮小すればあらすじが得られる。
まあ初手としては悪くない選択だと思うよ。これまでのログを見慣れてる奴にも馴染みやすい。

そしてこの場合、rebaseをユーザーから隠蔽出来るから、(というか多分これが目的)
実際はありのまま全部記録してたが(M)、表示では一本鎖にしてました(V)、なんて事もツール内側だけで出来る。
だからsapling方式でユーザーは全く問題ないと分かったら、次手としてMVC分離で今君が言ってる事(＝俺が欲しい機能)もやれる。
ここら辺の作戦は、実用主義で良いと思うよ。ツールは、
・「今出来てない」ことが出来ないのは、大して問題にはならないが、
・「今出来てる」ことが出来なくなるのは、大問題だから
ユーザーからrebaseを本当に取り上げて良いかをまず様子見して、というわけだ。
(この点、ダイレクトにこの次手を目指すべき、と思う連中には物足りないだろうが、
作ってる連中が自分達のモノレポ用にチューニングしてるのだから、まあ仕方ない。
ただGitにはMVC臭がまるでなく、おかしな仕様になってる部分をmetaが修正してくれることには期待だ。
rebaseはViewでやるべきで、Modelでやるのは不味いし、基本にも反する。
ここら辺の判断が付かないのだから、Git開発陣はMVCを知らないのだと思うんだよね。つかあいつら色々不勉強すぎ)

ただ、根本的な問題は、今のGitは一次元(時間軸)方向に成長する「一つの」ものをトラッキングする用に出来てて、
モノレポみたいに「多数の」物をブチ込んだ場合に対応出来ないことだ。
モノレポの場合は成長方向が多数だから、例えば中央から外側各方向に成長するものであって、
記録としては年輪やレーダーチャートみたいな見え方にならないと駄目だが、少なくとも今のGitはそうなってない。ただの線だ。
(それはポリレポでやれ、なのだろうけど、適度に癒着してるからモノレポの方がいいという判断なのだろうし)

>>329
それは紙媒体前提の、20年前の思考だよ。
実際Gitはそうだけど。

>>332
「紙媒体」ではなく「分散・非同期」でやる手続きな。git と科学研究の共通点。
「集中」とか「完全同期」とかの管理型が好みなら別の手順になる。

>>166
長文君がソフトを作る話はまた「いい名前を思いつかないから先延ばし」？

立てた。

日常の進捗履歴記録ツールWitBucket(仮称)検討中
http://2chb.net/r/tech/1668901194/



>>334
つかお前らマジのニートなんだと思うが、
今日やれ明日までにやれ今すぐやれ、とか、仕事はそういうものではないんだよ。
何であれ段取り良くしようと心掛けるのは大事。
というかそういう努力をしないと出来るようにはならないから、Gitに頼り切ってると上達しないのだと思うよ。今の君らがそれ。

ちなみにLinusがC++erを嫌ってるのは、
C++コンパイラがよしなにやってくれることを何も関知せず、C++なら素晴らしいと盲目的な連中が多いからで、
当たり前だがC++コンパイラが何やってるか理解してればそれをCで手動で書くことは(面倒だが)可能で、これを要求してる。
本来ツールはこのように、「無くても出来るけど、手間を減らす為に使う」のが正しく、
ツールがないと何も出来ない(C++コンパイラがやってくれないとメモリ管理も出来ない）連中が使うべき物ではないんだ。
Gitで凄く楽になった、が正しく、Gitが無いとプログラミング出来ません、は完全に間違い。
これはGit以前はそれなりに「手動で」段取り良くやらないと収拾がつかなかったからだけども、
ここでツールに頼り切って段取り良くやることを放棄しては駄目だ。
(と思うがGit陣営はこれで回ってるからなあ。
でも上達はしてない。ただこれも、Git以前の上達＝段取りが良くなる、に近いから、
Gitがあれで最終的に破綻しないのならあれでいいのだ！になってしまうし、なんだかねー)

相変わらず適当なこと書いてるな

git使うと段取りが良くなるからみんな使ってるんだけど、長文君はそうじゃないみたいだな

git はプログラムした結果を共有するためのツールって延々書かれてるのに、都合の悪いことは無視するよな
それとも理解できないほど馬鹿なんだろうか

ルールさえ決めておけば物置になるだろ。

>>335
>御託を並べるのは長文君ソフト(仮)を完成させ、それがgitよりも
>使われるソフトになってからにしろ

ってことで、大口叩いてるのではないことを示すために進捗状況を
公開しろと言ってる
スレは立てたけどこうなるんだろ

>言うだけでやらない理由を長々と説明（）しはじめそう

gitも満足に使えない奴ら向けのバージョン管理ソフトを作るってことはGit以上に開発に時間かかるだろうけど、本当に来年の3月までに一人で完成させられるのかな

>>340-341 せっかく別スレが立ったんだから、こっちで触らないで欲しい。

同意
ようやくGitスレに静寂が訪れた

>>342-343
すまん

>ようやくGitスレに静寂が訪れた

そうなるといいな

ふと思ったんだが

・リモートブランチを削除して再度push（git push --delete + git push）
・リモートブランチに強制push（git push -f）

て一見やってること同じだけど違うことしてるのかな

>>345
追加のオプションによって動作が変わるので厳密には違うけど、原則似たようなもんだよ

ワクチン接種歴「4回目までしか入力できない仕様」 - HER-SYSの接種歴回数、5回目は「不明」に

DSCIA自民
ネオコンウヨスパイは見つけ次第射殺しろ！
WHOロックフェラーを討伐せよ！

コロナで死んでいない人　99.96％　厚生労働省発表　

コロナ死者数のカウントはコロナ以外で死んだ人をコロナで死んだこととし
ワクチンを打たすため誘導した洗脳報道

裁判で名前を呼ばれる間抜けロックフェラー

コロナ対策に関する『大陪審（grand jury）』の審理を開始★ ライナー・フーミッヒ博士の冒頭陳述
https://www.bitchute.com/video/lZH4HZjO6QJE/

いい歳こいて反ワクチンて

時を同じくして今、海外でも長文ガイジ理論が熱い！
分岐もマージもせずひたすら一本道のコミットが続く方法論が大人気！
https://westling.dev/b/extremely-linear-git
この記事に対するHacker Newsのスレでも驚愕を持って迎えられ議論白熱「思いもつかなかった」「世紀の大発見だ」「天才か！？」など大絶賛！
https://news.ycombinator.com/item?id=33704297
今、世界でバケツが熱い！
ちなみにGitHubのページはこちら
https://github.com/zegl/extremely-linear

>>349
お前が持ってきた最初のリンクの内容を翻訳してやるよ。ヴァーカ

> 非常に直線的な Git の歴史
> 私が自分のプロジェクトでやりたいことの 1 つは、git の履歴をできるだけ直線的にすることです。
>
> 通常、これはコミットをメイン ブランチにリベースすることを意味しますが、
> フィーチャー ブランチからメインへの一方向のマージのみを許可し、
> その逆は許可しないことを意味する場合もあります。それはプロジェクトによって異なります。

>>350
バカだなぁ、もっと先まで読めよ早漏ｗ

>>349
ビットコインかよｗ

shit!!!

Git v2.39.0-rc0

Git v2.39.0-rc1

Junio氏復活してるね

.gitmodules で commit-id やタグが指定できないのはなんか理由があってなのかな。
技術的にそう難しそうにも思えないが。

>>356
urlの代わりにコミットID書くってこと？何のために？

代わりにじゃなくて併記でそのurlのリポジトリの特定のコミットを指定できたらいいと思った。
過去のバージョンをチェックアウトした時、参照先の最新と互換性がない場合なんかは困るんでないかな。

>>358
urlが指すリポジトリを取ってきてそこでcheckoutするコミットは最新のものではない
checkoutするコミットは.gitmodulesじゃなくて別の場所に既に記録されている

具体的には、コミットグラフの中で、通常のディレクトリは treeオブジェクトのハッシュが記録されているけど、
サブモジュールが展開されるディレクトリは別リポジトリの commit オブジェクトのハッシュが記録されている
cat-file -p とか使ってコミットグラフのtreeを辿って行けばサブモジュールはtreeじゃなくてcommitになっているのがわかる

なるほど、commit-id はリポジトリに記録されているのか。ありがとう。

Git v2.39.0-rc2

Git v2.38.2

メンテナンスリリース

Git v2.39.0

おもしろかったので

Gitは最初1244行しかなかった
https://zenn.dev/uta8a/articles/b7169fd147fb31

Githubのブラウザ上でmaster派生の新しいブランチを作ってプルリクを作ろうとしても
「there isn’t anything to compare 」と出て作れない

masterと新しいブランチに差分がないからだと思っていてローカル環境だと空コミットうって差分を作るんだが
Githubのブラウザ上からでも空コミットでできるの？

個人のリポジトリならReadMeとかの内容を適当にかえて差分を作るんだけど
そうじゃないケースだと空コミットで済ませたい

そもそも差分がないプルリクって何がしたいの？

あとで特定の目的をもったブランチ群をマージするための受け皿となるガワが欲しいんだってさ
そのガワに集めてからmasterにマージする

あーなるほど、それは分からんでもない
GitHub Actionsで空コミット作るだけのワークフロー作ってworkflow_dispatchで手動トリガしたら

役に立つ回答では無いと思うけどgitlabだとできる

基本機能でさくっとできれば理想だったけど、そうはうまくいかないのね

そもそもプルリクエストはgitの機能じゃないしなぁ

GitHubのプルリクエストが今の仕様なのは、むしろGitが想定している本来のワークフローを尊重した結果じゃないか？
プルリクエストって本来は文字通り俺のリポジトリからプルしてくれというメッセージ機能に近いもので、
この例のように組織内でのブランチ間の差分のモニタリングを目的として使用されるなんて当初は考えもしなかったんだろう

「Gitea」の開発者が離反、代替プロジェクト「Forgejo」を立ち上げ
https://codezine.jp/article/detail/17071

Gitリポジトリマネージャがどこで使われているのか、よく分からん。

>>374
ウチで使ってるわ
乗り換えないとならんのかなぁ

今年最後にgitを覚えようと
git 本体とtortoisegit と githubに登録したんだが

これ全部、機能としては同じだけど別物なのか？
あちこちのサイト見ながらやると「こっちのサイトはgit入れてて、あっちはtortoisegit 、こっちはgithub」
みたいな感じになって混乱した

githubを直接触りたいならgh cliのがいい
ghとgitの組み合わせが最強