Skip to content

When the remote repository force push to overwrite a tag, the mirrored repo will not update the tag updated time #32233

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
imkuang opened this issue Oct 10, 2024 · 4 comments · Fixed by #32342
Labels
topic/repo Related to repositories type/bug
Milestone

Comments

@imkuang
Copy link

imkuang commented Oct 10, 2024

Description

When using the mirroring feature to sync a repo from another server, if the remote server force push overwrites a tag, the local server will not update the updated time of these tags after completing the synchronization.

Finally, we will see the following situation on the webui: two tags with different update times have the same commit id:
image
You can check the test repository I created (I've converted it to a regular repo to remove the personal server url I use for mirroring operations): https://demo.gitea.com/404notfound/test/tags

This is common when synchronizing GitHub Actions repositories, where tags containing only the major version number are often constantly updated to always point to the latest version.

Gitea Version

1.22.3

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

No response

How are you running Gitea?

run gitea from docker

Database

SQLite

Steps to reproduce

  1. server1 for remote, server2 for local
  2. create a repo on server1, initialize a few commits, create a new tag v1 and push it
  3. create a new migration on server2 and select Git (not sure if it has any influence), fill in the URL of the repo on server1
  4. run git tag -d v1 to delete tag v1, create several new commits, and then re-create tag v1, git push --tags -f to push new tag references to server1
  5. go to the settings page of the repo on server2 and sync immediately to see the problem
@kemzeb kemzeb added the topic/repo Related to repositories label Oct 21, 2024
@lunny
Copy link
Member

lunny commented Oct 25, 2024

I cannot reproduce this problem according to the steps in my local machine.

@imkuang
Copy link
Author

imkuang commented Oct 25, 2024

Hello,

I just retested it and it can indeed be reproduced on demo.gitea.com.

A more detailed step-by-step guide is below, does this help?

  1. create a repo named 32233-test on gitea.com, and do these on local PC:
git clone https://demo.gitea.com/404notfound/test.git
cd test
git remote remove origin
git remote add origin https://gitea.com/404notfound/32233-test.git
git push -u origin main --tags
  1. create a new migration on demo.gitea.com, select Git, Migrate / Clone From URL: https://gitea.com/404notfound/32233-test.git, and mark "This repository will be a mirror"
  2. do these on local PC to overwrite a tag and push it, now on gitea.com, tags v1 and v1.0.3 have the same update time
touch test6
git add .
git commit -m "test6"
git tag v1.0.3
git tag -d v1
git tag v1
git push origin main --tags -f
  1. go to https://demo.gitea.com/404notfound/32233-test, Settings --> Mirror Settings --> Synchronize Now, We will resynchronize tag v1 (you can see that tag v1 and v1.0.3 have the same commit id), but the update time of tag v1 is not updated.
image

@lunny
Copy link
Member

lunny commented Oct 25, 2024

OK. Did you mean the problem is the updated time is not right?

@lunny lunny added this to the 1.22.4 milestone Oct 25, 2024
@imkuang
Copy link
Author

imkuang commented Oct 26, 2024

Yes, in my use case the updated time of tag v1 in the mirrored repo is wrong.

@lunny lunny closed this as completed in 13a2038 Nov 2, 2024
lunny added a commit to lunny/gitea that referenced this issue Nov 2, 2024
lunny added a commit that referenced this issue Nov 5, 2024
@go-gitea go-gitea locked as resolved and limited conversation to collaborators Jan 31, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
topic/repo Related to repositories type/bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants