Pushing to new repository does not change it to non-empty #4488

New Issue

GiteaMirror · 2025-11-02T05:52:28-06:00

GiteaMirror commented

2025-11-02 05:52:28 -06:00

Originally created by @mschoettle on GitHub (Dec 15, 2019).

Gitea version (or commit ref): 1.10.1
Git version: 2.22.2
Operating system: Raspian Buster (10)
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant
Log gist:

[Macaron] 2019-12-15 19:32:42: Started GET /user/test.git/info/refs?service=git-receive-pack for 192.168.1.119
[Macaron] 2019-12-15 19:32:42: Completed GET /user/test.git/info/refs?service=git-receive-pack 401 Unauthorized in 12.255841ms
[Macaron] 2019-12-15 19:32:42: Started GET /user/test.git/info/refs?service=git-receive-pack for 192.168.1.119
[Macaron] 2019-12-15 19:32:43: Completed GET /user/test.git/info/refs?service=git-receive-pack 200 OK in 410.181919ms
[Macaron] 2019-12-15 19:32:43: Started POST /user/test.git/git-receive-pack for 192.168.1.119
[Macaron] 2019-12-15 19:32:43: Completed POST /user/test.git/git-receive-pack 200 OK in 381.062007ms
[Macaron] 2019-12-15 19:32:50: Started GET /user/test for 192.168.1.119
[Macaron] 2019-12-15 19:32:50: Completed GET /user/test 200 OK in 41.880096ms

Description

I created a new repo and pushed a local repository. I tried it both with --all (it has two branches) and without (pushed only master). Either way the repository is not changed to non-empty. I did it manually in the DB to set the is_empty column to 0 which fixed the problem.

Steps to reproduce

Create a new repo
Take an existing repo on your machine and add the new repo as a remote test
git push -u test

Originally created by @mschoettle on GitHub (Dec 15, 2019). - Gitea version (or commit ref): 1.10.1 - Git version: 2.22.2 - Operating system: Raspian Buster (10) - Database (use `[x]`): - [ ] PostgreSQL - [x] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [ ] Not relevant - Log gist: ``` [Macaron] 2019-12-15 19:32:42: Started GET /user/test.git/info/refs?service=git-receive-pack for 192.168.1.119 [Macaron] 2019-12-15 19:32:42: Completed GET /user/test.git/info/refs?service=git-receive-pack 401 Unauthorized in 12.255841ms [Macaron] 2019-12-15 19:32:42: Started GET /user/test.git/info/refs?service=git-receive-pack for 192.168.1.119 [Macaron] 2019-12-15 19:32:43: Completed GET /user/test.git/info/refs?service=git-receive-pack 200 OK in 410.181919ms [Macaron] 2019-12-15 19:32:43: Started POST /user/test.git/git-receive-pack for 192.168.1.119 [Macaron] 2019-12-15 19:32:43: Completed POST /user/test.git/git-receive-pack 200 OK in 381.062007ms [Macaron] 2019-12-15 19:32:50: Started GET /user/test for 192.168.1.119 [Macaron] 2019-12-15 19:32:50: Completed GET /user/test 200 OK in 41.880096ms ``` ## Description I created a new repo and pushed a local repository. I tried it both with `--all` (it has two branches) and without (pushed only master). Either way the repository is not changed to non-empty. I did it manually in the DB to set the `is_empty` column to `0` which fixed the problem. **Steps to reproduce** 1. Create a new repo 1. Take an existing repo on your machine and add the new repo as a remote `test` 1. `git push -u test`

GiteaMirror closed this issue

2025-11-02 05:52:28 -06:00

GiteaMirror commented

2025-11-02 05:52:29 -06:00

@timonegk commented on GitHub (Dec 20, 2019):

I am experiencing the same problem with PostgreSQL, Debian Buster and Gitea 1.10.1.

@timonegk commented on GitHub (Dec 20, 2019): I am experiencing the same problem with PostgreSQL, Debian Buster and Gitea 1.10.1.

GiteaMirror commented

2025-11-02 05:52:29 -06:00

@zeripath commented on GitHub (Dec 20, 2019):

OK, so I don't see any hooks firing in that log gist.

Are your gitea repositories mounted on a non-exec partition?
Are the hooks marked executable?
Have you run the admin resynchronize hooks tool? (Please note this tool does not mark hooks as being executable if they are present but not executable - you will have to do that yourself.)

@zeripath commented on GitHub (Dec 20, 2019): OK, so I don't see any hooks firing in that log gist. * Are your gitea repositories mounted on a non-exec partition? * Are the hooks marked executable? * Have you run the admin resynchronize hooks tool? (Please note this tool does not mark hooks as being executable if they are present but not executable - you will have to do that yourself.)

GiteaMirror commented

2025-11-02 05:52:29 -06:00

@timonegk commented on GitHub (Dec 20, 2019):

Oh, I think the problem is the noexec flag. I am using podman for virtualization which mounts volumes with noexec by default. The corresponding issue seems to be fixed already, but my release does not contain the fix yet. I will try again with the current release and report the results here.

@timonegk commented on GitHub (Dec 20, 2019): Oh, I think the problem is the `noexec` flag. I am using podman for virtualization which mounts volumes with `noexec` by default. The [corresponding issue](https://github.com/containers/libpod/issues/4318) seems to be [fixed already](https://github.com/containers/libpod/pull/4557), but my release does not contain the fix yet. I will try again with the current release and report the results here.

GiteaMirror commented

2025-11-02 05:52:30 -06:00

@timonegk commented on GitHub (Dec 20, 2019):

Yes, that was the problem. Thank you for the quick response!

@timonegk commented on GitHub (Dec 20, 2019): Yes, that was the problem. Thank you for the quick response!

GiteaMirror commented

2025-11-02 05:52:30 -06:00

@timonegk commented on GitHub (Dec 20, 2019):

Well I don't know if this works for @mschoettle too

@timonegk commented on GitHub (Dec 20, 2019): Well I don't know if this works for @mschoettle too

GiteaMirror commented

2025-11-02 05:52:30 -06:00

@zeripath commented on GitHub (Dec 20, 2019):

Hmm I think I'll leave it closed unless they write back to say that doesn't explain their problem

@zeripath commented on GitHub (Dec 20, 2019): Hmm I think I'll leave it closed unless they write back to say that doesn't explain their problem

GiteaMirror commented

2025-11-02 05:52:30 -06:00

@mschoettle commented on GitHub (Dec 21, 2019):

Thanks.

I had user in my mount options which implies noexec. Without it it works now.

However, I think there should be some indication (in the logs or somewhere else) that the hooks are not executable.

@mschoettle commented on GitHub (Dec 21, 2019): Thanks. I had `user` in my mount options which implies `noexec`. Without it it works now. However, I think there should be some indication (in the logs or somewhere else) that the hooks are not executable.

GiteaMirror commented

2025-11-02 05:52:30 -06:00

@iwzoo commented on GitHub (Dec 22, 2019):

I'm having exact the same problem here. I run gitea + sqlite docker container on debian.

@iwzoo commented on GitHub (Dec 22, 2019): I'm having exact the same problem here. I run gitea + sqlite docker container on debian.

GiteaMirror commented

2025-11-02 05:52:31 -06:00

@mschoettle commented on GitHub (Dec 22, 2019):

@iwzoo: Did you check this comment?

I connected to the container and tried to execute a hook manually (for example: /data/git/repositories/<user>/<repo>/hooks/post.receive.d/gitea) which gave me "permission denied". That way I knew it was the problem described above.

@mschoettle commented on GitHub (Dec 22, 2019): @iwzoo: Did you check this [comment](#issuecomment-567889477)? I connected to the container and tried to execute a hook manually (for example: `/data/git/repositories/<user>/<repo>/hooks/post.receive.d/gitea`) which gave me "permission denied". That way I knew it was the problem described above.

GiteaMirror referenced this issue

2025-11-02 13:08:43 -06:00

[PR #4488] [MERGED] Add 1.5.0-rc2 changelog #17396

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#4488