feat: vcs: support Jujutsu as a diff-provider

[poliorcetics]

Built on top of #9951, I'll be waiting for it to be merged to un-draft this

---

Jujutsu (jj) is a new change-based VCS (whereas git is branch-based).

In this PR, I add the ability for helix to get the diffs and current head, behind a feature called jj that is active by default. That would make it the first editor I know off that officially handles that VCS!

To handle all current, future and private backends (Google already has one I believe), I instead made it so Helix can behave as a diff tool for Jujutsu and then use that as a subcommand to get the diff base.

For the head, I simply used the templating system to extract all relevant informations.

Jujutsu has a library, called jj-lib but it's not ready for use in third party programs and wouldn't fix the issue of custom backends anyway.

Testing

Since testing needs jj installed, I haven't written any for Helix yet to discuss how to do it:

1. Ignore the issue. I don't like it much, but it doesn't cost CI time and doesn't need any change. For a feature that probably won't be used much yet, that's probably ok for a time
2. Install jj in CI and use it to test the new feature

[yerlaser]

Hi @poliorcetics,

Thanks for this PR, hope it will be merged soon.
Quick question. I just built from it but all I get the change hash in the status line but no diff indicators in the gutter.
Did I miss something?

[VasanthakumarV]

Hi @poliorcetics,

Thank you for working on integrating jj into helix, I am using helix from your branch, and it has been great so far.

I am new to jj, and this PR is still a draft, but wanted to make a suggestion on the status-line entry,

Will description.first_line() be more useful thanchange_id in the status-line message?

Change-Id:

Description:

[poliorcetics]

I am new to jj, and this PR is still a draft, but wanted to make a suggestion on the status-line entry,

Will description.first_line() be more useful thanchange_id in the status-line message?

It could easily be done code-wise, but I'm trying to get the same behavior as the git backend (to make it easier for this PR to get in), so I don't think I'll do it

If maintainers confirm it would be ok to add, I'll do it :)

[bryceberger]

This gets a bit weird with reloading newly-added or untracked files.

1. Create a new file, add some content. Nothing shows up in the gutter (expected).
2. Reload the file with :reload. Still nothing in gutter (expected).
3. Edit the file. Edits show up as changes (unexpected!!)

Each time the file is reloaded, the diff base is set to the current file.

I have somewhat of a fix for this at d4a0e44. If the file is untracked, return early. If the file is new, return an empty base. Otherwise, continue as before.

I'm not really a fan of my implementation, since it relies on jj emitting a warning message if the file isn't found in the repo. Could do without that by doing a separate (jj file list).contains(file_relative_to_root), but I didn't want to add another jj invocation.

[bryceberger]

Was curious to see what an implementation using jj-lib would look like. Have a proof of concept at https://github.com/bryceberger/helix/tree/jj-lib (permalink: a8a105d). Needs better integration with helix's async code, doesn't solve custom backends. Otherwise seems to work.