feat(jj): add jj module to display repository status

[0xdeafbeef]

Description

Add jj status module, which shows basics info for jj repos.

Screenshots (if appropriate):

Change without branch

Change set to some branch

Change with description

How Has This Been Tested?

• I have tested using MacOS
• I have tested using Linux
• I have tested using Windows

Checklist:

• I have updated the documentation accordingly.
• I have updated the tests accordingly.

[0xdeafbeef]

The only unresolved message is how to make jj module mutual exclusive to git module - show only jj status if it's available, otherwise show git* modules.

[folliehiyuki]

My suggestion: provide an option to prefer status from jj or from git than the other.

Implementation: we can get the repo root with jj root. Inside that directory, if both .jj and .git directories exist, the user (using the above configuration option) will get either the status from 1 of the 2 VCS backends.

[0xdeafbeef]

My suggestion: provide an option to prefer status from jj or from git than the other.

Implementation: we can get the repo root with jj root. Inside that directory, if both .jj and .git directories exist, the user (using the above configuration option) will get either the status from 1 of the 2 VCS backends.

I think it's possible to filter the git module's output if jj is present here, but a better mechanism can be implemented.

[davidkna]

Is it possible to get this jj status through git, to avoid duplication and perhaps external command spawning?

[0xdeafbeef]

Is it possible to get this jj status through git, to avoid duplication and perhaps external command spawning?

Sadly, no. JJ maintains its own database in the .jj directory, and manually parsing it is not a trivial task. Moreover, JJ can be used without a Git repository. However, JJ can also be used as a library.

[0xdeafbeef]

I'm daily driving it for a week, haven't found any problems. It resolves in 90ms even it linux repo.

Here are the timings of modules in your prompt (>=1ms or output):
git_status  -  106ms  -   "[?]"
jj_status   -   87ms  -   "[🍐 kyysvqks 8fbd179b on <no branch> 📝]"
directory   -   <1ms  -   "linux "
git_commit  -   <1ms  -   "(374a7f4) "
line_break  -   <1ms  -   "\n"
character   -   <1ms  -   "❯ "

[0xdeafbeef]

Hi, I was wondering if someone could take a look at this PR when you have a chance. Thank you!

[davidkna]

However, JJ can also be used as a library.

I would rather avoid that as long as it still depends on git2.

In general regarding the module, I would prefer if the module here was named and structured in line with other starship vcs modules for git/hg/fossil.
Starship doesn't provide general vcs modules at this time, but it would be nice for the modules to follow a common structure.

[poliorcetics]

However, JJ can also be used as a library.

Even if gitoxide was used instead inside JJ, there would still be the problem of future or private backends, which jj-lib won't be aware of if statically compiled in starship. As long as there is no dynamic loading or discovery of some sort, using the CLI is more future-proof

[0xdeafbeef]

@davidkna, do you want me to refactor this PR to match the structure of #5814? I can do that, but I'm still unsure about how to handle output that conflicts with Git. For example, if we break down the jj status into several modules like we do with Git, the Starship prompt will display [master][⎇ master] for both jj and Git outputs. With the current grouping, it doesn't look as strange:
[🍐 tknkszzp 56b48ad0 on master*][⎇ master]

[poliorcetics]

I think we could introduce a config to say "disable git if jj is present", since if both are there, jj is very probably the one wanted by users.

Something like

[jj]
disable-git = true

there are several cases as a result:

1. No Git, no JJ: nothing
2. Git, no JJ: normal git modules
3. No Git, JJ enabled, JJ: normal jj module(s)
4. Git, JJ enabled, JJ: both git and jj modules
5. Git, JJ enabled, JJ, git-disabling: only jj module(s)

[poliorcetics]

If we make the JJ module disabled by default (or not in the default status line) the cost of checking should be one easily cached boolean

[0xdeafbeef]

@davidkna, do you want me to refactor this PR to match the structure of #5814? I can do that, but I'm still unsure about how to handle output that conflicts with Git. For example, if we break down the jj status into several modules like we do with Git, the Starship prompt will display [master][⎇ master] for both jj and Git outputs. With the current grouping, it doesn't look as strange: [🍐 tknkszzp 56b48ad0 on master*][⎇ master]

@davidkna can you please comment on this?

[poliorcetics]

Maybe what we need is not separate modules per VCS but instead a single "VCS" module with a behavior like this:

[vcs]
# Order in which the VCSs are tried for the current directory.
# The first successful one is picked
order = [
  "jj",
  "git",
  "pijul",
  # ...
] # The default would be git first probably, to make the first check successful for most people ?

# and the final status line would replace the whole "$vcs" module with the relevant format
jj_format = "jj: $jj_change$jj_status"
git_format = "git: $git_branch$git_state"

People could then still configure their modules independently and (de)activate one by one but the final statusline would only ever display one VCS.

If they want several VCS, they could still directly use the relevant modules in the directly in the overall statusline

What do you all think ?

[davidkna]

@0xdeafbeef Please do split the module up.

[Nemo157]

Suggested change

	[jj]
	[jj_status]

The docs here are out of sync with the code. Also needs changing in the initial prose.