Git と GitHub の次を妄想する

GitHub みたいなサービスを今一から作るならどの言語・フレームワークを使うか GitHub の次は何かを考えてみるのは、現実に実現困難なのを忘れれば、なかなかに楽しいことではあります。ここではその妄想をやっていきましょう。 GitHub の抱える課題を分割すると、Git の問題と、 GitHub の提供する機能の問題に分けられると思います。自分は、Git をベースとして GitHub に勝つのは現代ではなかなか難しいと考えています。MS による買収と実際に注ぎ込まれてる資本を考えると、よほど斬新な切り口でないと、 同じ Git を使っても優位性は出せません。 なので、 GitHub に本質的に勝つには、その基幹となる VCS から考え直すとよいのではないか、と考えています。幸いなことに(?)、Git はその優秀さは認められていますが、学習の困難さや特定のユースケースで機能しないことが知

[n314]

pull requestあるよ。https://n314.hatenablog.com/entry/2019/06/21/211838

[UKIBORI]

“git の優秀さは、 個人的に git pack にあると思っていて、objects 内で似たような内容のチャンクを、編集距離に基づいて圧縮します。各 blob の中身は Packfile へのインデックスになります。”

[kako-jun]

Git自体の拡張はリーナスが許可しない。MSのできる範囲で、GitHubにVSCodeのWeb版が統合され、VSCodeのローカル版にGitHub操作機能が付く。その結果、IssueやPRはVSCodeのエディタ上で書くのが当たり前になるかも

[kazokmr]

GitもSubversionが使えなさすぎて開発したって経緯をどっかで読んだ気がするから、VCSから考えた方がいいんだろうな。あと自分の仕事上、バイナリファイル管理どうしたらいい？って相談は多い。

[gabill]

RepositoryとProjectを分ける。Projectは複数のRepositoryを持つ。Issue,Pull RequestはProject単位で受ける。大抵のコマンドはProject単位でも実行できる。Repositoryは細分化する。Versionが上がるだけで別Repository。前VersionとのRelationは残る。

[prograti]

こういうのとか https://radicle.xyz/

[a-kuma3]

partial checkout が欲しくなるのは、commit の単位が雑（大き過ぎ）か、ひとつのファイルが大き過ぎなんだと思うけど。部分的に取り込みたければ difftool で足りると思うけど、使うことはあまりないかな

[akabekobeko]

自分ならこう作るというのすごく楽しいよね。これだけで酒の肴になる。GUI は私の用途だと Sourcetree で充分。足りなければ CLI や GitHub で補完すればいいやという感じ。ひとつだけでうまくやらない、という諦念もある。

[wordi]

Redmineと指定したリポジトリのチケット番号がどちらかを一新した時に合わなくなるのは困るなと思ってる

[ledsun]

ブロックチェーンにバージョン管理システムを載せるの、技術的に可能そう。ネットワークに参加するインセンティブはなんだろう？やはり、匿名でメタルギアのソースコードを公開するブラックネットワークに…（妄想中

[ponpon_qonqon]

Git → GitHub → GitHub Z → GitHub GT →

[endo_5501]

やっぱ部分チェックアウトは欲しいよなあ。いろんなコード管理するときとても面倒

[mistake3]

GitHouse

[takutakuma]

次を妄想するの、色々と理解が深まりそうなので他のことでも妄想してみたい。

[mizchi]

書いた