| 1 | --- |
| 2 | title: Transferring a repository |
| 3 | description: Move a repository to another workspace you own, with its issues, pull requests, deployments and history, while its old address keeps working. |
| 4 | --- |
| 5 | |
| 6 | Transferring moves a repository from one workspace to another. It keeps its |
| 7 | name, and everything in it moves with it. Its address changes from |
| 8 | `g1t.sh/<old>/<repo>` to `g1t.sh/<new>/<repo>`, and the old address keeps |
| 9 | working as a redirect. |
| 10 | |
| 11 | To change only its name and keep it in its workspace, |
| 12 | [rename it](/guides/managing-repositories/#rename-a-repository) instead; |
| 13 | its old address redirects the same way. To be rid of a repository rather |
| 14 | than move it, [delete it](/guides/managing-repositories/#delete-a-repository). |
| 15 | |
| 16 | ## Who can transfer |
| 17 | |
| 18 | You must be an **owner of both workspaces**: the one the repository is in |
| 19 | and the one it moves to. A member of either cannot, and neither can an |
| 20 | access token that belongs to a workspace or g1t's token. Your email |
| 21 | address must be confirmed. |
| 22 | |
| 23 | ## Transfer a repository |
| 24 | |
| 25 | 1. Open the repository's **Settings → Repository**. |
| 26 | 2. Under **Danger zone**, choose **Transfer**. |
| 27 | 3. Pick the workspace to move it to. Only workspaces you own are listed. |
| 28 | 4. Read what changes, type the repository's full name (`<old>/<repo>`) to |
| 29 | confirm, and choose **Transfer**. |
| 30 | |
| 31 | You land on the repository's settings at its new address. Everything kept |
| 32 | about it elsewhere in g1t (search, the context hub, deployments and the |
| 33 | rest) follows within a few seconds. |
| 34 | |
| 35 | From the API, call |
| 36 | [`POST /repos/{owner}/{name}/transfer`](/reference/api/repositories/transfer-repo/) |
| 37 | with the destination in `to`: |
| 38 | |
| 39 | ```sh |
| 40 | curl -X POST https://api.g1t.sh/repos/acme/rocket/transfer \ |
| 41 | -H "Authorization: Bearer $G1T_TOKEN" \ |
| 42 | -H "Content-Type: application/json" \ |
| 43 | -d '{"to": "acme-labs"}' |
| 44 | ``` |
| 45 | |
| 46 | Over MCP, it is the `repository` tool's `transfer` action, with `repo` and |
| 47 | `to`. A token's owner must |
| 48 | own both workspaces, as on the site. |
| 49 | |
| 50 | ## When a transfer is refused |
| 51 | |
| 52 | | Response | Why | What to do | |
| 53 | | --- | --- | --- | |
| 54 | | `403 forbidden` | You do not own one of the two workspaces, or you are using a workspace or agent token. | Ask an owner of both to transfer it, or use a personal token. | |
| 55 | | `409 conflict` | The destination already has a repository with that name, or a recently deleted one held it. | Rename or move that repository first, or purge the deleted one. | |
| 56 | | `402 payment_required` | The repository is private, the destination is on no plan, and its private repositories would hold more than a free workspace's 1 GB. | Start the g1t plan in the destination, or make the repository public first. | |
| 57 | | `422 invalid` | No destination, or the destination is the workspace it is already in. | Name another workspace. | |
| 58 | |
| 59 | ## What moves |
| 60 | |
| 61 | Everything that belongs to the repository moves with it: |
| 62 | |
| 63 | | | | |
| 64 | | --- | --- | |
| 65 | | Code | Every branch and tag. The git data does not move or copy; only the address changes. | |
| 66 | | Issues and pull requests | With their numbers, comments, reviews, labels, sessions and merge queue. | |
| 67 | | Workflows | Workflow runs, their jobs, logs and artifacts. | |
| 68 | | Deployments | The repository's project, its deployments and its custom domains. See [deployments](#deployments). | |
| 69 | | Its own settings | Merge rules, branch protection, guardrails, and the project's memory. | |
| 70 | | Its own secrets and variables | Set on the repository, they move with it. | |
| 71 | | Its own webhooks | They now name the repository by its new path. | |
| 72 | | Agents at work on it | Their runs carry on and are listed in the new workspace. | |
| 73 | |
| 74 | These belong to the old workspace and stay with it: |
| 75 | |
| 76 | | | | |
| 77 | | --- | --- | |
| 78 | | Workspace secrets and variables | The old workspace's stop reaching the repository; the new workspace's start, if they reach every repository or name this one. | |
| 79 | | Workspace webhooks | The old workspace's stop hearing about the repository; the new one's start. | |
| 80 | | Integrations | Model providers, Sentry, Datadog, Jira and Linear connections stay with their workspace. Connect them in the new one if you need them there. | |
| 81 | | Workspace memory and guardrails | The new workspace's apply from now on. | |
| 82 | | The audit log | What happened before the transfer stays in the old workspace's log. Each workspace's log records the transfer itself. | |
| 83 | | Billing history | See [billing](#billing). | |
| 84 | |
| 85 | ## Old addresses |
| 86 | |
| 87 | The old address keeps working, for as long as nothing else is made there: |
| 88 | |
| 89 | | | Behaviour | |
| 90 | | --- | --- | |
| 91 | | Web pages | A permanent redirect (`301`) to the same page at the new address, query string included. A private repository redirects only for people who can see it; anyone else gets a 404, as before. | |
| 92 | | `git clone`, `fetch` and `pull` | Redirected to the new remote. Git follows it and prints a warning each time. | |
| 93 | | `git push` | Redirected the same way: git asks for the push's refs at the old address, follows the redirect, and sends the push to the new one. | |
| 94 | | API and MCP | A call that names the repository by its old path runs against it at its new path. | |
| 95 | | `g1t.page` apps | The old app addresses redirect to the new ones for 90 days. | |
| 96 | |
| 97 | A redirect stops as soon as a repository is created at the old address, |
| 98 | whether by the site, the API or a push that creates one. Update your |
| 99 | remotes rather than relying on it: |
| 100 | |
| 101 | ```sh |
| 102 | git remote set-url origin https://g1t.sh/<new>/<repo>.git |
| 103 | ``` |
| 104 | |
| 105 | Update anything else with the old address in it too: links in READMEs, CI |
| 106 | configuration, API clients and MCP clients. |
| 107 | |
| 108 | If the old workspace is later [deleted](/guides/workspaces/#delete-a-workspace), |
| 109 | its name is never given to anyone else, so the redirects keep working. |
| 110 | |
| 111 | ## Deployments |
| 112 | |
| 113 | A `g1t.page` address ends in its workspace's name: production is at |
| 114 | `<project>-<workspace>.g1t.page`. After a transfer, each of the project's |
| 115 | apps (production and every open preview, including one paused by the old |
| 116 | workspace's usage limit) is built again from the same commit under the new |
| 117 | workspace's name. The old address keeps serving until the new one is live, |
| 118 | then redirects to it for 90 days, whatever the old workspace's plan or |
| 119 | limit. Custom domains move with the project and serve the new build. |
| 120 | |
| 121 | From the transfer on, the apps are the new workspace's: its plan and usage |
| 122 | limit decide whether they build and serve. If the new workspace cannot |
| 123 | build yet (Deployments are off, or it reached its limit), the rebuild waits |
| 124 | and is tried again until it can. |
| 125 | |
| 126 | ## Billing |
| 127 | |
| 128 | - Usage from the moment of the transfer is charged to the new workspace: |
| 129 | agent runs, builds, app traffic, git operations and storage. |
| 130 | - What the repository used before stays on the old workspace's bill. |
| 131 | Runs already under way finish on the bill they started on. |
| 132 | - Storage follows the repository: from the next daily count it is the new |
| 133 | workspace's private storage. |
| 134 | - A public repository's share of the open-source pool this month moves |
| 135 | with it. |