Inquiry: plans and preferred path for preliminary Sapling support

[omry]

Hi! I’m interested in contributing preliminary support for Sapling SCM and wanted to coordinate before starting substantial work.

I noticed that the VCS architecture anticipates eventual Sapling support, and that #2461 is developing the corresponding Jujutsu integration. I also saw that the earlier JJ contribution in #1796 was superseded by the newer architecture. I’d like to avoid duplicating planned work or pursuing an approach the maintainers would not want to maintain.

My initial target would be GitHub-hosted repositories used through the sl client, with preliminary support for:

• detecting Sapling repositories, including .sl and compatible .git modes where practical;
• workspace status, diffs, files, bookmarks, and remotes;
• local commits and revision/bookmark navigation;
• pull and push through the repository’s Git-compatible remote;
• continued use of T3 Code’s existing GitHub integration for repository and pull-request operations;
• isolated per-chat working copies;
• capability-gating checkpoints and other unsupported workflows until their Sapling semantics have been validated.

For per-chat isolation, Sapling has an opt-in share extension that creates independent working directories backed by a shared repository store:

sl --config extensions.share= share <seed-repository> <chat-workspace>

This appears closer to the required abstraction than creating a full independent clone for every chat. Normal GitHub clones use the Git protocol and are not inherently lightweight or lazy, so cloning afresh per chat could introduce substantial latency and storage overhead.

My tentative workspace design would therefore be:

1. maintain one T3-managed .sl seed repository for the GitHub repository;
2. use sl share to create an isolated working copy for each chat;
3. keep bookmarks independent between chat workspaces;
4. use full independent clones as a fallback if shared working copies prove unsafe for required history-rewriting operations.

sl share is an opt-in, less prominently documented feature and includes warnings around destructive history rewriting. I would prototype and test its behavior with operations such as amend, rebase, workspace deletion, and recovery before treating it as production-ready.

I would aim to keep Sapling-specific command handling inside its own driver and contribute shared changes as small, provider-neutral improvements. In particular, I would prefer generic workspace operations over adding Sapling conditionals throughout the existing Git workflow.

Before proceeding, could you clarify:

1. Is first-class Sapling support currently planned?
2. Should Sapling work follow the architecture in feat(vcs): JJ #2461, or is that direction likely to change before merging?
3. Would you accept preliminary support that initially omits or disables checkpoints and advanced Git-specific workflows?
4. Would sl share be an acceptable candidate for per-chat workspace isolation, assuming the prototype establishes safe lifecycle and recovery behavior?
5. Should .sl repositories cloned from GitHub be the initial supported mode, with .git-mode support treated separately?
6. Would you prefer several focused PRs—generic routing, read support, mutations, and workspace isolation—or one integrated feature PR?

I’m happy to implement and test this work. My goal would be useful preliminary Sapling support without disrupting existing Git behavior or committing T3 Code to abstractions the maintainers do not want.

If this direction sounds reasonable, I can begin with either a small detection/status/diff proof of concept or a focused prototype validating sl share as the per-chat workspace primitive.