I had recommended Gitea to a team. They installed it on Windows 10 (the client insisted on Windows). They then reported that the UI would only create empty repositories and hit a 500 error for pre-provisioned ones. Also they couldn’t push to the server.
The log reported a file-not-found error when executing c:\gitea\gitea.exe for the pre-received hook, but they insisted the file was there (after all, they had configured it to run as a Windows service, so the service shouldn’t run if it wasn’t there). So they assumed something had gone wrong in the installation - maybe a problem with getting it to run as the SYSTEM user - and that some other file or files were missing.
Before I went to visit them, I did a little research and found a fair number of Gitea-on-windows users have encountered this problem and eventually got past it after trying random things, not really knowing which change had worked.
When I visit, I discover that they hadn’t disabled the “hide known file extensions” feature in Windows Explorer. So when they downloaded the Windows binary and renamed it to “gitea.exe”, they actually renamed it to “gitea.exe.exe”. How did the service run? I assume the Windows Service Manager calls a windows-specific function to run the start command, one which duplicates the command shell’s behaviour of “If I can’t find foo, try foo.exe”. But when the Gitea web UI calls the gitea binary, as it does for the git functions, it doesn’t call such a Windows-specific function and fails.
I hate the traps caused when Microsoft devs working on core system tools adopt the noob-friendly logic of the Windows GUI.