Add support for the jj SCM

[nilskch]

This discussion is about #21538. I opened a new discussion to avoid spamming the issue.

I would like to work on a better jj integration over the next couple month and would like to put more structure into the workstream. It would be great if we can work more closely with the Zed team on this!

Project Milestones

I would like to split the workstream into the two following milestones:

Removing the need to co-locate Jujutsu/Git repos

Currently, most Zed + jj users colocate the Jujutsu/Git repos for two reasons:

• git blame - inline blame still works and is very helpful
• git diff - The diff view and restoring changes

Colocating the git repository comes with a performance hit, so this is not ideal. Before we add a jj UI, I would like to add support for jj diff and jj file annotate (the jj equivalents of git blame and git diff). This requires some work upstream in the jj, but I am happy to take on that challenge.

It's already a big win if Zed users do not need to colocate the repos anymore, especially for very large repos.

Building a jj UI

@maxdeviant added a picker for jj bookmark list in #30883, but it's behind a feature flag jj-ui and I don't know if there has been any development since.

There are probably many different opinions on the UI, so I would focus on implementing blame and diff now, but it would be great if we can already talk about how a nice UI should look like in the future. I am not a designer/frontend dev, so maybe someone here finds time to make some sketches that we can iterate on?

Using jj as a CLI or as a lib

We have to options to communicate with jj:

• Run the jj CLI as a command
• Consume the jj-lib as a crate

Most jj TUIs call the jj CLI and parse the output instead of using the jj-lib crate (even the ones written in Rust). This is because the jj-lib is not that good atm. However, I think we should take the ambitious approach and consume jj as a library and we shouldn't use the CLI and make the necessary upstream contributions - other IDEs/app authors will benefit from this as well.

[JonGretar]

Now that the git support is getting pretty good. We might want to consider starting with some basic jj support?

[BoscoDomingo]

Given the fact that jj-lib is seemingly not that great yet, could we at least build something in the meantime that uses the CLI in a way that is easily replaceable once the lib is ready?

Idk what the stance is on expecting users to have the jj binary installed in their system. I'd assume it's ok as long as it's an opt-in setting and we let users know and give them the ability to point to a specific install path (or check PATH by default otherwise), right?

As for features, I would divide them into Git colocated, pure jj and common. I have personally never used jj by itself, it's always been in Git repos (and I would expect the vast majority of users to be in that camp as well), so I do think supporting both would be nice but the first focus should be the Git-colocated ones.

After that classification, we can start ranking them by complexity/usefulness ratio. I would expect moving up and down the revisions to be fairly trivial, whereas conflict resolution may be a bit more involved, for example.

Also in terms of the GUI, there are some VS Code extensions and desktop apps we could take inspiration from, or even recreate the built-in TUI itself. It does however feel like a significant undertaking given the myriad of edge cases and ways to display the data, and something that may not be as critical as, say, being able to commit changes or change descriptions but open to hearing other opinions on this.

Maybe a rough first draft (in no particular order) could be something like:

• Revisions
  • Create
  • Switch to
  • Edit description
  • Commit
  • Squash into
    • Parent
    • Specific revision
  • Absorb
  • Abandon
• Bookmarks
  • Create
  • Switch to
  • Delete
  • Rename
  • Advance
  • Move to revision
• Workspaces
  • Create
  • Switch to
  • Delete
  • Rename
  • Show files opened from a sibling workspace as such (similar to Cursor with Git worktree files)
• Files:
  • Restore/reset
  • List
• Log (open terminal for now to show it? Spawn a new window?)
• Push
  • Bookmark
  • Everything
  • Tracked
  • Deleted
  • etc (all other flags in jj git push)

[JonGretar]

Idk what the stance is on expecting users to have the jj binary installed in their system. I'd assume it's ok as long as it's an opt-in setting and we let users know and give them the ability to point to a specific install path (or check PATH by default otherwise), right?

I would say that is not an unusual expectation. Of course they will have the product they use installed. Just like Zed expects the git binary to by installed.

[BoscoDomingo]

@JonGretar Awesome. Wasn't sure about it, especially given some IDEs and Git-related apps ship with their own Git versions, for example

[Ralith]

Using a separate binary is actually a major advantage, as it allows them to be updated independently, and makes it Just Work with jj forks that use custom backends.

[BoscoDomingo]

Ok, thats's a good point and it simplifies the whole thing, although on the other camp it may mean having a minimum version we can support if we use newer features. Definitely a problem for the future though

[luolong]

Just to remind that there is #21538

[BoscoDomingo]

Yes, and I asked there which is the better place to continue the discussion. Still unclear

[Wabuo]

Just want to point out that this: https://github.com/nilskch/jj-lsp exists, extension to resolve jj merge conflicts via lsp