-
-
Notifications
You must be signed in to change notification settings - Fork 5.4k
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
FindRecentlyPushedNewBranches
finding non-existing Branches
#31471
Comments
This comment was marked as outdated.
This comment was marked as outdated.
Thanks for the information. Did you check out how to apply the workaround, to make this error disappear? It works for me. If you have specific questions regarding the setup, perhaps you could ask on the forum for clarification. I would be happy to help. |
oh i need to upgrade 1.22-nightly to try? UPDATE: Yeah, i download then upgrade, now seems it's work correctlly. Thanks! i hope they fixed it by lastest version as soon as quicky and tell every person who meet this issue. Thanks for your help. |
That's only one case for the "branch sync" problem .....
That's another case: some branches are out-of-sync for some known or unknown reasons, so "sync branches" on the admin dashboard panel could also "fix" the problem. The root problem is the "branch sync mechanism", it is incomplete in some cases (but at the moment I can't tell more .....), the cases need to be fixed one by one. |
I see. Thanks for the clarification. However, even if it is out of sync, why does it search for a |
Because if a repo doesn't have a default branch, but the database might have recorded "main" as the default branch. There could be some different causes:
More context: theoretically, the "branch list" should be correctly stored in a database table and used from that database table, the "default branch" is also stored in database. In most cases, the "branch list" and "default branch" in database should be the same as what in a git repo. However, sometimes "branch list" and "default branch" might differ from from the underlying git repo (surely it is a bug). Even the underlying repo doesn't really have a default branch, "default branch" could also be something like "main". |
Description
Follow up on #31163. This issue has been worked around in the mentioned issue and this issue is for solving the root problem.
The issue starts to appear, when you upgrade from a pre-
1.22
version to the1.22
version.The problem displayed itself as the user trying to open a repository and then hitting a HTTP 500 Error, because the system tries to find the default branch named
main
. Right now, this error is not displayed in the Nightly version of1.22
, because it is just hidden and ignored. The root issue remains unsolved.I use this space to clarify and further detail the description of the root problem.
This comment by a maintainer suggests, that when a default branch by the default name is missing, the branch might've been deleted, renamed or a default branch might simply not be set, which happened between the upgrade from an older version to
1.22
, before the workaround was released.I can 100% confirm, that this is not the case. My repositories worked for all previous versions, then I switched to
1.22
and suddenly the system looks for a branch, that never existed in any of the repositories on my instance in the first place. No default branches have been ever re-assigned or even deleted.The root problem is related to the system trying to find the default branch
main
, even though, there is no reason for looking for it. Even, if it has never been there. It still looks for it. This is one question, that needs to be answered, to be able to properly fix the issue.I welcome other affected users to comment on this issue and add further information for clarifying the issue at hand.
Gitea Version
1.22-nightly
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?
Kubernetes via Helm
(Happens on any type of deployment, though.)
Database
PostgreSQL
The text was updated successfully, but these errors were encountered: