文章目录
-
- [gitea - fatal: Authentication failed](#gitea - fatal: Authentication failed)
- 概述
- 笔记
- 删除windows凭证管理器中对应的url认证凭证
- 启动gitea服务端的命令行
- [正常用 TortoiseGit 提交代码](#正常用 TortoiseGit 提交代码)
- 备注
- END
gitea - fatal: Authentication failed
概述
本地的git归档服务端使用gitea.
原来的用法就一个大库，用了许久后，git操作的速度就慢了，还有报错提示(e.g. 健康检查超时之类)。
现在新的库(e.g. myPKM)就采用开小库, 但是git服务还是3000端口。
自己写了git库模板，对于每个库只要在模板上将路径改了，让gitea的工作目录对应不同的库目录就行，还是挺方便的。
现在有个新问题，这样用之后，如果在不同库之间切换, 需要关掉上一个gitea服务，然后开启新库的gitea服务。
run_gitea_on_my_pkm.bat
bash
@echo off
rem run_gitea_on_my_pkm.bat
set PATH=C:\Program Files\Git\bin;C:\Program Files\Git\cmd;C:\soft\gitea;%PATH%
call gitea --work-path E:\my_git_rep\rep_my_pkm\my_pkm但是提交时，因为url是一样的(e.g. AppURL(ROOT_URL): http://localhost:3000/), 但是每个库的登录token不一样了，导致下一个库提交时，用的还是上一个库的认证token. 提交没问题，但是在push时报错如下：
这个问题的原因是，windows凭证管理器已经保存了gitea认证信息，认证信息的key是根据url。
如果像我这么用gitea(不同库都是一个url, 只是要独立启动单独的不同的gitea命令行)，就会出现认证失败的问题。
对于由于同一个url引起的认证缓存(凭证)问题，导致认证失败，解决方法如下，任选：
方法1. 将gitea模板改了，让不同库使用不同的端口(e.g. rep1 use port 3000, rep2 use port 3001)
方法2. 如果本次要使用的库和上次不同(e.g. 上次正常提交了rep1, 现在要提交的是rep2), 在提交之前，去windows凭证管理器中，将这个url对应的凭证删掉，然后再启动rep对应的gitea命令行脚本。
考虑到自己的使用情况，并不会频繁切换不同的库(也就每一天结束时，要保存进度，才会启动gitea，进行入库)，一天最多几次push操作。
那么我就采用方法2，也不是很麻烦。
笔记
删除windows凭证管理器中对应的url认证凭证
因为gitea服务端就用3000端口的url, 看到3000端口的url删掉就行。
一般同一个url的认证凭证就一个。
启动gitea服务端的命令行
这没啥要记录的。
正常用 TortoiseGit 提交代码
当前用的是 TortoiseGit 2.17.0.1
add, commit 都是项目目录的git本地操作，不会涉及到远端，也就不会引发认证操作。
然后push,就会触发认证操作。
此时，在浏览器中弹出gitea网页端登录操作页面。
输入自己配的库用户名和口令，选择登录
点击"应用授权"按钮。
网页端认证成功了，关掉此网页。
此时，再回到TortoiseGit的push的UI, 就会看到在认证之后在push东西，直到成功。
备注
以前用一个大库，一直正常用。
直到前1个月开始出现认证失败消息，只能暂时强行push, 能行，但是感觉很怪啊。
昨天才反应过来，确认是不同git库之间提交切换时，我的不同库的url都是一个引起的问题。
如果不是频繁的切换git库，用删除windows凭证的方法，也算方便，能接受。
建议这种情况，提交时，就只add + commit. 等当天结束了，再统一启动不同库的gitea命令行，进行push.
如果每次开新的小库，去将gitea服务端口搞成不同的，也是可以的。看自己情况。
如果要求绝对安全或者和同事间要协同，就用改port这种方法，每次都add, commit, push 一条龙。