Add compatibility with jj (Jujutsu VCS)

[chicks-net]

Summary

gh-observer currently assumes the user is working in a git repository and relies on gh pr view for auto-detecting the current PR. Users of jj (Jujutsu) — a Git-compatible VCS — may hit issues because jj's internal working copy model differs from git's, even though jj interoperates with git remotes.

Problem Areas

1. PR auto-detection fails (GetCurrentPR / GetCurrentPRWithRepo)

Both functions in internal/github/pr.go shell out to gh pr view --json number,url, which in turn inspects the current git branch. jj doesn't create a traditional git working tree or HEAD ref in the same way, so gh pr view may fail or return unexpected results.

• GetCurrentPR() — line 32
• GetCurrentPRWithRepo() — line 83

2. Remote URL parsing may fail

parseOwnerRepoFromURL() in internal/github/pr.go:106 reads git remote origin via the git config. jj can work without a traditional .git directory structure, so remote discovery could break.

3. Branch model assumptions

jj uses a "working copy commit" model instead of git branches. The concept of "current branch" maps differently, which affects any logic that assumes a 1:1 mapping between a branch name and a PR.

Suggested Approach

• Detect when running inside a jj repo (e.g., check for .jj/ directory or jj on $PATH with jj root succeeding).
• When jj is detected, convert jj operations to equivalent git operations jj supports (e.g., jj git remote list instead of git remote -v, jj log to determine the current change/branch).
• Alternatively, support a fallback where the user can explicitly pass --owner/repo or --pr-url when auto-detection fails (partially covered by existing positional args, but could be more ergonomic).
• Consider using jj's native jj git subcommands where they map 1:1.

Workaround

Users can currently work around this by passing a full PR URL or PR number explicitly:

gh-observer https://github.com/owner/repo/pull/123
gh-observer 123

References

• Jujutsu VCS
• jj and git interoperability docs

[chicks-net]

@claude I'd rather not install jj locally at this time. What testing options do we have such as podman containers or github actions?

[claude]

Claude finished @chicks-net's task in 1m 10s —— View job

---

Testing Options for jj Compatibility

• Gather context (reviewed CI workflows and Go test patterns)
• Research jj installation options in containers/CI
• Propose testing strategies

---

Good news: you have several solid options, and GitHub Actions is the cleanest fit for this project.

Option 1: GitHub Actions (Recommended)

jj ships pre-built Linux binaries on each GitHub release, so installation in CI is a one-liner — no Rust toolchain needed:

- name: Install jj
  run: |
    JJ_VERSION=0.27.0
    curl -sSL "https://github.com/jj-vcs/jj/releases/download/v${JJ_VERSION}/jj-v${JJ_VERSION}-x86_64-unknown-linux-musl.tar.gz" \
      | tar -xz -C /usr/local/bin jj

A dedicated jj-compat.yml workflow could:

1. Install jj and gh CLI
2. Create a jj repo colocated with git: jj git init --colocate
3. Add a GitHub remote and attempt gh-observer auto-detection
4. Verify the right error/fallback behavior

This fits naturally alongside the existing ci.yml which already runs on ubuntu-latest.

Option 2: Go Unit Tests (No jj Binary Needed)

Most of the detection logic can be tested in pure Go without jj installed at all. The key functions to cover:

• .jj/ detection — pure filesystem check, testable with os.MkdirTemp
• GetCurrentPR fallback behavior — the current code shells out to gh pr view; if we refactor to accept an injectable command runner (a common Go pattern), we can simulate jj's failure modes without any VCS installed
• Remote URL parsing — already well-covered in pr_test.go

This approach would live in internal/github/pr_test.go alongside the existing tests and run in CI with no extra setup.

Option 3: Podman/Docker (Local or CI)

A Dockerfile.test-jj with jj installed would work locally if you ever need interactive debugging:

FROM ubuntu:24.04
RUN apt-get update && apt-get install -y curl git gh
RUN curl -sSL "https://github.com/jj-vcs/jj/releases/download/v0.27.0/jj-v0.27.0-x86_64-unknown-linux-musl.tar.gz" \
    | tar -xz -C /usr/local/bin jj

But since gh-observer is already CI-first, GitHub Actions is simpler.

Recommended Approach

1. Start with unit tests — refactor GetCurrentPR to use an injectable executor and add tests for jj detection/fallback (no jj binary needed, runs in existing CI)
2. Add a GH Actions integration test — a separate workflow that installs jj and exercises real end-to-end behavior

The unit test refactor is where the real implementation work lives; the GH Actions test is the integration safety net.

---