Compulsory submission results in abnormal warehouse size #7669

New Issue

GiteaMirror · 2025-11-02T07:32:59-06:00

GiteaMirror commented

2025-11-02 07:32:59 -06:00

Originally created by @inkss on GitHub (Aug 8, 2021).

Gitea version (or commit ref): 1.14.6 built with GNU Make 4.1, go1.16.7 : bindata, sqlite, sqlite_unlock_notify
Git version: 2.27.0
Operating system: command-line
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
Log gist:

Description

Hello, I use Github Action to deploy the Hexo blog, and use hexo-delpoy-git to deploy to the Gitea server through Token. Since Github Action is a new environment each time it is deployed, the temporary files generated are empty. A submission is equivalent to a mandatory submission.

The actual effect is that after deployment, the warehouse only keeps two submission records, and the previous submission information disappears. However, I found that the size of the warehouse has indeed increased over time, and the same deployment content, pushed to Github, can maintain a normal size. So this should be a bug, right?

The warehouse address 29.7M corresponding to Gihub: inkss.github.io
The warehouse address 1.0GB corresponding to Gitea: Blog

...

Screenshots

Originally created by @inkss on GitHub (Aug 8, 2021).   - Gitea version (or commit ref): 1.14.6 built with GNU Make 4.1, go1.16.7 : bindata, sqlite, sqlite_unlock_notify - Git version: 2.27.0 - Operating system: command-line    - Database (use `[x]`): - [ ] PostgreSQL - [x] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - Log gist:    ## Description  Hello, I use Github Action to deploy the Hexo blog, and use hexo-delpoy-git to deploy to the Gitea server through Token. Since Github Action is a new environment each time it is deployed, the temporary files generated are empty. A submission is equivalent to a mandatory submission. The actual effect is that after deployment, the warehouse only keeps two submission records, and the previous submission information disappears. However, I found that the size of the warehouse has indeed increased over time, and the same deployment content, pushed to Github, can maintain a normal size. So this should be a bug, right? The warehouse address 29.7M corresponding to Gihub: [inkss.github.io](https://github.com/inkss/inkss.github.io) The warehouse address 1.0GB corresponding to Gitea: [Blog](https://gitea.szyink.com/szyink/Blog) ... ## Screenshots  ![Gitea](https://user-images.githubusercontent.com/31947043/128636427-8274329e-8d30-4ac7-b019-4a4af9e80dbd.png) ![Github](https://user-images.githubusercontent.com/31947043/128636434-65ce82db-0c62-4696-a1d0-2bbf4d5ea9d5.png)

GiteaMirror added the type/question label 2025-11-02 07:32:59 -06:00

GiteaMirror closed this issue

2025-11-02 07:32:59 -06:00

GiteaMirror commented

2025-11-02 07:33:00 -06:00

@inkss commented on GitHub (Aug 8, 2021):

To summarize: it seems that all submissions are stored in the system, even if the corresponding submission has been permanently deleted in the submission history

@inkss commented on GitHub (Aug 8, 2021): To summarize: it seems that all submissions are stored in the system, even if the corresponding submission has been permanently deleted in the submission history

GiteaMirror commented

2025-11-02 07:33:00 -06:00

@delvh commented on GitHub (Aug 8, 2021):

If I understand your problem correctly, that's not a bug of Gitea, that's just how git works.
Any file you once added in a commit stays stored inside your repo, even if it is removed in a later commit.
git gc might help, although I do not know how you can manually start garbage collection of your remote repo, unless you are a server administrator.
I suppose that Gitea simply hasn't run the garbage collector yet.
I hope that one of the core-maintainers can help you more than I with my amateur opinion.

@delvh commented on GitHub (Aug 8, 2021): If I understand your problem correctly, that's not a bug of Gitea, that's just how git works. Any file you once added in a commit stays stored inside your repo, even if it is removed in a later commit. `git gc` might help, although I do not know how you can manually start garbage collection of your remote repo, unless you are a server administrator. I suppose that Gitea simply hasn't run the garbage collector yet. I hope that one of the core-maintainers can help you more than I with my amateur opinion.

GiteaMirror commented

2025-11-02 07:33:00 -06:00

@techknowlogick commented on GitHub (Aug 8, 2021):

Yes, that is correct. There are git commits that are not referenced anywhere but still exist on disk. git gc would clean them up.

@techknowlogick commented on GitHub (Aug 8, 2021): Yes, that is correct. There are git commits that are not referenced anywhere but still exist on disk. `git gc` would clean them up.

GiteaMirror commented

2025-11-02 07:33:00 -06:00

@inkss commented on GitHub (Aug 9, 2021):

So because I didn't set it to scheduled tasks here? I only found four relevant information in System Notices.

@inkss commented on GitHub (Aug 9, 2021): ![Snipaste_2021-08-09_08-07-29](https://user-images.githubusercontent.com/31947043/128649748-edfed39c-7b08-4577-acff-6fa3c0449ce1.png) So because I didn't set it to scheduled tasks here? I only found four relevant information in System Notices.

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#7669