skill-git-push/skills/updating-gitea-repositories/SKILL.md

name, description

name	description
updating-gitea-repositories	Use when publishing or updating a Gitea HTTPS repository, reusing Git credentials across repositories, or diagnosing repeated GCM, PAT, OAuth, and credential-store authorization prompts on Windows, macOS, WSL, or Linux.

Updating Gitea Repositories

Publish only the intended changes, reuse valid credentials through a secure Git credential helper, keep secrets out of commands and logs, and verify the remote commit.

Required reading

1. Read repository workflow and credential persistence.
2. Read the platform reference for the machine running Git: Windows and WSL, macOS, or Linux.

Core contract

• Identify the clean HTTPS site and repository, account, source and destination paths, branch, and commit intent. Reuse information already established in the task.
• Prefer an existing valid credential for the same machine, system user, site, and account. Reuse it across repositories when their access permissions allow. Do not require a new PAT or a new login merely because this is a different repository.
• Inspect effective helper order, URL and path matching, account, and secure-store availability before modifying configuration. Change only the necessary site-specific current-user settings when authorized; preserve other sites and existing credential records.
• Never print, request in chat, or place tokens or passwords in URLs, command arguments, environment variables, logs, or project files. User-entered secrets belong in a trusted local authentication prompt.
• Diagnosis and migration must not erase or overwrite original credentials. Git can send erase after a failed authentication; use the read-only PAT probe in the credential reference or an equivalently verified get-only helper. Do not call git credential reject as a diagnostic.
• Use Windows Credential Manager, macOS Keychain, an unlocked Secret Service collection, or GPG/pass as appropriate. Git store, GCM plaintext, and the 15-minute memory cache are not persistent secure solutions.
• Retain PAT authentication. For users who sign in with OIDC, prefer a verified browser OAuth flow when supported; an OIDC account need not have a local password. Check the actual server, client, registration, scopes, secure store and refresh behavior; never put an OAuth client secret in Git configuration. Upgrade GCM only when a demonstrated feature requires a compatible version and the task authorizes it.
• Select the platform according to where Git runs. Web SSO alone does not establish Git authentication.
• Preserve unrelated work; stage exact task paths only. Never bypass TLS, hooks, branch protection, or non-fast-forward safety. Verify the pushed branch SHA after a successful push.

Quick decisions

State	Action
A matching secure credential already works	Reuse it without another login
Authentication fails	Diagnose configuration and server response without erasing the credential
A matching old plaintext entry can be copied safely	Copy to a new secure namespace; keep the old entry and disclose its plaintext copy
Linux has no unlocked graphical store	Set up persistent GPG/pass when authorized; allow for key unlock
The user signs in to Gitea with OIDC	Check the browser OAuth path in the credential reference before asking for a PAT
Required OAuth refresh is blocked by the installed version	Verify compatibility and update GCM only when authorized
Authentication truly requires a new credential	Have the user enter it in a trusted local prompt; never ask for the token in chat
Remote branch has advanced or protection rejects the push	Do not force; follow the repository workflow