Commits that have been forced overwritten remain on dashboard/activity #1389

@stale[bot] commented on GitHub (Feb 9, 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.

@stale[bot] commented on GitHub (Feb 9, 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.

GiteaMirror commented

@0x3333 commented on GitHub (Mar 3, 2020):

Is there anything I could do to fix this? If someone give me some guidance, I could work it out. Thanks.

@0x3333 commented on GitHub (Mar 3, 2020): Is there anything I could do to fix this? If someone give me some guidance, I could work it out. Thanks.

GiteaMirror commented

@guillep2k commented on GitHub (Mar 3, 2020):

I don't think there's a simple way of "fixing" this. I'm not even sure it's a bug. Since the dashboard should notify of new events, why should those events disappear if they actually happened?

If you're force pushing to e.g. cover some mistake, I understand that you may not want others to see such mistake. But IMHO there is plenty of other uses for force pushing that it would be incorrect to hide.

Also, you must take into account that other users might have enabled e-mail notifications. Those e-mails are out there and can't be claimed back. 😁

@guillep2k commented on GitHub (Mar 3, 2020): I don't think there's a simple way of "fixing" this. I'm not even sure it's a bug. Since the dashboard should notify of new events, why should those events disappear if they actually happened? If you're force pushing to e.g. cover some mistake, I understand that you may not want others to see such mistake. But IMHO there is plenty of other uses for force pushing that it would be incorrect to hide. Also, you must take into account that other users might have enabled e-mail notifications. Those e-mails are out there and can't be claimed back. 😁

GiteaMirror commented

@lunny commented on GitHub (Mar 3, 2020):

@guillep2k I think the problem is if you force-push to a branch, the hidden commit should not be displayed on dashboard. It should be a bug of calculation of the commits affected when force pushing.

He didn't mean to delete the old events.

@lunny commented on GitHub (Mar 3, 2020): @guillep2k I think the problem is if you force-push to a branch, the hidden commit should not be displayed on dashboard. It should be a bug of calculation of the commits affected when force pushing. He didn't mean to delete the old events.

GiteaMirror commented

@guillep2k commented on GitHub (Mar 3, 2020):

But "not be displayed" and "delete the event" are equivalent from the UI point of view. I understand that if the commit was overwritten the link becomes invalid, but the entry should still show up in the dashboard. Perhaps something like:

@guillep2k commented on GitHub (Mar 3, 2020): But "not be displayed" and "delete the event" are equivalent from the UI point of view. I understand that if the commit was overwritten the link becomes invalid, but the entry should still show up in the dashboard. Perhaps something like: ![image](https://user-images.githubusercontent.com/18600385/75738062-0be1d280-5ce0-11ea-8c9a-9a9f7e00081d.png)

GiteaMirror commented

@0x3333 commented on GitHub (Mar 3, 2020):

After @guillep2k comment, it looks to me that he is right. Effectively, you pushed those commits, they must show up in the dashboard. My concern was that it was wrong, not to hide some mistake, but if you changed your history, you changed commits, if you changed commits, they should show up. Actually, this is a hint that something may have gone wrong.

I'm withdrawing my complaint... 😆

Thanks!

@0x3333 commented on GitHub (Mar 3, 2020): After @guillep2k comment, it looks to me that he is right. Effectively, you pushed those commits, they must show up in the dashboard. My concern was that it was wrong, not to hide some mistake, but if you changed your history, you changed commits, if you changed commits, they should show up. Actually, this is a hint that something may have gone wrong. I'm withdrawing my complaint... 😆 Thanks!

GiteaMirror commented

@Erriez commented on GitHub (Mar 2, 2021):

Is there a workaround to remove specific commits from the Dashboard? I accidentally pushed a file with passwords, but remains on the Dashboard after rewriting the git history... However, the Git log is correct.

Thanks!

@Erriez commented on GitHub (Mar 2, 2021): Is there a workaround to remove specific commits from the Dashboard? I accidentally pushed a file with passwords, but remains on the Dashboard after rewriting the git history... However, the Git log is correct. Thanks!

GiteaMirror commented

@lunny commented on GitHub (Mar 4, 2021):

Currently, I think the workaround is to delete the comment from database directly.

@lunny commented on GitHub (Mar 4, 2021): Currently, I think the workaround is to delete the comment from database directly.

GiteaMirror commented

@Erriez commented on GitHub (Mar 4, 2021):

Thanks @lunny. I've deleted the entries manually from table actions and is no longer displayed at the Dashboard.

I ran the Garbage collect all repositories in the Site Administration, but the SHA1 link is still accessible. Is it possible to delete this as well?

@Erriez commented on GitHub (Mar 4, 2021): Thanks @lunny. I've deleted the entries manually from table `actions` and is no longer displayed at the Dashboard. I ran the `Garbage collect all repositories` in the `Site Administration`, but the SHA1 link is still accessible. Is it possible to delete this as well?

GiteaMirror commented

@lunny commented on GitHub (Mar 6, 2021):

The default garbage collect is 1 week ago unused commits You can change the default garbage collect time. See https://docs.gitea.io/en-us/config-cheat-sheet/#git-git GC_Args

@lunny commented on GitHub (Mar 6, 2021): The default garbage collect is 1 week ago unused commits You can change the default garbage collect time. See https://docs.gitea.io/en-us/config-cheat-sheet/#git-git GC_Args

GiteaMirror commented

@Erriez commented on GitHub (Mar 7, 2021):

@lunny Thanks for pointing to the documentation. That's very useful.

However, I don't understand why the manual "Garbage collect all repositories" did not work:

After running it, the commits are still available. I have to wait a few days and then I know if there is a difference with the Cron garbage collection.

@Erriez commented on GitHub (Mar 7, 2021): @lunny Thanks for pointing to the documentation. That's very useful. However, I don't understand why the manual "Garbage collect all repositories" did not work: ![image](https://user-images.githubusercontent.com/8849873/110254193-65817a80-7f8e-11eb-869a-0495fcd55d2b.png) After running it, the commits are still available. I have to wait a few days and then I know if there is a difference with the Cron garbage collection.

GiteaMirror commented

@devnakx commented on GitHub (Sep 4, 2023):

indeed this issue also troubles me
at least I also believe that force push should no longer be displayed on the dashboard

@devnakx commented on GitHub (Sep 4, 2023): indeed this issue also troubles me at least I also believe that force push should no longer be displayed on the dashboard

GiteaMirror commented

@maciejopalinski commented on GitHub (Mar 1, 2025):

I managed to solve the issue on my instance of Gitea.

First, I amended and force-pushed a commit that leaked credentials, using the following commands:

git commit --amend
git push origin master --force

The commit was still available on the dashboard and on the commit details page

To remove the commit from the commit details page, I ran the following commands:

docker exec -it -u git gitea bash
cd /data/git/repositories/maciej.opalinski/rc522_shell.git # replace with your actual repository path
git reflog expire --expire=90.days.ago --expire-unreachable=now --all
git gc --aggressive --prune=now

That resulted in the commit being removed from the origin reflog and is not accessible from the commit details page anymore.

I decided NOT to remove the commit from the activity log on my dashboard, because the commit contents are inaccessible anyways and the commit message does not leak credentials.

If you need to remove the commit from the activity log on your dashboard, the activity log is stored in the database and you can select the data using the following query (replace the text between percentage signs with your commit hash):

SELECT
	*
FROM public.action
WHERE
	"content" LIKE '%9977eb10b1dbf6e1b81cde81eda418059c06a447%'
	AND
	"is_private" = FALSE

You can probably just delete this row, but I DID NOT TEST IT, as I don't need to remove the activity log entry. Proceed with caution and make a backup in case something breaks after deleting the row.

@maciejopalinski commented on GitHub (Mar 1, 2025): **I managed to solve the issue on my instance of Gitea.** First, I amended and force-pushed a commit that leaked credentials, using the following commands: ```sh git commit --amend git push origin master --force ``` The commit was still available on [the dashboard](https://git.mopalinski.com/maciej.opalinski?sort=recentupdate&q=&tab=activity&date=2024-08-27) and on [the commit details page](https://git.mopalinski.com/maciej.opalinski/rc522_shell/commit/9977eb10b1dbf6e1b81cde81eda418059c06a447) To remove the commit from the commit details page, I ran the following commands: ```sh docker exec -it -u git gitea bash cd /data/git/repositories/maciej.opalinski/rc522_shell.git # replace with your actual repository path git reflog expire --expire=90.days.ago --expire-unreachable=now --all git gc --aggressive --prune=now ``` That resulted in the commit being removed from the origin reflog and is not accessible from the commit details page anymore. I decided **NOT** to remove the commit from the activity log on my dashboard, because the commit contents are inaccessible anyways and the commit message does not leak credentials. If you need to remove the commit from the activity log on your dashboard, the activity log is stored in the database and you can select the data using the following query (replace the text between percentage signs with your commit hash): ```sql SELECT * FROM public.action WHERE "content" LIKE '%9977eb10b1dbf6e1b81cde81eda418059c06a447%' AND "is_private" = FALSE ``` You can probably just delete this row, but **I DID NOT TEST IT**, as I don't need to remove the activity log entry. Proceed with caution and make a backup in case something breaks after deleting the row.

GiteaMirror commented