Closed
Description
- Gitea version (or commit ref): 1.4.3 built with: bindata, sqlite
- Git version: git version 2.12.3
- Operating system: Linux 4.4.138-94.39-default Rename import paths: "github.com/gogits/gogs" -> "github.com/go-gitea/gitea" #1 SMP Mon Jun 18 13:27:26 UTC 2018 (baa07f9) x86_64 x86_64 x86_64 GNU/Linux
- Database (use
[x]
):- PostgreSQLMySQLMSSQLSQLite
- Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)NoNot relevant
- Log gist: no error is logged when accessing the commit count or list
Description
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?
Screenshots
Metadata
Metadata
Assignees
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
johanhugg commentedon Jul 11, 2018
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.
lafriks commentedon Jul 11, 2018
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.
bkroll commentedon Jul 16, 2018
@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.
bkroll commentedon Jul 16, 2018
@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?
ghost commentedon Jul 17, 2018
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.
bkroll commentedon Jul 23, 2018
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.
lafriks commentedon Jul 23, 2018
@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
bkroll commentedon Jul 23, 2018
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 thenoexec
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.lafriks commentedon Jul 23, 2018
Check logs if there are any warnings or errors
bkroll commentedon Jul 23, 2018
Thanks @lafriks I watched gitea.log, http.log and xorm.log while I did the following:
close #1
to close issue:#1
in commit message is linked to issue pageCommits are now counted correctly, since I deactivated caching.
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.
lafriks commentedon Jul 23, 2018
Do you have SELinux enabled in enforced mode?
lafriks commentedon Jul 23, 2018
Check /var/log/audit.log if there is anything about gitea 3000 port
bkroll commentedon Jul 24, 2018
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.
8 remaining items
lafriks commentedon Dec 4, 2018
@Akito13 what version are you using?
theAkito commentedon Dec 5, 2018
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.
stale commentedon Feb 3, 2019
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.
Exagone313 commentedon Feb 4, 2019
This bug is still not resolved, please do not close.
adelowo commentedon Feb 4, 2019
I still cannot replicate this on a regular repository through
Exagone313 commentedon Feb 4, 2019
You can check the steps to reproduce of #5058, it's easy.
zeripath commentedon Feb 4, 2019
The issue with deploy keys should be fixed by #5935 and its backport to v1.7 #5944. Is there anything else causing this?
stale commentedon Apr 5, 2019
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.
zeripath commentedon Apr 7, 2019
Ok I'm gonna close this as fixed by #5935