Repositories and pull requests

A native repository is a git repository on Overlane, tied to one project. You can create it with no GitHub account. Every step below is also an API call; the CLI uses the same public API and contracts.

Create a repository and push

overlane repo create app
overlane repo token app --scope write --ttl 3600

repo create starts the default branch with a README commit unless you pass --no-seed. The remote URL carries no credential. repo token mints a token bound to this repository, a scope (read or write), your principal and an expiry, and shows it once; give it to a git credential helper or send it as an Authorization header. A token is never stored in a remote URL or a file in the working copy, and the service stores only its digest. A token minted for one repository, or by another person, is refused elsewhere, and repo token revoke ends it at once.

Clone and push with git

Every native repository is also a standard smart HTTP remote at git.overlane.app. The URL names the team, the project and the repository, and overlane repo show prints it:

git clone https://git.overlane.app/<team>/<project>/app.git
cd app
git switch -c feature/login
git push -u origin feature/login

Git asks for a user name and a password. The user name is ignored; the password is an Overlane credential:

• an agent token from repository sign-in, a CLI session or a team API key, which act with the role and project scope they already have;
• a repository git token from overlane repo token, which is bound to one repository, a scope (read or write) and the principal that minted it.

To keep a credential out of the URL and out of shell history, store it in a git credential helper, or send it as a header for one command: git -c http.extraHeader="Authorization: Bearer $TOKEN" clone <url>. The remote URL never carries a credential.

The front checks the same rules as an API push, on the server. It reads the pack itself before anything is stored, so a refused push leaves nothing behind:

• A viewer can clone and cannot push; a project-scoped agent token reaches its own project only; a token from another team is refused without saying whether the repository exists.
• A push to a protected branch is refused with the reason and the command that opens a pull request instead. Deleting a protected branch or the default branch is refused too.
• The read-only side of a mirror refuses pushes and names the writable side.
• The guardrail rules run for the branch and for the paths the push changes, judged from the pack before it is stored. A force-push (a new tip that does not descend from the old one) is detected and judged as a force-push. A new file or an added line that carries a credential is refused, in any commit of the push, even one a later commit removes; the answer names the file, line and rule but never prints the key. A refused push stores nothing and no refused branch ever exists. As a second check, the same rules run again once a push is stored, and a branch that fails there is put back where it was.
• Native repositories hold branches. A push of a tag is refused with that message.

A refused push ends with ! [remote rejected] and a remote: message that names the rule. A push that is allowed is recorded as an event, so pull requests follow the branch, CI runs and the review service posts, as for an API push.

A push is inspected in memory, up to 64 MiB of pack and unpacked content. A larger push is refused with a message that says why and how to split it: push the older commits first (git push origin <older-commit>:refs/heads/<branch>), then the rest. A push whose pack leans on objects the server cannot read is refused with the advice to retry with git push --no-thin.

Limits: a repository holds at most 1 GB, and a push that would pass the room left in it is refused with 413 before it is stored; the same limit applies to a push with no declared length, which stops once it passes the room. A single push may update at most 100 branches. Tags, signed pushes (--signed) and the dumb HTTP protocol are not served.

Without a git binary, an agent or script can commit files through the API:

overlane repo branch create app feature/login
overlane repo push app --branch feature/login --message "Add login" --file src/login.ts

A push is checked on the server before anything lands: the read-only side of a mirror, branch protection, the guardrail rules and a scan of the pushed files for credentials. A credential in a file is refused, and the answer names the file and rule but never prints the key.

Pull requests

overlane repo pr open app --head feature/login --title "Add login"
overlane repo pr show app 1
overlane repo pr review app 1 --state approved --body "tests cover the new paths"
overlane repo pr merge app 1 --method squash

Opening a pull request starts two things on their own. The review service reviews it, with deterministic checks first and an optional model pass second, and posts inline comments and one summary that it updates on each push. CI runs the pipeline for the head commit when the repository has a pipeline file.

pr show lists the reviews, the required checks and every reason a merge is blocked. A review is recorded against the head it saw, so a push after an approval makes that approval stale and the answer says so. The author cannot approve their own pull request; another person or an independent agent does.

Protect a branch

overlane repo protect app --branch main --approvals 1 --check unit_tests
overlane repo protection app

A protected branch takes changes only through a pull request that has the approvals on its current head and the named CI jobs passed. Force-push is never allowed on it. Setting protection is a policy change: under supervised autonomy it waits for an approval. An agent’s push or merge into a branch like main waits for an approval even without a protection rule: the platform guardrail rule holds it, the answer exits 6 and names the command that answers the approval.

Roles

Roles are checked on the server for every request. A viewer’s write returns 403 with the rule that refused it.

Events and idempotency

Every push, branch change, pull request change and merge writes an event with an idempotency key, a per-repository sequence number and the commit SHA, so a consumer applies each event once and in order. Every write takes a request ID, and repeating the request returns the stored result instead of acting twice.

When native repositories are paused

If the git host is unavailable the project falls back to GitHub-only mode. Creating a repository then answers that native repositories are paused and points to connecting GitHub; pull requests, CI and deploys keep working on the GitHub repository. Native repositories return when the host does.

Command reference: repo create, repo token, repo push, repo pr open, repo pr review, repo pr merge and repo protect.