Description
Hi,
Any plans to support migration from on prem Azure DevOps (git) to gitea?
I have tried and it just fails - possibly because authentication in azure devops is not using basic authentication but something else?
It just logs:
May 19 18:15:27 git gitea[687]: #033[36m2022/05/19 18:15:27 #033[0m#033[32m...ervices/task/task.go:56:#033[32mhandle()#033[0m #033[1;31m[E]#033[0m Run task failed: #033[1mAuthentication failed: Clone: exit status 128 - fatal: Authentication failed for 'http://devops.root.dom/ROOT/common/_git/Helm/'
I am 100% certain that the username/password combo is correct, since I use it on a daily basis - and also can access the repo from another service - using the exact same combo.
I also have this in my app.ini
[migrations]
ALLOW_LOCALNETWORKS = true
My guess is that it is probably because I have a "special" character in my password and when I turn on debug logging I can see the url it tries to clone - and if I copy/paste that URL and do a manual git clone from the prompt - I also get the same:
fatal: Authentication failed for 'http://devops.root.dom/ROOT/common/_git/Helm/'
If I do a
git clone http://root%[email protected]/ROOT/common/_git/Helm
And manually type in the password - it just works.
I have no idea if its some kind of escaping that happens that messes up the http request inside git - or if its simply wrongly escaped from gitea's side.
Do I just have to accept this?
According to "people" on the internet, then it seems to have been escaped correctly according to https://en.wikipedia.org/wiki/Percent-encoding - but no dice - I have used other systems in the past that did not like my password.
To give a hint about what character that messes it up - its #
- which I know is bad in a url - but I refuse to change my password just because some systems do not like it.
wget on the other hand just accepts the encoded url - so I am beginning to think its a bug in git.
Edit:
Just tested on a windows machine and git clone just works with the encoded url (git version 2.33) - on the gitea server (Rocky Linux) - git version 2.27.0 it fails - so either its a bug that is fixed in 2.33 - or an OS issue that is causing this.
Edit2:
Updated git to version 2.31 on the server - and its the same issue. So I am thinking its a git on linux issue.
Originally posted by @bjornbouetsmith in #8689 (comment)