Skip to main content

Repositories

Repositories are the core unit of JJHub. They store your code, track changes via jj, and host landing requests, issues, workflows, and more. JJHub repositories are jj-native — they use bookmarks instead of branches, stable Change IDs instead of commit SHAs, and first-class conflict tracking.

Creating Repositories

Via CLI

Via API

Cloning Repositories

The jjhub repo clone command clones via your preferred git protocol (SSH or HTTPS, configurable with jjhub config set git_protocol). After cloning, you work with standard jj commands.

Listing and Viewing

Bookmarks

Bookmarks are jj’s replacement for git branches. They are named pointers to changes, and they are the primary reference type in JJHub.

Key Differences from Branches

Managing Bookmarks

Bookmark Protection

Protect important bookmarks with rules that gate landing:
See the Landing Requests guide for full details on protection rules.

API Endpoints

Changes & Change IDs

Changes are the fundamental unit of work in jj. Every edit you make creates a change with a stable Change ID that persists across rebases, amends, and rewrites.

Viewing Changes

How Change IDs Work

Unlike git commit hashes, which change every time you amend or rebase, jj Change IDs are stable:
This stability is what makes landing requests, stacked changes, and CI statuses work seamlessly. A landing request tracks changes by their stable IDs, so amending or rebasing automatically updates the LR.

Change IDs in the API

Changes are accessible via API endpoints that use the stable Change ID:

Repository Settings

Visibility

Repositories can be public or private:
  • Public: Visible to everyone, cloneable without authentication
  • Private: Visible only to the owner, org members with access, and explicit collaborators
Change visibility via the API:

Topics

Topics tag your repository for discoverability:

Stars

Star a repository to bookmark it and show appreciation:

Repository Archiving

Archiving puts a repository into a read-only state. No pushes, no new issues, no new landing requests, and no new workflow runs are accepted. The repository remains cloneable and browsable for reference.
Who can archive/unarchive: repository owner, organization owners (for org-owned repos), and platform admins. What archiving does:
  • Repository becomes read-only (no pushes, no new issues/LRs/workflows)
  • Existing data is fully preserved and browsable
  • Repository is filtered from default listings (use --archived to include)

API Endpoints

Repository Transfer

Transfer moves a repository from one owner to another (user-to-org, org-to-user, or org-to-org).
What happens during transfer:
  • The repository URL changes (e.g., alice/my-repo becomes acme-org/my-repo). The old URL redirects for a grace period.
  • All collaborators, issues, landing requests, workflows, webhooks, stars, and watches are preserved.
  • The target user or org owner may need to accept the transfer.
Who can transfer: repository owner, organization owners (for org-owned repos), and platform admins.

API Endpoint

Deploy Keys

Deploy keys are SSH keys scoped to a single repository. They are useful for CI/CD pipelines and deployment automation where you need repository access without a personal account.
See the Deploy Keys guide for detailed usage and security best practices.

API Endpoints

File Content Access

Access file contents via the API:

API Endpoints

Operation Log

jj maintains an operation log of every repository operation. This provides a full audit trail and enables undo:

Full Repository API

Next Steps