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
| Flag | Description |
|---|---|
-d, --description <text> | Repository description |
--public | Make the repository public (default) |
--private | Make the repository private |
Via API
Cloning Repositories
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
| Aspect | Git Branches | jj Bookmarks |
|---|---|---|
| Identity | Tied to commit hash | Tied to stable Change ID |
| Rebase | Changes the hash | Change ID persists |
| Tracking | Implicit (remote tracking) | Explicit (push/pull) |
| Default | main or master | main (configurable) |
Managing Bookmarks
Bookmark Protection
Protect important bookmarks with rules that gate landing:API Endpoints
| Method | Endpoint | Description |
|---|---|---|
GET | /api/repos/:owner/:repo/bookmarks | List bookmarks |
POST | /api/repos/:owner/:repo/bookmarks | Create a bookmark |
DELETE | /api/repos/:owner/:repo/bookmarks/:name | Delete a bookmark |
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:Change IDs in the API
Changes are accessible via API endpoints that use the stable Change ID:| Method | Endpoint | Description |
|---|---|---|
GET | /api/repos/:owner/:repo/changes | List changes |
GET | /api/repos/:owner/:repo/changes/:change_id | Get a change |
GET | /api/repos/:owner/:repo/changes/:change_id/diff | Get the diff |
GET | /api/repos/:owner/:repo/changes/:change_id/files | List files in change |
GET | /api/repos/:owner/:repo/changes/:change_id/conflicts | List conflicts |
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
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.- 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
--archivedto include)
API Endpoints
| Method | Endpoint | Description |
|---|---|---|
POST | /api/repos/:owner/:repo/archive | Archive a repository |
DELETE | /api/repos/:owner/:repo/archive | Unarchive a repository |
Repository Transfer
Transfer moves a repository from one owner to another (user-to-org, org-to-user, or org-to-org).- The repository URL changes (e.g.,
alice/my-repobecomesacme-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.
API Endpoint
| Method | Endpoint | Description |
|---|---|---|
POST | /api/repos/:owner/:repo/transfer | Transfer a repository (body: {"new_owner": "acme-org"}) |
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.API Endpoints
| Method | Endpoint | Description |
|---|---|---|
GET | /api/repos/:owner/:repo/keys | List deploy keys |
POST | /api/repos/:owner/:repo/keys | Add a deploy key |
GET | /api/repos/:owner/:repo/keys/:id | Get a deploy key |
DELETE | /api/repos/:owner/:repo/keys/:id | Delete a deploy key |
File Content Access
Access file contents via the API:API Endpoints
| Method | Endpoint | Description |
|---|---|---|
GET | /api/repos/:owner/:repo/contents/:path | Get file or directory contents |
GET | /api/repos/:owner/:repo/git/trees/:sha | Get a git tree |
GET | /api/repos/:owner/:repo/git/commits/:sha | Get a git commit |
GET | /api/repos/:owner/:repo/git/refs | List git refs |
Operation Log
jj maintains an operation log of every repository operation. This provides a full audit trail and enables undo:| Method | Endpoint | Description |
|---|---|---|
GET | /api/repos/:owner/:repo/operations | List jj operations |
Full Repository API
| Method | Endpoint | Description |
|---|---|---|
GET | /api/repos/:owner/:repo | Get repository |
POST | /api/user/repos | Create user repository |
POST | /api/orgs/:org/repos | Create org repository |
PATCH | /api/repos/:owner/:repo | Update repository |
DELETE | /api/repos/:owner/:repo | Delete repository |
Next Steps
- Stacked Changes — work with stacked changes
- Landing Requests — submit changes for review
- Workflows — automate CI and AI workflows
- jj Crash Course — learn jj fundamentals