-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
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
Match unqualified references when syncing pulls as well #23070
Match unqualified references when syncing pulls as well #23070
Conversation
Good catch. There are some details about git IMO the bug is in In other functions, when they see a variable called |
I actually expected someone to point that out, unfortunately, it seems to be parsing remote output to get the tag, and from my logging as depicted below, for i := range lines {
// Make sure reference name is presented before continue
idx := strings.Index(lines[i], "-> ")
if idx == -1 {
continue
}
refName := lines[i][idx+3:]
log.Info("stats_indexer.parseRemoteUpdateOutput(%d) RefFullName: %s, %s", 0, refName, lines[i])
switch {
case strings.HasPrefix(lines[i], " * "): // New reference
if strings.HasPrefix(lines[i], " * [new tag]") {
refName = git.TagPrefix + refName
} else if strings.HasPrefix(lines[i], " * [new branch]") {
refName = git.BranchPrefix + refName
}
results = append(results, &mirrorSyncResult{
refName: This is the output it processes when it is doing a pull,
Specifically the line Personally, I'm not opposed to just assuming it's a branch by default, or with my current PR, matching it regardless of whether it has a prefix. I am more concerned about not letting this issue remain an issue, when the "fix" for it, is fairly clear. |
According to my test.
If I change/delete the tags on remote, |
Given that the code in this PR is only targeting |
Im my mind, storing a non-ref value into a variable called Maybe @zeripath could help to take a look at this problem, he has spent a lot of time cleaning up the legacy ref problems in Gitea. |
Maybe we should change
Maybe it's not about missing |
There are also instances where
|
Yes, so I mean maybe we should correct the function |
Sorry @lunny, I have been out of touch of this issue for awhile as I've been running my own custom build with this, but how do you suppose we can rectify this issue? Is there a drawback to just calling a re-index every time |
I have no objection for this change. Leaving enough comments, then it could look good to me. |
Great to hear, what kind of comments are you expecting from this PR? |
Some explanation about why need this logic? And take some test result from the commens like |
I have sent #24634. I think that PR did more work than this PR. |
No problem with that, so long as that PR doesn't take a couple of months to review and merge, given how much more complicated it is. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since my PR will take more time, I think we can merge this first.
…nc bugs (#24634) This PR replaces all string refName as a type `git.RefName` to make the code more maintainable. Fix #15367 Replaces #23070 It also fixed a bug that tags are not sync because `git remote --prune origin` will not remove local tags if remote removed. We in fact should use `git fetch --prune --tags origin` but not `git remote update origin` to do the sync. Some answer from ChatGPT as ref. > If the git fetch --prune --tags command is not working as expected, there could be a few reasons why. Here are a few things to check: > >Make sure that you have the latest version of Git installed on your system. You can check the version by running git --version in your terminal. If you have an outdated version, try updating Git and see if that resolves the issue. > >Check that your Git repository is properly configured to track the remote repository's tags. You can check this by running git config --get-all remote.origin.fetch and verifying that it includes +refs/tags/*:refs/tags/*. If it does not, you can add it by running git config --add remote.origin.fetch "+refs/tags/*:refs/tags/*". > >Verify that the tags you are trying to prune actually exist on the remote repository. You can do this by running git ls-remote --tags origin to list all the tags on the remote repository. > >Check if any local tags have been created that match the names of tags on the remote repository. If so, these local tags may be preventing the git fetch --prune --tags command from working properly. You can delete local tags using the git tag -d command. --------- Co-authored-by: delvh <[email protected]>
Since #24634 is merged but not backport to v1.19 because there are too many conflicts, I think this patch could be sent to v1.19. |
Conflict needs to be fixed. |
Am I suppose to fix the conflict based off v1.19 code? |
No, just fix it against the |
The original issue's problem has been fixed by Use the type RefName for all the needed places and fix pull mirror sync bugs #24634 in 1.20 So this PR could be applied to 1.19 |
Ok, let me try changing PR base. |
No, didn't work, it showed a massive diff. I think we may need a fresh PR targeting |
@silverwind, does this look good for merging? |
Seems good, but @lunny should take a final look as well. |
Oh, that's too bad. |
That refactoring PR is too big, it's not suitable to backport. I think 1.20 is pretty stable, and its release day is not too far. Maybe you could try 1.20 nightly, any bug could be fixed in the first time. |
Maybe #24868 could be reopen and retarget to 1.19? @sillyguodong |
I was thinking of this one-line fix: #24868
We run 1.20 in dev, but for production I have to deploy something stable :( |
It seems that `opts.RefFullName` may occassionally be set to just the branch name, without the `refs/heads/` prefixing. (cherry picked from commit 7dc46ff)
It seems that
opts.RefFullName
may occassionally be set to just the branch name, without therefs/heads/
prefixing.