Skip to content

Number of commits not counted correctly #4424

Closed
@bkroll

Description

@bkroll
  • 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]):
    • PostgreSQL
      MySQL
      MSSQL
      SQLite
  • Can you reproduce the bug at https://try.gitea.io:
    • Yes (provide example URL)
      No
      Not 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

gitea not counting correctly

Activity

johanhugg

johanhugg commented on Jul 11, 2018

@johanhugg

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

lafriks commented on Jul 11, 2018

@lafriks
Member

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.

added
issue/needs-feedbackFor bugs, we need more details. For features, the feature must be described in more detail
on Jul 11, 2018
bkroll

bkroll commented on Jul 16, 2018

@bkroll
ContributorAuthor

@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

bkroll commented on Jul 16, 2018

@bkroll
ContributorAuthor

@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

ghost commented on Jul 17, 2018

@ghost

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

bkroll commented on Jul 23, 2018

@bkroll
ContributorAuthor

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

lafriks commented on Jul 23, 2018

@lafriks
Member

@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

bkroll commented on Jul 23, 2018

@bkroll
ContributorAuthor

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.

lafriks

lafriks commented on Jul 23, 2018

@lafriks
Member

Check logs if there are any warnings or errors

bkroll

bkroll commented on Jul 23, 2018

@bkroll
ContributorAuthor

Thanks @lafriks I watched gitea.log, http.log and xorm.log while I did the following:

  • pushed first file into empty repo:
    • "quick guide" still appears after pushing file
    • nothing logged
  • created new repo with "initialize repository" option activated, pushed with commit message close #1to close issue:
    • pushed changes appear in gitea
    • #1 in commit message is linked to issue page
    • no reference is displayed on the issue page itself
    • issue is not closed
    • nothing is logged.

Commits 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.

lafriks

lafriks commented on Jul 23, 2018

@lafriks
Member

Do you have SELinux enabled in enforced mode?

lafriks

lafriks commented on Jul 23, 2018

@lafriks
Member

Check /var/log/audit.log if there is anything about gitea 3000 port

bkroll

bkroll commented on Jul 24, 2018

@bkroll
ContributorAuthor

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

lafriks commented on Dec 4, 2018

@lafriks
Member

@Akito13 what version are you using?

theAkito

theAkito commented on Dec 5, 2018

@theAkito

@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.

stale

stale commented on Feb 3, 2019

@stale

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

Exagone313 commented on Feb 4, 2019

@Exagone313
Contributor

This bug is still not resolved, please do not close.

adelowo

adelowo commented on Feb 4, 2019

@adelowo
Member

I still cannot replicate this on a regular repository through

Exagone313

Exagone313 commented on Feb 4, 2019

@Exagone313
Contributor

You can check the steps to reproduce of #5058, it's easy.

zeripath

zeripath commented on Feb 4, 2019

@zeripath
Contributor

The issue with deploy keys should be fixed by #5935 and its backport to v1.7 #5944. Is there anything else causing this?

stale

stale commented on Apr 5, 2019

@stale

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

zeripath commented on Apr 7, 2019

@zeripath
Contributor

Ok I'm gonna close this as fixed by #5935

locked and limited conversation to collaborators on Nov 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    issue/needs-feedbackFor bugs, we need more details. For features, the feature must be described in more detailissue/stale

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @lafriks@johanhugg@bjoe2k4@zeripath@bkroll

        Issue actions

          Number of commits not counted correctly · Issue #4424 · go-gitea/gitea