这是一篇关于新兴jj生态系统的建议文章。

主要观点：

• 对 VS Code 中 jj 的内置集成不满意，更倾向于使用edamagit实现的 Magit 界面。
• 希望能实现 Magit/jj/VSCode 或 Magit/jj/Zed 的三重整合，但目前缺乏足够的插件 API。
• 指出 Emacs 和 VSCode 中的 Magit 从用户角度看基本相同，缺少一个能实现一次 Magit 的“窄腰”，目前的 shell/终端组合存在诸多问题。
• 提出一种实现“jj 的 Magit”的捷径，即将相关文件直接创建在磁盘上，通过 LSP 实现大部分 Magit 类似的体验，如语义标记、折叠范围、跳转定义、代码动作等，但缺乏 Magit 的一键操作级别的集成。
• 从宏观角度看，VCS 系统通过内容哈希链接对象形成复杂图，而 Git 和 jj 已在宏观和微观层面使用“文件系统作为用户界面”范式，中间环节缺失。

关键信息和重要细节：

• VS Code 内置 git 集成不适用于 jj，直接解决方案是为 VSCode 添加对 jj 的一级支持，但作者想要更好的 VCS UI。
• [edamagit]是[kahole]为 VSCode 实现的 Magit 版本，被认为是正确的 VCS 用户界面实现方式。
• 不同编辑器中的 Magit 从用户角度看基本相同，缺少能实现一次 Magit 的“窄腰”，目前的 shell/终端组合存在复杂、设计缺陷和功能缺失等问题。
• “magit for jj”的实现方式是将相关文件创建在磁盘上，通过 LSP 实现大部分 Magit 类似的体验，如语义标记用于语法高亮、折叠范围用于折叠差异等，但缺乏一键操作级别的集成。
• VCS 系统通过内容哈希链接对象形成复杂图，Git 和 jj 已在宏观和微观层面使用“文件系统作为用户界面”范式，中间环节缺失。