[x]):The number of commits is not counted correctly. as it can be seen from the screenshot. There are three commits, but it says "1 Commits" on the repository pages.
Also, the uncounted commits are not shown on the user's public activity list on their profile.
What could be done to have the repositories show the correct commit counts?
Do you have a git repository we can test on? Have you tried using the latest version of Gitea? I just compiled the version you have and tested it, I can't seem to reproduce.
Can you give steps on how did you pushed these commits? (ssh or https etc).
Do you have any warnings/errors in gitea.log at that time.
Commit count are cached for 24 hours if I remember correctly but cache should invalidate on git push/pr merge etc.
@johanhugg I have used the release at https://github.com/go-gitea/gitea/releases/latest as binary, but not the v1.5.0-rc1 pre-relase, as we are using gitea in production. Sorry, I can't make that gitea install available online due to our firewall.
@lafriks The commits where pushed via ssh using password authentication. No warnings or errors are written to gitea.log when pushing or when viewing the commit count.
I noticed that only some commits are not counted - in other repos on that install, there are ten commits but the counter shows only seven. However, all commits where pushed from the same remote.
The partition is not mounted with "noexec", so #1231 does not seem to apply here.
@lafriks Now I see that the commit counter at the repo pictured in the screenshot has updated to three, which is correct. There have been more than 24 hours since the commits where made and pushed. No further pushes have been made to the repo in the meantime.
Could there be a problem clearing the cache on push/merge?
I ran into the same issue as well. Same setup (gitea on sqlite, version 1.4.3, amd64-linux); repository being https://neueland.iserlohn-fortress.net/gitea/aqua/smolbote. The repository is a converted mercurial repo.
Rerunning the gitea instance fixed the commit count.
Creating an empty repository however, and pushing a couple of commits to it properly updates the commit count. (This was done after rerunning the instance.)
Edit: Pushing again to the original repository doesn't update the commit count (gitea says 384; git rev-list --count --all says 385), but pushing to the test repo properly updates (2 -> 3 commits),
Edit: I also noticed that this repository wasn't getting its pushes listed in the dashboard, and no size listed in the user settings. I had manually reset it previously (deleted it, then git init --bare), which I suppose has broken its gitea integration. Remaking the repository from the gitea UI and pushing it back up fixed the issue.
Thanks @xiannox, rerunning the gitea instance fixed the commit counter for our problem as well, as far at least for now.
If there is no other solution, setting cronjob to regularly restart the instance could be an option, but I still hope someone can help finding another way.
@bkroll no need to restart. It is cached for 20hours so it will show correct after that anyway. You can also set smaller cache time in app.ini
Thanks @lafriks, I have set ITEM_TTL = 0 to deactivate caching, which provides a workaround to this problem. But now I have noticed that closing or referencing an issue from the commit message does not work either. Could those two problems be related? (I have checked that the noexec problem #1231 is not the case here.)
Is it normal that on ssh push to a gitea repo, no log is written to gitea.log with Debug log level? I'm not sure the hooks are running properly. Also, I have updated the instance to 1.5.0-rc2, but that did not solve the problems.
Check logs if there are any warnings or errors
Thanks @lafriks I watched gitea.log, http.log and xorm.log while I did the following:
close #1to close issue:#1 in commit message is linked to issue pageCommits are now counted correctly, since I deactivated caching.
machine:/etc/gitea # cat app.ini | grep LEVEL -B2
[log]
MODE = file
LEVEL = Debug
I tried the same steps on try.gitea.org. There, everything worked as expected. On my machine, I am running SLES 12 SP3 with git 2.12.3 on sqlite db.
Do you have SELinux enabled in enforced mode?
Check /var/log/audit.log if there is anything about gitea 3000 port
SELinux is not enabled, /var/log/audit/ is empty. I looked into /var/log/messages, there are only Macaron log lines in there, but no errors.
I can also confirm, fresh install of 1.5.0 of Gitea. The only thing I did was create a mirrored repo from GitHub, after the automatic sync has pulled in a few commits I noticed that the commit count is never updated. A restart of the Gitea instance fixed the count.
@SoulSeekkor There is a fix for mirrored repos already at https://github.com/go-gitea/gitea/pull/4720
@bkroll is this issue on a mirrored repo too or a regular one ?
@adelowo Perfect, thank you!
@adelowo The issue occured in a regular repo, not a mirrored one.
I have only observed this kind of behavior when pushing via read/write deploy key, which is already reported a while ago in #3795
This happens to me whenever I push from terminal. Doesn't matter if over SSH or HTTPS. It looks like the commit never happened. The only way to see the new commit is to go to the correct branch and check commits.
@Akito13 what version are you using?
@Akito13 what version are you using?
1.6.0+rc1-123-g3379141d8
Though, I have to clarify: I actually don't care if the commits are counted incorrectly. That's not my problem. And I didn't notice any incorrect counts. I didn't really _check_ it for all repositories, just one and there the count was correct. So I ignored that. But it bothers me, that I can't see pushes on the _Dashboard_ or _Public Activity_ if they are executed from a client in the terminal.
Also, the uncounted commits are not shown on the user's public activity list on their profile.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.
This bug is still not resolved, please do not close.
I still cannot replicate this on a regular repository through
You can check the steps to reproduce of #5058, it's easy.
The issue with deploy keys should be fixed by #5935 and its backport to v1.7 #5944. Is there anything else causing this?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.
Ok I'm gonna close this as fixed by #5935