Storing branch commits count in db rather than caching them in memory or redis

[lunny]

Branch commit counts are cached in memory or Redis after the first access. However, the initial page load is still slow because the commit count needs to be computed.

This PR introduces a new field in the database to store commit counts for branches. The commit count is updated automatically when branches are pushed or mirrored. Additionally, a background task periodically checks and corrects any discrepancies in the commit count to handle unexpected situations.

With this change, even if the commit count is not updated in time, a number will still be displayed in the UI. This prevents the UI from blocking the user, as commit counts are generally not critical for the user’s experience when visiting the page.

Note: The release table has a column num_commits which stored the commit count of a tag. So that we just need to cache a commit's commit count in the cache.

[wxiaoguang]

You can not do this! You can not close the gitRepo then then access the returned "commit"!!!!

That's I said many times: I do not see how you could make the "gitrepo" package work correctly, but introducing more bugs.

[lunny]

998f9ff

[wxiaoguang]

Really questionable whether it should be that complex

[wxiaoguang]

The whole design is problematic. You shouldn't make the logic tightly depending on each other. What you need is a "commit count cache" module.

• If the commit count is in cache: use it to render the template
• If the commit count is not in cache: render a "loading" indicator and use async fetch to partially load the page, and start a background task to fill the commit count into cache.

You should make the module work for all branches, tags and commits. No more hacky patch please.

[wxiaoguang]

You should never need it.

Why you know "RefType" but don't know the full "RefName" when using the ref?

[lunny]

The whole design is problematic. You shouldn't make the logic tightly depending on each other. What you need is a "commit count cache" module.

• If the commit count is in cache: use it to render the template
• If the commit count is not in cache: render a "loading" indicator and use async fetch to partially load the page, and start a background task to fill the commit count into cache.

You should make the module work for all branches, tags and commits. No more hacky patch please.

This cannot work well. For the first visit to a repository home page, it needs the commits count to decide whether last commit cache should be enabled at the moment. Except we cache all last commit information even there is less commits.

Tag's commit count has already been stored in the database.

[wxiaoguang]

whether last commit cache should be enabled at the moment.

I do not see the "last commit cache" is right either.

[lunny]

whether last commit cache should be enabled at the moment.

I do not see the "last commit cache" is right either.

The last commit cache isn’t perfect yet, but it has already improved homepage loading times — except on the first visit.
Found a problem? Feel free to open an issue!

[wxiaoguang]

The last commit cache isn’t perfect yet, but it has already improved homepage loading times — except on the first visit.

Why not make it overall right first? Why it should depend on the commit count since it is stored in git.Repository which is a per-request object?