I was working-with a test setup of gitea on a VPS♣ and encountered what may have been the same problem. After poking around with various tests, I found a workaround that is working for me. In case it could help you...
What was already working
In my case, asking gitea to create a new git repository with an initial "readme commit" was working fine. I could clone, add new commits, and push. The new commits appeared after the first one in the gitea web UI.
What wasn't working
If I asked gitea to create a repository without an initial commit†, gitea's web UI would not reflect the push of a commit history, i.e.
user@client:~/projects$ mkdir myCode
user@client:~/projects$ cd myCode
user@client:~/projects/myCode$ git init
Initialized empty Git repository in /home/user/projects/myCode/.git/
user@client:~/projects/myCode$ echo "testing 1 2 3" > file.txt
user@client:~/projects/myCode$ git add file.txt
user@client:~/projects/myCode$ git commit -m0
[master (root-commit) f9d8e7] 0
1 file changed, 1 insertion(+)
create mode 100644 file.txt
user@client:~/projects/myCode$ git remote add origin git@server:gitea_repos/owner/myCode.git
user@client:~/projects/myCode$ git push -u origin master
Counting objects: 3, done.
Writing objects: 100% (3/3), 210 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To git@server:gitea_repos/owner/myCode.git
* [new branch] master -> master
Branch master set up to track remote branch master from origin.
user@client:~/projects/myCode$
git would report success and git@server:gitea_repos/owner/myCode.git would continue to function as a remote but the gitea web UI would continue to display the "empty repository" help page instead of the repository browser‡.
Work-around strategy
Because new commits were registering on repositories that started non-empty, it occurred to me that gitea might notice the change if git overwrote the stub commit history of a new project with the complete commit history of another project↯. To try this, follow:
3 Easy Steps:
- In the
gitea web UI, create a new repository. On the New Repository creation page, be sure to check the box next to Initialize this repository with selected files and template before clicking Create Repository.
On your workstation, add this new stub as a remote to the local git repository with the desired commit history.
user@client:~$ cd projects/myCode
user@client:~/projects/myCode$ git remote add gitea git@server:gitea_repos/owner/myCode.git
Overwrite the gitea-generated stub-commit with the intended material.
user@client:~/projects/myCode$ git push -fu gitea master
Counting objects: 97, done.
Delta compression using up to 32 threads.
Compressing objects: 100% (95/95), done.
Writing objects: 100% (97/97), 55.53 KiB | 0 bytes/s, done.
Total 97 (delta 45), reused 0 (delta 0)
To git@server:gitea_repos/owner/myCode.git
+ a1b2c3...d4e5f6 master -> master (forced update)
Branch master set up to track remote branch master from gitea.
user@client:~/projects/myCode$
Note that, for Step 3:
-f is for force: this empowers git to perform the (otherwise prohibited) "commit tree overwrite"-u is for set-upstream - this connects local branch master through the remote-tracking branch gitea/master to the master branch managed by gitea
Follow through
This strategy is something of a hack and I suspect it leaves a few things undone. E.g. you might want to push branches and tags up to gitea. (My tests haven't taken me this far.) Consider --all for branches and --tags for tags:
user@client:~/projects/myCode$ git push gitea --all
user@client:~/projects/myCode$ git push gitea --tags
While YMMV, I wish you luck!
Footnotes:
♣ - I am working with gitea-1.4.2-linux-amd64 on Ubuntu 16.04.2 LTS hosted at virmach.com.
† - git uses the term "empty repository" when referring to a repository w/o commits but, in the internal API used by gitea to access git features (and, occasionally, by gitea community members), the term "bare repository"☥ is used.
☥ - git uses the term "bare repository" when referring to a repository not embedded (as the directory ./.git) in the root directory of a "working tree". Bare repositories are frequently used as a canonical copy for collaboration and are stored on (and accessible from) a server. E.g. the 'github' service. Sometimes these directories are named with the schema project_name.git
‡ - I tried a number of setup variations, asked around on irc channel #gitea, and poked around in the code. All I can conclude is that some difference in the git→hooks→gitea chain (varying between empty and non-empty repositories) is responsible for this problem on my VPS.
↯ - Before this, I thought of replaying the history of the desired project over the new stub but this rebase operation is a desperate hack: all the commits get new sha checksums and, essentially, all developers would have to clone-in again as if working on a new repository.
