Feature Request: Add Jujutsu (jj) repository support

[frittlechasm]

Summary

Would you be open to adding support for Jujutsu (jj) repositories?
Right now, reposcan skips .jj repos entirely, which makes it less useful for anyone who has adopted jj in their workflow.

Proposed Scope (Read-Only First)

A minimal first pass would not need to touch the TUI mutation flow at all. The useful surface area is:

• Detect .jj directories during filesystem walking
• Collect basic repo state (dirty files via jj diff --summary, current bookmark/change ID)
• Display jj repos in table and JSON output alongside Git repos
• Handle co-located repos (.git + .jj) with a clear precedence rule

This is intentionally scoped to read-only support first. Write operations (push/fetch) can come later once the read path is stable, since jj semantics differ from Git in meaningful ways (bookmarks vs branches, no direct pull equivalent, etc.).

Non-Goals (for now)

• TUI push/pull/fetch actions for jj
• Perfect Git-equivalent ahead/behind semantics (jj doesn't map cleanly)
• Any changes to existing Git behavior

Notes

• If jj is not installed, the scanner should degrade gracefully and continue scanning Git repos normally

Happy to contribute an implementation if you're open to it.
Thanks for the great tool !

[frittlechasm]

I have been working on this and have a branch with an initial implementation: feat/jj-support
Would you be open to a PR for this? Happy to discuss the approach before submitting.

[mabd-dev]

Thanks for suggesting this @frittlechasm

I have heard about jj but did not try it out myself. I don't mind supporting it in reposcan but first, I have to learn and use for a while to be able to make it officially supported in the tool. This is going to take some time given all the things I am doing in my life

What I can do, open a branch from dev, make it always synced with dev but also have all jj features. Later once it's stable we can release it officially to public
Does this make sense ?

[frittlechasm]

Makes sense.

[mabd-dev]

@frittlechasm Alright, your plan looks solid. Can you create a PR to feat/jjSupport branch

[frittlechasm]

Raised an initial PR for read-only jj repository support : #31

Completed

• Created a VCS abstraction so RepoScan can handle more than Git.
• Detects jj repositories by .jj directories.
• Scans jj repos without mutating them.
• Reports jj repo metadata: path, repo name, VCS type ( in JSON report ), bookmark/change display, uncommitted file summaries, outgoing tracked bookmark commits
• Maps jj outgoing commit count into RemoteStatus.Ahead, so dirty and unpushed filters work for jj repos.
• Shows jj outgoing commits in stdout/TUI details.
• Added test coverage for jj detection, provider routing, dirty jj repos, outgoing commits, and missing binary behavior.

Missing :

• No jj fetch/push/pull support yet.
• No jj incoming/unpulled detection yet, so unpulled is not meaningful for jj repos.
• jj remote status is simplified to one synthetic entry instead of preserving remote/bookmark-level status.
• TUI repo actions still call Git-specific functions directly.
• TUI refresh still uses Git-specific refresh logic, not the VCS provider abstraction.
• Details view does not show jj-specific states like incoming commits, remote/bookmark grouping, conflicts, divergent bookmarks, or other jj metadata.
• README/docs still need to describe jj support and its current limitations.

[mabd-dev]

@frittlechasm first step of jj support is done.

[frittlechasm]

Follow-up PR #38 is now ready for review with:

• Incoming/unpulled detection for jj (enables --filter unpulled)
• Per-bookmark remote status
• VCS column in table and TUI
• VCS-agnostic TUI actions (fetch enabled, push/pull deferred for unified implementation)
• Better error messages and integration tests
• README/docs update

Still pending / Deferred:

• jj fetch/push/pull support is deferred until we target it across both git and jj
• TUI fetch/push/pull wiring for jj (semantics need definition)