administration/repositories.md
at 55a1b0bRepository settings
Manage repository details and access
A repository contains code and its change history. These settings control its description, visibility, and owner or name.
Repository owner — The user or organization in the owner/repository address.
Management permission — Permission to change repository settings. A personal namespace owner or organization owner/admin can have this permission.
Repository policy — The nerudo.toml rules for repository membership, approval keys, checks, and approval requirements.
Management permission does not replace repository policy. It does not automatically give private code access or approval rights.
Before you start
Your account must have management permission for changes to repository settings. Sign-in confirmation lasts five minutes.
OWNER and REPO are placeholders for the owner and repository names. General settings use /OWNER/REPO/settings/general.
- Open the repository in Nerudo.
- Select Settings.
- Select General, Access, Governance, or Developer access.
Users without management permission can see only the settings available to their accounts. Missing controls do not indicate approval authority.
Change the description
- Open General.
- Confirm your sign-in if the previous confirmation has expired.
- Change Description.
- Select Save settings.
The description has a maximum of 300 characters on one line. Nerudo shows the saved description after the page reloads.
Change visibility
Public — Users can read the repository without sign-in.
Private — Users must have repository permission to read the repository.
A visibility change cannot remove copies that other users already have.
- Open General.
- Confirm your sign-in if necessary.
- Under Visibility, select Private or Public.
- Select Save settings.
- If you selected Public, confirm the public access notice.
Nerudo updates the repository visibility. The page shows the selected state.
A visibility change does not add approval keys or change approval requirements.
Examine repository access
- Open Access.
- Select Open nerudo.toml.
The file lists repository approvers, public keys, and roles. The account and key must satisfy repository policy for the applicable operation.
Organization membership is separate from this policy. Removing an organization member does not remove their repository policy role.
To change policy membership:
- Make the necessary change in the repository policy file in your local repository.
- Open a pull request for the change.
- Get the necessary approvals for the policy change.
The policy change takes effect through the normal repository process. The Access page does not bypass that process.
Examine governance
- Open Governance.
- Select Open nerudo.toml.
The file defines the checks, approval keys, roles, and approval requirements for changes.
A policy change uses a pull request and the applicable approval process. An organization role or developer credential cannot replace an approval signature.
GPG ownership verification does not give approval rights. See Signing keys for the separate approval-key procedure.
Transfer or rename a repository
A transfer can change the repository owner or name. The target owner must already exist.
You must have management permission for the source owner and target owner. The target owner/repository name must be available.
Source repository — The owner/repository address before transfer.
Target repository — The proposed owner/repository address after transfer.
- Open the source repository's General settings.
- Confirm your sign-in if necessary.
- Open Transfer repository.
- Enter the existing owner name in Target owner.
- Enter the repository name in Target repository name.
- Enter the exact source
owner/repositoryin Type owner/repository to confirm. - Select Transfer repository.
- Confirm the source and target names in the dialog.
The target repository name uses 1–100 letters, digits, periods, underscores, or hyphens. It cannot be . or .. or end with .git.
Nerudo opens settings at the new repository address. The repository keeps its history, visibility, and repository policy.
Existing repository membership and approval keys stay in place. Target organization membership does not replace them.
The source repository address no longer identifies this repository. Links and local Git remotes must use the new address.
Transfer revokes all developer credentials for the source repository address. A credential for several repositories stops in all of them.
The revocation applies to credentials from all users, not only the person who transfers the repository.
After transfer:
- Update links to use the new repository address.
- Update your local Git remote to use the new repository address.
- Make new developer credentials in the target repository settings, if necessary.
- Give each tool its new developer credential.
See Developer access for credential setup and revocation.
Developer access
Developer access makes a personal credential for this repository. The form fixes the repository name.
The selected read/comment operations and your account permissions control its access. The credential does not give Git push, landing, or approval rights.
An organization overview links to repository credential settings. Account Authorized tools shows your credentials across repositories.
When a change fails
| Result | Next step |
|---|---|
| Sign-in confirmation expired | Confirm your sign-in on the same settings page. |
| Management permission missing | Ask an organization owner or namespace owner to review access. |
| Target owner does not exist | Create the target organization first or use an existing owner. |
| Target name is taken | Choose a different target repository name. |
| Repository policy is not available | Ask a repository maintainer to examine the policy file. |
Permanent repository deletion and archive are not available in these settings.