みんながどんなことを考えてるのかワクワクしてる ;) ところで、マーティンはグーグルを辞めたの？

jjが大好きなんだ（俺のHNのコメント履歴見てみて）。でも、jjにあってgitが得意なことの一つはコピー追跡なんだよね。もし誰かが上流でファイルの名前を変えたら、そのファイルに触れるコミットをメインにリベースしようとしたとき、jjはgitに比べてあんまりうまく処理できないんだ。これ、jjに近いうちに実装される予定あるのかな？

Jujutsu/jjがもっと注目されないと、これにチャンスはあるのかな？新しいVCSを学ぶのはプログラミング言語を学ぶよりは楽だけど、多くの開発者はgitを深く学んでないし、Mercurialや他のツールもあまり普及してないからね。

もしかしたら間違ってるかもしれないけど、jujutsuの最終目標は自分たちのバックエンドを使うことだと思ってた。gitの共存をサポートするのは、ユーザーを引き込むための互換性のケースみたいだね。推測するに、ERSCはこの新しい人材を基にjjフォージを作ろうとしてるんじゃないかな。それは素晴らしいと思う。

これについてはすぐにもっと話すけど、短く言うとこういうことだよ：SourceHutやCodebergのようなGitHubの競合を作ってるわけじゃない。企業向けのインフラを構築してるんだ、ソーシャルコーディングサイトじゃなくてね。jjはgitと連携するけど、必ずしもそうである必要はない。jjは多くのバックエンドと連携できる能力がある。gitはオープンソース界では人気だけど、他のバックエンドも可能だってこと。これが私たちが構築してきたコア技術なんだ。エージェントの台頭で、ますます多くの企業がgitの限界にぶつかってる。大規模なモノレポ用に設計されてなかったから、パフォーマンスの問題や、組織全体をスケールアップしようとすると重要な機能が欠けてるんだ。MetaやGoogleのような企業は、今の状況になる前からこれに直面してたけど、最近はFAANGでなくてもこういう問題にぶつかることがあるよね。私たちは、ソースコントロールのような基本的なものにおいて、段階的な導入が本当に重要だってことも理解してる。だから、私たちの技術にはコア機能と連携するgitのイングレス/エグレスがあるけど、gitではできないより高度なことは非gitプロトコルを使う必要がある。jjはその二つの世界をつなぐ橋なんだ。分かってもらえるといいな！私たちはしばらく擬似ステルス状態だったけど、これから少しずつ自分たちのことを話し始めるよ。

これはすごく正当な質問だね。私の少しの意見だけど、あなたがjjにどれだけ詳しいか分からないけど、確実に言えるのは、jjはgitに比べてかなりのUX改善を提供してるし、最終的にはバックエンドも持つ予定だってこと。ERSCから最初の実装が見られるかもしれないし、彼らのウェブサイトを見ると、初日からエージェントのことも考慮してるみたい。だから、現代のワークロードにもっとスケールできるものが出てくるかもしれないね？

gitはjujutsuができることをすべてできる（そうでなければ、jujutsuはgitと連携できない）。個人的には、もう少し複雑だと思う。例えば、Gitには現在、コミット内にコンフリクトを保存する方法がないんだ[1]。これは私たちの主要な機能の一つなんだけどね。これがどう機能するかというと、基本的にコンフリクトしたツリーの両側をGitのオブジェクトデータベースに保存しているんだ（そしてそれらすべてを指す別のコンフリクトしたツリーも）。でも、Jujutsuが理解するコンフリクトを表す実際のデータ構造は別の場所に保存されている。GitはJujutsuによって作成されたコンフリクトツリーオブジェクトを見ると、すごく混乱するはず。壊れることはないけど、何を見ているのか理解できないからね。だから、データベースに正しいオブジェクトが保存されていても、Gitがそれを「正しく見る」ことができない場合、「git」（または大文字のGのGit）はそれをサポートしているのかどうかは、聞く相手によると思う。ストレージのレイアウトがGit「そのもの」に密接に結びついているのは、Gitの最も興味深い特性の一つだと思う。私の見解では、Jujutsuはディスク上のGitストレージレイアウトを使っている。でも、基本的に両者のアルゴリズムやUXは全く異なるんだ。そこが実際の違いの大部分だよ。gitコマンドが動くように、たくさんの細かいGitの詳細（例えば、ブランチの追跡やリモート統合など）と統合する必要があるのは、UXを良くするための必要性だね。ディスク上のGitフォーマットを使うことは全然できるけど、git CLIには理解できない形で使うことになるから、明らかにあまり良くないだろうね。ちなみに、私はERSCで働いているけど、Jujutsuのメンテナーの一人でもある。この投稿はメンテナーの視点から書いているよ。[1] 昨年のGit Mergeで、Elijah Newrenがort-mergeに基づいてGitにファーストクラスのコンフリクトを保存する非常に初期のクールなプロトタイプをデモしたんだ。だから、これは永遠に真実ではないかもしれないね :)

「できる」と「簡単にできる」や「最小限の摩擦でできる」は同じじゃないよね。私はローカルでJJを使ってるけど、「ポーセリン」や「GitのUI」と呼ぶ人たちは多くを見落としてると思う。確かにそういう使い方もできるけど、私が感じたのは、JJは普通のGitとはかなり違ったワークフローを促進（そして多分、奨励）するってこと。JJでやってることを普通のGitでもできるけど、全然自然には感じないし、JJ主導のリポジトリをGitツール（単純なGitコマンドラインツールも含めて）で使い始めるとその違いがよくわかる。個人的には、単なるバージョン管理ユーザーとして、GitのモデルよりもJJのバージョン管理モデルの方がずっと好きだな。UIのメカニクスはすごく簡単に使えるようになった（基本的なことは1日で覚えたけど）、でもアイデアや概念の違い、そしてそれがワークフローに与える影響を理解するのには1、2ヶ月かかったよ。私にとって、その努力は価値があった。

jujutsuはgitと一緒に動く。TypeScriptがJSと、QUICがUDPと、GraphQLがHTTPと、AndroidがLinuxと同じようにね。 > gitはjujutsuができることはすべてできる（そうでなければ、jujutsuはgitと一緒に動けない）。「jujutsu」と「git」を「typescript」と「js」、「quic」と「udp」に置き換えてみれば、わかるよ。

アセンブリはPython/Java/Rustができることはすべてできるけど、必要がなければアセンブリでコーディングしたくないよね。