huzhifa/skill-git-push
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: add remote Linux Gitea authentication flow

Browse Source
This commit is contained in:
zoukai
2026-09-03 15:12:06 +08:00
parent 72c856975e
commit 4612b4357d
4 changed files with 119 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
skills/updating-gitea-repositories/SKILL.md
+8 -1
View File
@@ -1,6 +1,6 @@
---
name: updating-gitea-repositories
description: Use when publishing or updating prepared files in a Gitea repository over HTTPS on macOS or Windows, especially when Git Credential Manager, Personal Access Token authentication, empty repositories, existing clones, or push verification are involved.
description: Use when publishing or updating prepared files in a Gitea repository over HTTPS on macOS, Windows, WSL, or Linux, including remote Linux desktops, Git Credential Manager, Personal Access Token authentication, SSO/OIDC web login, empty repositories, existing clones, and push verification.
---
# Updating Gitea Repositories
@@ -14,11 +14,14 @@ Publish only the intended changes to a Gitea repository through HTTPS, Git Crede
1. Always read [repository workflow](references/repository-workflow.md).
2. On macOS, also read [macOS GCM setup](references/macos.md).
3. On native Windows or WSL, also read [Windows GCM setup](references/windows.md).
4. On native Linux, including Linux controlled through a Windows remote desktop, also read [Linux GCM setup](references/linux.md).
## Core Contract
- Require a clean Gitea HTTPS URL, exact prepared source paths, intended repository paths, target branch, and commit intent. Infer only what the active task makes unambiguous.
- Verify GCM by executing its version command. When it succeeds, reuse that installation without install, reinstall, or upgrade actions. Install only when no working GCM exists; repair only when installation records exist but the executable does not.
- Select setup instructions from the operating system where the Git process runs. A Windows computer used only to control a remote Linux desktop does not make that Git session Windows or WSL.
- Treat web SSO/OIDC login and Git HTTPS authentication as separate unless the Gitea instance explicitly documents an integrated Git flow. The web login can be used to create a PAT; it does not by itself authorize a command-line push.
- The user creates a Gitea PAT with `write:repository`. The user enters the Gitea login and PAT only in a local GCM prompt. Never request or expose a PAT in chat, URLs, environment variables, command arguments, logs, or files.
- Preserve unrelated work. Stage only exact task paths; never use unscoped `git add .` or `git add -A`.
- Before committing, set the user-confirmed identity only in the target repository:
@@ -37,6 +40,8 @@ Publish only the intended changes to a Gitea repository through HTTPS, Git Crede
|---|---|
| GCM version works | Reuse it unchanged |
| Installer record exists but command fails | Repair or reinstall GCM |
| Git runs on a remotely controlled Linux host | Use the Linux instructions |
| Linux Secret Service has no graphical session | Use a repository-local GCM memory cache |
| HTTPS remote has no refs | Initialize the confirmed default branch |
| Remote has history | Clone or fetch before writing |
| Dirty changes overlap task paths | Stop or use a clean clone/worktree |
@@ -50,6 +55,8 @@ Publish only the intended changes to a Gitea repository through HTTPS, Git Crede
- Trusting package-manager state instead of running the GCM version command.
- Treating a PAT as ordinary text.
- Assuming a successful browser SSO/OIDC login also authenticates Git HTTPS.
- Applying Windows or WSL setup to Git that actually runs on a remote Linux host.
- Staging the whole worktree for a narrow update.
- Treating push rejection as permission to force-push.
- Reporting the local commit without remote SHA verification.