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