Heatmap shows commits on push date instead of commit author date

[fjamesprice]

Description

The contribution heatmap displays commits on the push date rather than the commit author date. This causes all commits pushed together to appear on the same day, even if they were authored on different days.

This is a continuation of #14051 and #11861 (both now locked).

Steps to Reproduce

1. Create commits with backdated author timestamps:

   git commit --allow-empty --date="2025-01-20T15:00:00" -m "Commit from Jan 20"
   git commit --allow-empty --date="2025-01-22T19:30:00" -m "Commit from Jan 22"
   git commit --allow-empty --date="2025-01-24T14:15:00" -m "Commit from Jan 24"

2. Push all commits at once
3. Check the user's heatmap

Expected Behavior

Commits should appear on their author dates (Jan 20, 22, 24) - matching GitHub's behavior.

Actual Behavior

All commits appear on the push date (e.g., Jan 27).

Solution

PR #36469 fixes this by:

• Adding an original_unix field to the Action model to store the commit author timestamp
• Grouping commits by date and creating separate action records for each date
• Updating the heatmap query to use COALESCE(NULLIF(original_unix, 0), created_unix)

The fix maintains backward compatibility - existing records continue using the push date.

Version

Tested on latest main branch (commit from January 2026)

[silverwind]

Closing as "working as intended" as per #36469 (comment). I'm sorry it didn't work out.

[fjamesprice]

Closing as "working as intended" as per #36469 (comment). I'm sorry it didn't work out.

It's alright. This was my first PR ever. I understand the utility I was attempting to add was somewhat niche - I sometimes lose connection to my gitea server and like things to look right when I can push again. For now I can run my server with my changes so it suits me. This was a good learning experience. I appreciate the feedback and cooperation.

[silverwind]

Actually, I think it's still a valid goal, because GitHub does actually count commits and fundamentally I think it's right to count contributions by commits. Here are GitHub's inclusion criteria:

1. The email address used for the commit must be associated with your GitHub account (or the GitHub-provided noreply address).
2. The commit must be on the default branch or the gh-pages branch.
3. Commits in forks do not count.
4. The author date (not the commit date) determines which day the contribution appears on.

Remarks:

• Replayed commits in other repo's default branch do count (but some heuristics for replay detection could be implemented)
• GitHub calculates the data only once every 24 and serves a cache

So one approach to this could be a cron task in Gitea that parses a user's commits every day and then updates a serialized JSON value in the user table. That way, it should be simple to implement and the only downside is that today's commits are not included, but that's fine imho.

Ref: https://docs.github.com/en/account-and-profile/how-tos/contribution-settings/troubleshooting-missing-contributions
Ref: https://docs.github.com/en/account-and-profile/concepts/contributions-on-your-profile

cc: @lafriks fyi.

[silverwind]

Let's keep open, I can accept a implementation that does it like above, ideally with some "replay detection".

[silverwind]

Regarding "author date": This is git jargon for the date when the commit was originally written, which differs from the commit date when a commit is replayed or rewritten.

The author date will surive such operations, so by using this author date, replayed commits can be detected by a simple elimination of commits with exact same author date and author, and maybe title.

[fjamesprice]

Before I start on a new PR, I wanted to lay out what I'm thinking based on silverwind's cron suggestion and make sure it sounds right.

The idea is a daily cron task that walks each user's commits on default branches and builds heatmap data from author dates. It would be fully decoupled from the action table - no joins, no schema changes, no risk to existing feeds or performance.

Storage would be a small table like:

CREATE TABLE user_heatmap (
    id             BIGINT PRIMARY KEY AUTO_INCREMENT,
    user_id        BIGINT NOT NULL,
    contrib_date   DATE NOT NULL,
    contrib_count  INT NOT NULL DEFAULT 0,
    UNIQUE INDEX idx_user_date (user_id, contrib_date)
);

One row per user per day. The heatmap query becomes a simple indexed read with no joins. silverwind also mentioned storing this as JSON on the user table, which would be simpler but harder to query. Either way works for me.

The cron task would only count commits where the author email matches one of the user's verified emails, which handles the merge commit concern - other people's commits don't count toward your heatmap even if you pushed them.

For replay detection, a commit would be considered a duplicate if another commit already exists with the same author email, exact author date, and commit message first line. This covers force pushes, cherry-picks across repos, and the unsquashed upstream merge workflow silverwind described. The author date survives those operations, so the duplicates are identifiable. Undercounting from a false positive seems safer than overcounting.

The action table, feeds, notifications, and API would all be untouched. If the cron task causes problems it can just be disabled and the heatmap falls back to the current behavior.

A few things I'm not sure about:

1. Should this include gh-pages branches like GitHub does, or just the default branch?
2. Should forks be excluded entirely (GitHub excludes them)?
3. For the initial migration - backfilling by walking all commits could take a while on large instances. Should that be a background task?

I don't want to go down the same road as the last PR, so I'd rather get alignment on the approach before writing code. If this looks reasonable or needs changes, let me know.

[silverwind]

approach sounds good to me.

• i would make the cron sometimes after midnight in the server's timezone, maybe 02:00 or later to eliminate potential problems related to DST.
• As for the data retrieval from repos, I think git log should provide all data we need. make sure to set --since="1 year ago" and that commits from the current day are omitted.
• I like the approach with a separate table, it's more flexible.

1. No, just default branch only, gitea has no webhosting features.
2. Yes, why do you think forks should be included?
3. I guess heatmap data is not critical enough to block the startup for the initial migration. I would make it a background goroutine, same as the cron task that runs every night.

One question remains about what to do with the current day. Maybe it could be done with a separate mechanism that updates the table entries where contrib_date=currentdate as commits happen.

[lafriks]

Also there is still also things to consider:

• How to clean up data that are no longer needed here? (for example after force push commits that are not in git anymore need to be deleted, default branch changed, repo deleted etc)
• Forks should not be counted (at least GitHub does not count them)
• It should not count commits for users that are not part of organization that repo belongs to (for example if someone pushes my commits or commits with my email in organization repo that I'm not member - I would not want them in my heat map to not screw it up) - this is also how GitHub does this
• It still need to count other activities form actions table (PR reviews etc)